See also: IRC log
<trackbot> Date: 05 January 2012
trackbot, start meeting
<trackbot> Meeting: User Agent Accessibility Guidelines Working Group Teleconference
<trackbot> Date: 05 January 2012
action+ survey https://www.w3.org/2002/09/wbs/36791/20120105/
action+ survey https://www.w3.org/2002/09/wbs/36791/20120105/
discussion of timing. 3 hours seems concensus
js suggest thurs and friday
<jeanne> Special Meeting: 19 & 20, 1:00-4:00 ET
js suggests also meeting on 13 also
will have tentative meeting on Jan 13 from 1-4 ET. come if you can, Zakim will be set up,
Jeanne will send out the zakim codes, etc
<jeanne> ACTION: Jeanne to set up zakim teleconferences for special meetings on 13, 19 & 20 and send out notices. [recorded in http://www.w3.org/2012/01/05-ua-minutes.html#action01]
<trackbot> Created ACTION-698 - Set up zakim teleconferences for special meetings on 13, 19 & 20 and send out notices. [on Jeanne F Spellman - due 2012-01-12].
https://www.w3.org/2002/09/wbs/36791/20120105/
this is the current wording in the draft.
jr: need dfn for "Timebase", "continuous scale, "relative time units"
<scribe> ACTION: markH to write definitions for "Timebase", "continuous scale, "relative time units" related to 2.11.7 [recorded in http://www.w3.org/2012/01/05-ua-minutes.html#action02]
<trackbot> Sorry, couldn't find user - markH
<scribe> ACTION: mark to write definitions for "Timebase", "continuous scale, "relative time units" related to 2.11.7 [recorded in http://www.w3.org/2012/01/05-ua-minutes.html#action03]
<trackbot> Created ACTION-699 - Write definitions for "Timebase", "continuous scale, "relative time units" related to 2.11.7 [on Markku Hakkinen - due 2012-01-12].
discussion of time position, and continuous time scale.
mh: user is limited by granularity of the interface on the continuous time scale.
jr: we need to define our scale better. saying that it depends on the UI (frame, tenth of second, 10 seconds, etc.) where is the accessibility criteria?
gl: granularity should be "reasonable"
jr: arbitrary units could be gotten from WCAG20 2.2.1
<Jan> http://www.w3.org/TR/WCAG/#time-limits
jr: and 2.2.2
... interesting that WCAG has time of 5 seconds, UAAG has
timing of 3 seconds
mh: caption on screen length...as long as speech lasts or until next instance of speech
gl: base it on type of media, high speed camera work.
mh: stick with continuous time scale, but may depend on the media.
setting of time scale 1-10, or 1-100, or 1-500. youtube does 10% increments from the keyboard
kp: speech users need more granularity.
mh: as fine a granularity as supported by the technology
close for now, more discussion when mark comes back with definitions.
2.11.x Review Time-Based Media
The user can request that a predefined interval of recently played audio, video, or animation be repeated. (Level AA)
Intent:
Users with sensory, cognitive or attentional impairments may find it difficult to understand or follow time-based media, especially if distracted by environmental visual or auditory events. This success criteria allows users to review recently played content that may have been missed or not fully understood by providing a single action that resets the playback position by a predefined...
scribe: interval and resumes playback.
jr and gl: what is predefined?
<Greg> Clarify whether interval can be defined by developer, user, or either OK.
mh: to review Daisy spec. to see if timing is configurable. or see clarity of 'configurable'
gl: and others...this is a common feature in many players.
jr: granularity. Media accessibility requirements from PF Media Accessibility User Requirements
http://www.w3.org/TR/media-accessibility-reqs
could reference the above for granularity
gl: concerned about failing players for not meeting UAAG defined interval.
kp: need robust intent to explain some of the use cases
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012JanMar/0003.html
jr: combined these to make 1 SC removing 3.4.2
<Jan> http://www.w3.org/WAI/UA/2011/ED-IMPLEMENTING-UAAG20-20111227/#sc-342
<Jan> http://www.w3.org/WAI/UA/2011/ED-IMPLEMENTING-UAAG20-20111227/#sc-241
<Jan> oops...
<Jan> http://www.w3.org/WAI/UA/2011/ED-IMPLEMENTING-UAAG20-20111227/#sc-214
gl: need to exempt have the
status bar change as a link gets focus.
... transient presentation of information needs to be
considered
<Jan> 2.1.6 Separate Selection from Activation (former 2.1.4): The user can specify that selection is separate from activation (e.g. navigating through a set of radio buttons without changing which is the active/selected option). (Level A)
<Jan> 3.4.2 Avoid Side Effects of Navigation [former 1.9.1, before that 3.11.11, changed]: The user can move the keyboard focus without causing the user agent to take any further action, other than the presentation of information (e.g. scrolling or pop-ups that do not change the focus or selection). (Level A)
jr: is combining ok
<Greg> I agree it's possible in concept to combine those two, as changing focus could be considered a side effect of navigation.
ja, gl, mh, kp all ok with combining
<Jan> ACTION: JR to Continue to work on the combined 2.1.6 Navigation Without Side Effects to make it clear that some transient side effects are ok [recorded in http://www.w3.org/2012/01/05-ua-minutes.html#action04]
<trackbot> Created ACTION-700 - Continue to work on the combined 2.1.6 Navigation Without Side Effects to make it clear that some transient side effects are ok [on Jan Richards - due 2012-01-12].
<Jan> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20111227/#sc-531
<jeanne> http://www.w3.org/WAI/UA/work/wiki/Main_Page
http://www.w3.org/WAI/UA/work/wiki/User_Agent_issues_effecting_A11y
<Greg> Jan suggests that 5.3.1 (document accessibility features) would cover making sure accesskey works correctly.
jr: add a more specific list to 5.3.1 call out bugs that affect accessibility
<Greg> Greg notes that's only true of the HTML spec is specific enough about behavior.
<Greg> HTML4 spec *does* require the focus to be moved when the user presses an accesskey ("Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element.") So the behaviors of Webkit-based browsers (e.g. Chrome and Safari) fail to implement it as spec'd.
tab and enter should reset the dom pointer
discussion basic functionality in browsers that are broken...in page link, anchors for form control @id
jr: inpage links should move keyboard focus and the subsequent tabs should take the user to the next available link after the named anchor
<Jan> http://www.tc.gc.ca/eng/menu.htm
<scribe> ACTION: Jim to write intent for 5.3.1 to address browser bugs effecting accessibility [recorded in http://www.w3.org/2012/01/05-ua-minutes.html#action05]
<trackbot> Created ACTION-701 - Write intent for 5.3.1 to address browser bugs effecting accessibility [on Jim Allan - due 2012-01-12].
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/thrus/thurs/ Succeeded: s/US./ET/ No ScribeNick specified. Guessing ScribeNick: JAllan Inferring Scribes: JAllan Default Present: Jim_Allan, Greg_Lowney, Jeanne, Jan, Kim_Patch, +1.609.734.aaaa, Mark Present: Jim Jeanne Kim Jan Mark Greg Regrets: simon kelly wayne Simon Kelly Found Date: 05 Jan 2012 Guessing minutes URL: http://www.w3.org/2012/01/05-ua-minutes.html People with action items: jeanne jim jr mark markh[End of scribe.perl diagnostic output]