minutes: UAWG 11 October 2012

from: http://www.w3.org/2012/10/11-ua-minutes.html
User Agent Accessibility Guidelines Working Group Teleconference
11 Oct 2012

See also: IRC log http://www.w3.org/2012/10/11-ua-irc
Attendees

Present
    Jim_Allan, kford, Greg_Lowney, Jeanne, Kim_Patch, Jan, MarkHakkinen
Regrets
    Jeanne
Chair
    JimAllan, KellyFord
Scribe
    Greg_Lowney

Contents

    Topics
        Volunteers writing mobile examples. October 12.
        Finish off 2.8 Action-747
        Levels Discussion
        Finish off 2.8 Action-747
        Levels Discussion
    Summary of Action Items

Summary of Action Items
[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] 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> Date: 11 October 2012

<JAllan> http://www.surveygizmo.com/s3/966655/Microsoft-Accessibility-Survey
Volunteers writing mobile examples. October 12.

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.
Finish off 2.8 Action-747
Levels Discussion

<mth> http://www.youtube.com/watch?v=E7ZCRkyb-uQ

<mth> link is to a video demo of assistive touch
Finish off 2.8 Action-747

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.
Levels Discussion

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?

<Jan> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-command-element

<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].


[End of minutes]

-- 
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

Received on Thursday, 11 October 2012 18:39:58 UTC