See also: IRC log
<scribe> ACTION:jeanne make new scribe schedule [recorded in http://www.w3.org/2008/08/21-ua-minutes.html#action01]
JALLAN out 9/4 and 9/11
<jeanne> 4.1.5 User has the option to have the keyboard commands for currently
<jeanne> available UI and interactive CONTENT controls be presented in close proximity to
<jeanne> the control in the modality of presentation, easily discoverable without AT,
<jeanne> and able to be activated with a single keystroke. with NOTE:For each browser modality, it needs to be in the correct modality.
<AllanJ> http://www.w3.org/WAI/UA/2008/draft_uawg_charter_14aug08.html
JALLAN, any comments on charter?
Jeanne, JB asked to change dates to quarterly instead of by month and to ensure something is published each quarter. Look in 2.2.
Jeanne expanded from proposals in meeting, all make sure it makes sense.
JAlan, assuming we'd be putting in heartbeat editor drafts.
JAllan, do we need to be putting in updated working draft each quarter.
Jan might want to put in public working drafts every two quarters or something.
<scribe> ACTION: jeanne put in working draft q1 09 [recorded in http://www.w3.org/2008/08/21-ua-minutes.html#action02]
Jeanne, updated mission to include interop with assistive technology, changes some dates and otherlittle edits.
kford I think charter is fine.
Jan, timeline seems to make sense, one of these things that's kind of up in the air. Last call draft a bit ambitious.
Sharper good.
<AllanJ> Mark?? thoughts on charter?
JAllan, itis good.
Jeanne, charter is good.
resolved: charter edits accepted at current state.
<AllanJ> http://www.w3.org/WAI/UA/2008/status41.htm
JAllan thrashing on 4.1, JAllan had action to review and get organized/agreed on.
first is keyboard operation, all functionality operable from keyboard (see link)
JAllan we had provisionally approved.
<jeanne> action02: closed
kford had action to review 4.1 and 4.7
<scribe> ACTION: kford review 4.1 and 4.7 [recorded in http://www.w3.org/2008/08/21-ua-minutes.html#action03]
Any issues with 4.1 as read.
Jeanne, take a vote.
Jan,good.
<jeanne> Jeanne +
All agreed good.
Resolved: 4.1.1 added to current draft as is.
<scribe> ACTION: Jeanne add to current draft [recorded in http://www.w3.org/2008/08/21-ua-minutes.html#action04]
JAllan 4.2 keystroke processing order.
<AllanJ> KF: consulted with developers. 4.1.2 seem technically feasible.
Jeanne vote on 4.2
<jeanne> jeanne +
Resolved: add 4.1.2 to current draft.
<scribe> ACTION: Jeanne Add 4.1.3 to draft [recorded in http://www.w3.org/2008/08/21-ua-minutes.html#action05]
moving to 4.1.3 keyboard trap
See link for text.
<AllanJ> new text for discussion 4.1.3 No Keyboard Trap (Minimum): The user agent prevents keyboard traps as follows: 1. in the UI: if keyboard focus can be moved to a component using the keyboard, then focus can be moved away from that component using standard sequential keyboard commands (e.g., TAB key) 2. in the rendered content: provides a documented direct keyboard command that will...
<AllanJ> ...always restore keyboard focus to a known location (e.g., the address bar). Level A 4.1.xx (Level AA) No Keyboard Trap (Enhanced): In the rendered content, if keyboard focus can be moved to a component using the keyboard, then focus can be moved away from that component using standard sequential keyboard commands (e.g., TAB key).
Jeanne, not sure I get the level a and aa, think they should be reversed.
Jan, in your UI, part you have full control, no keyboard traps.
In content, where things might steel keys, must have an eject button if you will.
No way the browser can guarantee keys in AJAX.
Jallen, in contet this could be F6or alt+d or refreshing content setting focus to the top of the page. Old problem with Flash, tab into it but never get out. We need to have an AA if you can tab in, you can tab out.
Jan agree, nice to have, not sure it can be the tab key though. Many AJAX controls grabbing tab and arrows.
Jan, if these are circular, no way for User Agent to deal with this.
Jan, extent point 2 that talks about moving focus from current component to next component.
Jan, minimum is get me out of the stuck location.
Jeanne, it is still a barrier if you are not able to get past object. I think this stays level a.
Jeanne, doesn't have to be a tab key, just need a direct keyboard command to move you to a cybling item.
Jan, like idea of mirroring second item.
SHarper agree with Jeanne, in point 2 jumping back to address bar takes you out of the content. Should have something to jump to next item in document content.
Jan, may be some content that's so difficult to use that even being at top has trapped user.
<jeanne> in the rendered content: provides a documented direct keyboard command that will always restore keyboard focus to an element subsequent to the current element.
SHarper, what about next block in DOM?
Jan, I'd like to see both, get me back to address bar, someplace in DOM.
<AllanJ> in the rendered content: provides a documented direct keyboard command that will always restore keyboard focus to the next element in the DOM
JAllan: proposal to have 4.1.3 have existing 2 and a third with language similar to what Jim posted.
Jeanne: talk about what element we want item moved to.
<jeanne> in the rendered content: provides a documented direct keyboard command that will always move keyboard focus to a subsequent element.
More disucssion from all about what element to move to.
<AllanJ> in the rendered content: provides a documented direct keyboard command that will always move keyboard focus to subsequent focusable element
oard command that will always move keyboard focus to a subsequent element.
Resolved: 4.1.3 is existing draft plus new text.
<scribe> ACTION: Jeanne update draft with 4.1.3 revisions. [recorded in http://www.w3.org/2008/08/21-ua-minutes.html#action06]
4.1.4 Separate Activation
Jan, might be duplicated someplace else.
Jan, this is a very key concept.
Jallen: it is from UAG 1.
Resolved: 4.1.4 added to draft as is.
<scribe> ACTION: Jeanne, update draft with 4.1.4 [recorded in http://www.w3.org/2008/08/21-ua-minutes.html#action07]
4.1.5 user agent keyboard commands
<AllanJ> 4.1.5 User has the option to have the keyboard commands for currently available UI and interactive CONTENT controls be presented in close proximity to the control in the modality of presentation, easily discoverable without AT, and able to be activated with a single keystroke. with NOTE:For a visual browser, this needs to be a visual mode, for an auditory browser, it must be an auditory mode.
KFord: this basically means menu items need to be underlined and you can see this.
JAllan: Yes.
Jan: review2ing sentence, a lot goingon.
... A lot going on in this sentence, see text.
<AllanJ> KF: need a dictionary to parse sentence.
<AllanJ> ...doesn't flow with other language.
<scribe> ACTION: Jan to review 4.5 [recorded in http://www.w3.org/2008/08/21-ua-minutes.html#action08]
Jan: is this meant to be the controls you can see?
Jallan: Yes.
Jan: If the author has put a control off screen
is this then not included?
... Usually I'm a fan of abstracting but Judy's original point was that this
was a very visual need.
JAllen: Simon did you have issues with the visible?
Jeanne: No, it was Mark, it closed out auditory browsers.\
SHarper: Further explanation from last week's discussion.
Jan: One clarification, we are talking about controls that have keyboard commands. If the developer did not add commands this is not about that.
Jallan: correct.
Jeanne: should be something about commands should be discoverable.
Jallan: now to 4.1.6
Resolved: 4.1.6 was approved.
<scribe> ACTION: Jeanne to add 4.1.6 to draft. [recorded in http://www.w3.org/2008/08/21-ua-minutes.html#action09]
Jan: Pointing out that we have a section about following conventions. This has enough that we should still add it here but I wanted to call this out.
JAllan: 4.1.7 proposed to be removed.
... removed because it is part of 1.1.
... can we discuss.
Jan: there is a difference. Without 4.1.7 you
are saying you can have some inaccessible parts of your UI as long as you can
still do the functions. For example, you might not be able to get to the
toolbar as long as the functions have hotkeys.
... gave example of save button. 4.1.1 says you have to do it somehow, but
not necessarily from a toolbar.
<AllanJ> KF: Interesting. in most applications, tool bars are not accessible. but that's ok because you can get to the function from the menu.
<AllanJ> ...in IE tried to expand to give more control to toolbars.
Jan: use case that sticks in my mind is the person who can see but not able to use mouse.
We are now creating a situation where they can not get to what they see.
Jeanne: good point, whatching speech input users. Icon describes what you want to do but you have to search through menus.
SHarper: for me I was on the side of removing
initially but now I think by removing we remove ability for discovery.
... We place too much requirement on memory.
Jan: Make it AA.
Resolved: 4.1.7 to be included at AA.
<scribe> ACTION: Jeanne add 4.1.7 to draft. [recorded in http://www.w3.org/2008/08/21-ua-minutes.html#action10]
Jan: Let's keep the use case of the person who can see wanting easy access to what's visible.
Jallan: This is important because 4.1.1 applies
to base user agent. 4.1.7 applies to all extensions, toolbars and anything
else you add to the user agent, even if the author didn't provide keyboard
access that the user agent should.
... 4.8
<AllanJ> 4.1.8 Direct keyboard commands are provided to activate the following classes of functions (contingent on direct keyboard commands being available in the *operating environment*): (a) most commonly used functions (e.g., address bar, "back" button, etc.) (b) display-related functions (e.g., increase/decrease text size, volume, etc.)
<AllanJ> Note: Change "operating environment" Def'n to add device restrictions:
<AllanJ> operating environment
<AllanJ> The environment that governs the user agent's operation, including both software (e.g., operating system, programming language environments such as Java) and hardware (e.g., mobile devices with a limited number of buttons).
Jan: I think I wrote this and wonder if commonly used is a problem.
<AllanJ> SH: change 'commonly used functions' to 'primary to the operation;
<AllanJ> KF: question about "contigent on commands available in the OS"
<AllanJ> KF: concerned about 'operating environment'
<AllanJ> ...what we want to say is 'if you don't do something you don't have to have a keystroke for it'
<AllanJ> JR: want developer to add direct keyboard command for available features if hardware allows
<AllanJ> KF: what we mean and what we say are different
<AllanJ> ...use case - 10 important commands that you can touch on a screen but only 5 buttons
<AllanJ> ...how do you get at all functionality.
<AllanJ> JR: need to smooth out 'contingent upon'
<AllanJ> JA: straw poll
<scribe> ACTION: kford to update 4.1.8 [recorded in http://www.w3.org/2008/08/21-ua-minutes.html#action11]
JAllan: on to 4.9
<scribe> ACTION: Jallann update 4.9 [recorded in http://www.w3.org/2008/08/21-ua-minutes.html#action12]
Jallan: 4.10
<AllanJ> 4.1.10 User Override of Keyboard Commands: The user can override any keyboard shortcut binding that is part of the user agent default input configuration except for conventional bindings for the operating environment (e.g., for access to help). The keyboard combinations offered for rebinding include single key and key plus modifier keys if these are available in the operating environment.
Presnet+Sharper
<AllanJ> 4.1.xx
<AllanJ> The user can override any author supplied content keybinding (i.e. access key) that the user agent can *recognize*. The user must have an option to save the override of user interface keyboard shortcuts so that the rebinding persists beyond the current session.
kford: should this be AA.
some discussion and agreement that it should.
JAllan: 4.1.xx is new.
SHarper: Are we saying in 4.1.10 you can save key bindings. We don't call that out.
Jeanne: I think we are.
picking up next week on 4.10