See also: IRC log
<trackbot> Date: 11 October 2012
<JAllan> http://www.surveygizmo.com/s3/966655/Microsoft-Accessibility-Survey
JA: Reminder that tomorrow volunteers will write mobile examples for UAAG20.
<JAllan> There will also be dial-in access for those who cannot attend in person via the W3C Conference Bridge at:
<JAllan> (+1 617.761.6200, conference code: 662453# [mobile#]). For SIP access: zakim@voip.w3.org
<JAllan> Instructions for SIP access are at: http://www.w3.org/2006/tools/wiki/Zakim-SIP
KP: Currently four people will be there live in the room, in addition to callers.
<JAllan> 9-4:30 EDT
<scribe> scribe: Greg_Lowney
KP: People are welcome to dial in for part of the day, whenever works for them, any time from 9:30 EDT on.
<mth> http://www.youtube.com/watch?v=E7ZCRkyb-uQ
<mth> link is to a video demo of assistive touch
KP: iOS 6 contains an accessibility feature called Assistive Touch which is intended for people who can only do single touch, also replacing the need to use physical buttons.
JS: The ease with which it can be moved could be an example of how toolbars can be moved or customized.
JR: One cannot expect that degree of configurability from something that is not the OS.
MH: Almost done with work on upgrading and synthesizing input on toolbars, will email soon.
JA: Resuming on 2.3.4.
Spreadsheet is at https://docs.google.com/spreadsheet/ccc?key=0AiiGLIaAlHSKdHNrcGNacUp2MHdXQW9sUmpBQ21Lenc&pli=1#gid=0
<JAllan> http://www.w3.org/TR/UAAG20/
JA: 2.3.4 Present Direct Commands in User Interface (AA).
JR: We didn't finish discussion of 2.3.2 Present Direct Commands in Rendered Content last week.
JA: According to minutes, we got down to implementation strategies but did not decide on a level.
KP: Thinks it should remain A, because much of her job is explaining to users that something exists they didn't know about. Discoverability is key. Jeanne just told us about something most of didn't know about.
JR: Microsoft does that in its ribbon, wondering how hard it is to implement.
MH: Browser has to walk the DOM to final where all the ARIA landmarks are.
KF: Rendering is complicated because where do you put it, how does it affect page layout.
KP: The one that Jeanne pointed out handles it well, they fade.
MH: Transparency leads to background color problems.
KP: Key is letting the user change the presentation to meet their needs. Having more people thinking about ways to implement this well will be very important.
JR: Browser handles some commands natively (e.g. accesskey) but not others (e.g. landmarks). How? It must walk the DOM, identify all the landmarks. One concern is that if we allow plugins to do things, and plugins bring in their own direct commands (e.g. direct commands for landmark) if they didn't put them into the overlay would the combined tool fail?
GL: Isn't the Mouseless Browsing add-in one implementation of this?
JR: E.g. is an add-in provides an outline view that has its own shortcuts.
JA: ARIA Landmarks do not have key bindings, so this is a separate issue, so we should just stick with accesskey.
GL: What about the COMMAND element that associates a keyboard shortcut with an element or action?
<JAllan> greg discusses feedback about the 'command' element
<JAllan> mh: how to bind the key
<JAllan> mh: ah, access key
So, COMMAND provides a way of associating a keyboard input (accesskey) with any action or element in a way that is recognized by the user agent, allowing the user agent to convey this to the user through any UI it deems appropriate (e.g. displaying indicators inline, providing a voice menu or on-screen menu, etc.)
I've provided feedback in the HTML5 development process recommending that the mechanism for specifying keyboard inputs for COMMAND elements be made more flexible.
Discussion of how Mouseless Browsing add-in is an example of the UI, but does not exactly match this SC because it adds new shortcuts instead of just presenting existing ones.
JR: On mobile devices, gestures could be mapped to different spots, would be nice but if a menu is provided, but would we fail those that don't?
GL: I thought this was direct keyboard commands.
JR: It says all direct commands.
<JAllan> opera has an extension to reveal accesskeys
GL: What about limiting this to direct keyboard commands, which is what I think most of us thought it was?
KP: What about the bottom rung (minimum) being to present a persistent list of commands shortcuts, for keyboard inputs, gestures, etc.
JR: Can't always be visible, could be on request.
JA: Opera has exactly that, Chaal's accesskey button that appears on the UI. It lights up if there are accesskeys, you hit it and it gives you the list.
JR: Rewrite 2.3.2 to make that fit, or keep it as is with AA and add a new one that is A?
KP: Probably clearer to add a new A SC, making the current AA.
GL: The reason I put in the wording that shortcuts be presented "with their associated UI controls" is that there are many cases where a separate list won't be particularly useful, as in a lot of seemingly identical buttons.
KP: It would be unusual to provide shortcuts for separate identical buttons. If that happened, would have to make the list show them, e.g. an overlay.
JR: Level A would not handle that
case, a stinky end-user experience, which is why we have the AA
version that is better for those cases.
... The A requirement is just "a foot on the bottom rung", and
better than nothing.
<JAllan> ACTION: Jeanne to change 2.3.2 to AA because there are no implementations. [recorded in http://www.w3.org/2012/10/11-ua-minutes.html#action01]
<trackbot> Created ACTION-764 - Change 2.3.2 to AA because there are no implementations. [on Jeanne F Spellman - due 2012-10-18].
<Jan> ACTION: JR to Propose a new 2.3.X that is the list version of direct commands notification [recorded in http://www.w3.org/2012/10/11-ua-minutes.html#action02]
<trackbot> Created ACTION-765 - Propose a new 2.3.X that is the list version of direct commands notification [on Jan Richards - due 2012-10-18].
GL: we could edit the mouseless browsing add-in to simply remove the adding of addition accesskeys, and then it would be an implementation of 2.3.2.
MH: Simple Chrome extension that puts accesskeys in context on the page.
<mth> Accesskey extension for chrome using CSS http://aloiroberto.wordpress.com/2010/06/12/how-to-display-accesskey-shortcuts-in-google-chrome-and-much-more/
<JAllan> ACTION: jeanne add Accesskey extension for chrome using CSS http://aloiroberto.wordpress.com/2010/06/12/how-to-display-accesskey-shortcuts-in-google-chrome-and-much-more/ as a resource for 2.3.2 [recorded in http://www.w3.org/2012/10/11-ua-minutes.html#action03]
<trackbot> Created ACTION-766 - Add Accesskey extension for chrome using CSS http://aloiroberto.wordpress.com/2010/06/12/how-to-display-accesskey-shortcuts-in-google-chrome-and-much-more/ as a resource for 2.3.2 [on Jeanne F Spellman - due 2012-10-18].
<mth> For the record, here is the CSS:
<mth> a[accesskey]:after, button[accesskey]:after, input[accesskey]:after, label[accesskey]:after, legend[accesskey]:after, textarea[accesskey]:after { margin-left: 0.3em; color: Plum; content: "[" attr(accesskey) "]"; }
MH: We'll remove the term "landmark"?
JA: Yes, it just confuses the issue because landmark has nothing other than accesskey for associating a shortcut with it.
JR: Will remove the (e.g. accesskey, landmark) and instead link to the glossary entry for direct commands.
Next, 2.3.3 Direct activation (former 2.7.6): The user can move directly to and activate any operable elements in rendered content. (Level AA)
<Jan> Suggest handle change from: Direct activation --> Direct Activation of Operable Elements
GL: Can anything other than operable elements be directly activated?
<Jan> Hmmm are operable elements always recognizable as such or do we have to say recognized?
GL: operable element is not in the glossary.
JA: Same as "enabled element": An element with associated behaviors that can be activated through the user interface or through an API.
GL: operable elements might include both enabled and disabled elements (i.e. those that are *currently* disabled, but might be enabled later).
JR: This SC should be "enabled elements".
JA: OK with Jan's suggestion of "Direct Activation of Enabled Elements".
No objections from the group.
<scribe> New version: 2.3.3 Direct Activation of Enabled Elements (former 2.7.6): The user can move directly to and activate any enabled elements in rendered content. (Level AA)
<scribe> New version: 2.3.3 Direct Activation of Enabled Elements (former 2.7.6): The user can move directly to and activate any enabled element in rendered content. (Level AA)
<JAllan> ACTION: Jeanne change 2.3.3 to be: 2.3.3 Direct Activation of Enabled Elements (former 2.7.6): The user can move directly to and activate any enabled element in rendered content. (Level AA) [recorded in http://www.w3.org/2012/10/11-ua-minutes.html#action04]
<trackbot> Created ACTION-767 - Change 2.3.3 to be: 2.3.3 Direct Activation of Enabled Elements (former 2.7.6): The user can move directly to and activate any enabled element in rendered content. (Level AA) [on Jeanne F Spellman - due 2012-10-18].
GL: Technically it's "moving keyboard focus directly to", but OK.
Next, 2.3.1 Direct Navigation to Important Elements (former 2.7.4): The user can navigate directly to any important (e.g. structural or operable) element in rendered content. (Level A)
GL: "important element" should certainly be a link, or else readers will say "well, *I* don't think that's important."
JR: Suggest it be AA.
GL: Today the Mouseless Browsing add-ins don't allow navigation to static elements like headings.
JR: Does anything do this today?
General agreement to move it to AA.
GL: If there are no implementations by the time we publish it will be deleted altogether.
MH: We should maintain a list of at-risk SCs that need extensions written.
KP: However, deleting this would be horrible, it's very important.
GL: Create a wiki page listing add-ins we need written?
JA: Will create that wiki page today.
<mth> Accesskey, important elements, mouseless browsing are candidate for browser extension implementations.
<JAllan> ACTION: jeanne to change 2.3.1 to be 2.3.1 Direct Navigation to Important Elements (former 2.7.4): The user can navigate directly to any important (e.g. structural or operable) element in rendered content. (Level AA). Make 'important element' a link to glossary. move example (e.g. xxxx) to after the word element. moved to AA because no implementation [recorded in http://www.w3.org/2012/10/11-ua-minutes.html#action05]
<trackbot> Created ACTION-768 - Change 2.3.1 to be 2.3.1 Direct Navigation to Important Elements (former 2.7.4): The user can navigate directly to any important (e.g. structural or operable) element in rendered content. (Level AA). Make 'important element' a link to glossary. move example (e.g. xxxx) to after the word element. moved to AA because no implementation [on Jeanne F Spellman - due 2012-10-18].
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: Greg Found Scribe: Greg_Lowney Default Present: Jim_Allan, kford, Greg_Lowney, Jeanne, Kim_Patch, Jan, MarkHakkinen Present: Jim_Allan kford Greg_Lowney Jeanne Kim_Patch Jan MarkHakkinen Regrets: Jeanne Found Date: 11 Oct 2012 Guessing minutes URL: http://www.w3.org/2012/10/11-ua-minutes.html People with action items: 2.3.3 change jeanne jr WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]