User Agent Accessibility Guidelines Working Group Teleconference -- 14 Apr 2011

<trackbot> Date: 14 April 2011

microosft is kford

<JAllan> Kudos to Simon as co-chair of revitalized R&D WG

<scribe> Scribe: KFord

<JAllan> sh: explains the purpose of the RDWG, quarterly meetings, workshops on new topics

SH explains new R&D W3C group.

Simon, do you have a link to your group's home page?

<Greg> http://www.w3.org/WAI/RD/

Group gives some history of previous involvement with this effort.

reminder longer meeting on April 28

JA reminds everyone of the longer call on 4/28.

Quick survey F2F Santa Clara, CA at the Santa Clara Marriott Hotel from 31 October through 4 November 2011

JA: There will be a TPAC meeting in CA on 10/31.
... Do people think we should try and meet at this meeting and do a F2F?

Group in general sounds like reasonable idea.

<jeanne> Greg: would prefer later in the week.

<JAllan> small registration fee of 50 USD per day to defray a portion of the meeting costs

<jeanne> Simon: I can't get that far to California.

<jeanne> Simon: I'd like to pass up the tree that it's cheeky of W3C to ask for a $50 fee when we are already providing our work for free.

<jeanne> Jan: I doubt I could attend in person. I probably could attend by phone.

<jeanne> Greg: I probably could make it, but I would have to verify that.

<jeanne> Kelly: Probably yes.

<jeanne> Kim: Tentative yes

<jeanne> Jim: Yes, but I have to talk to Judy.

<jeanne> Jeanne: yes

<mhakkinen> +1 for thursday-friday

<mhakkinen> +1 for early or late in the week

Group moving forward on doing a F2F.

<JAllan> ACTION: JAllan complete WBS F2F survey, for beginning of the week (can change later), meet with html5, pf [recorded in http://www.w3.org/2011/04/14-ua-minutes.html#action01]

<trackbot> Created ACTION-523 - Complete WBS F2F survey, for beginning of the week (can change later), meet with html5, pf [on Jim Allan - due 2011-04-21].

JS: Do we have anyone who has knowledge about creating accessible PDFs using tools outside Adobe tools?

If you know more about this, let JS know.

<jeanne> simon: Vision Australia just presented a paper at the W4All conference on this.

<JAllan> topic SC 2.7.3

<JAllan> 2.7.3 http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JanMar/0090.html

Proposals from Simon, please see:

<Jan> http://www.w3.org/2002/09/wbs/36791/20110405/results

<jeanne> http://www.w3.org/2002/09/wbs/36791/20110405/results#xq3

<jeanne> wiki - http://www.w3.org/WAI/UA/work/wiki/Guideline_2.7

<JAllan> Jeanne's wording for 2.7.3 http://www.w3.org/2002/09/wbs/36791/20110405/results#xq3

<JAllan> The user can view the path of nodes leading from the root of any content hierarchy including those in which the structure and semantics are implied by presentation.

<Greg> 1. The new wording still says the path goes from the root, but not where it goes to.

<Greg> 2. If it requires the UA to infer hierarchy from presentation, the UA may get it wrong, and may that (at least in some cases) be even worse for the user than not providing any hierarchy?

<JAllan> JS: need to deal with heuristics. seems a lot for Level A

Group talking about the aspects of determining path.

<jeanne> Simon: It is more like the Firebug Inspect visual rendering of the information.

SH: The DOM might not be the rendered model.

JR: If I put things that visually look close so you can associate them, how is the browser supposed to figure this out?

<Greg> Keep in mind that screen readers try to infer labels for elements based on spatial position, but they are not foolproof. For example, imagine a scripted element with text immediately above and to the left of it. Which is the element? Can't be sure.

<JAllan> kf: confused. without explicit association, AT doesn't know what to do. they have heuristics and try to guess. half the time get it wrong.

<JAllan> ... what are we asking.

<Greg> I would say that presenting hierarchy that is entirely known (because it's spelled out in the DOM or source) should be higher priority than putting in heuristics and presenting guesswork to the user.

JS: Canvas makes this even harder.

JA: Mark you were a browser developer, is such a thing possible.

MH: I think this would be hard.

<Greg> I suggest we create some usage examples and then decide which we want to require at what priority levels, and only after that try to craft legalese wording for one or more SCs.

<Greg> E.g. usage example 1: the user can issue a keyboard command causing their Web browser to pop-up a window showing the list of container elements from the root to the element that has the keyboard focus.

<Greg> E.g. usage example 2: the user right-click on an element and choose a command from its context menu causing their Web browser to pop-up a window showing the list of container elements from the root to the element that was clicked on.

<JAllan> canvas is just pixels.

<JAllan> sh: how is dom created for canvas.

<Greg> (Both of those would be container elements based on the DOM.)

<JAllan> kf: web author is expected to do that

<JAllan> mh: author must provide coordinates of focus ring to AT

<JAllan> kp: most developer won't do this.

<JAllan> mh: will require toolkits for canvas.

<Greg> E.g. usage example 3: The user can use a command that selects the element that is the container of the element that is currently selected.

<Greg> E.g. usage example 4: Just like #1 except the UA uses heuristics to try to determine hierarchy that is not explicit in the DOM.

<JAllan> first proposal usage example 1: the user can issue a keyboard command causing their Web browser to pop-up a window showing the list of container elements from the root to the element that has the keyboard focus.

KP: This seems like it is hard to do.

JR: What is a user going to do with the info?

<Greg> E.g. usage example 5: The user can turn on a mode where the browser's status bar shows the hierarchy of elements from that which has the keyboard focus to the root, as in root > body > div "content" > h1 "My Title" > p > a.

SH: I'd say it is more useful to have a path going to the root from the leaf.

JS: What accessibility problem does this solve?

SH: I think we are making a lot of presumptions about what people will and won't use.

MH: Wouldn't these items be solved by good structural markup.

SH: Yes but what should be in the real world and what is actually there are two different items.

KP: I agree that you have to get the world to try and do the right thing but you should try and have a safety net too.

SH: Maybe I should take this one back and reformulate things a bit.

GL: I suggest we use the wiki to put more usage examples for this.

MH: Can we try and put examples of real code where we think we'd need this approach.

<jeanne> http://www.w3.org/WAI/UA/work/wiki/Location_Hierarchy

<Greg> Mark referenced navigation based on structure, as opposed to merely displaying the structure. Navigation can be divided into the categories: sequential (back and forth), structural (as in to parent and child and sibling), directional (as in up, down, right and left based on screen position), and search.

<Greg> Kim's and my proposal on navigation includes three of those four, omitting only directional navigation.

2.7.4 http://www.w3.org/2002/09/wbs/36791/20110405/results#xq4

JA: We have two accepts and two changes.

GL: I think the SC isn't getting at the heart of what we want to achieve.

<JAllan> proposed change: Direct navigation: The user can navigate directly to important (structural and operable) elements in rendered content. (Level A).

<JAllan> Intent - It is often difficult for some people to use a pointing device (the standard method of direct navigation) to move the viewport and focus to important elements. In this case some other form of direct navigation - such as numbers or key combinations assigned to important elements - should be available which can then be accessed via the keyboard or speech control technology.

<Greg> We need to distinguish between two potential features: 1) where frequently used operable elements have direct navigation/activation keyboard commands (e.g. Alt+D to go to the address bar), vs. 2) a mode where the user agent adds direct navigation commands to ALL operable elements (e.g. the Mouseless Browsing extension for Firefox, which adds numbers to all links and controls).

<Greg> My first thought is that (1) is something that's already widely done, and expected by users, and therefore should be Level A, although it does have the problem of defining which set of controls are those that are frequently used and therefore should get direct shortcuts, whereas (2) is less widely done, and therefore could be lower priority.

KP: I'm not sure you have to reconfigure.

JA: Is what is missing is specificity or what?

SH: The intent here is something like mouseless browsing.

KP: What are we trying to bring to this by being more specific?

<JAllan> latest draft

<JAllan> http://www.w3.org/WAI/UA/2011/ED-UAAG20-20110406/

KP: Mouseless browsing is already a good example.

JA: If we are going a bit in circles on this, are developers going to get confused.

<JAllan> implementing http://www.w3.org/WAI/UA/2011/ED-IMPLEMENTING-UAAG20-201

<JAllan> working draft http://www.w3.org/TR/2010/WD-UAAG20-20100617/

<JAllan> implementinghttp://www.w3.org/WAI/UA/2011/ED-IMPLEMENTING-UAAG20-20110406/

<JAllan> http://www.w3.org/WAI/UA/2011/ED-IMPLEMENTING-UAAG20-20110406/

<jeanne> Simon: Configure these important elements.

<jeanne> Greg: That is an existing SC - 1.2.3 Important Elements

<Greg> "1.10.3 (former 3.12.3) Configure Set of Important Elements:

<Greg> The user can configure the set of important elements for the hierarchical view, including by element type (e.g., headers). (Level AAA)"

<Greg> "Intent of Success Criterion 1.10.3 (former 3.12.3):

<Greg> Sometimes authors will visually convey relationships between elements by spatially grouping them, by giving them the same coloration or background, and so forth. Users may not be able to perceive those attributes, such as when using a screen reader, or when strong magnification makes it difficult to make a mental model of the screen layout. In those cases the user agent can assist by...

<Greg> ...providing a view of the data that groups elements that that user agent perceives as implying relationships. "

<Greg> I believe that my confusion was at least partially caused by a disconnect between the text of the SC ("The user can navigate directly to important (structural and operable) elements in rendered content. (Level A).") and it's title ("Diret Navigation") which is MUCH broader than the SC warrants. If we adjust the title it will help avoid confusion.

<Greg> Perhaps "Direct Navigation to Important Elements"?

<Greg> That would leave it open for us to have another SC that required direct navigation to some frequently used elements in the UA UI.

<JAllan> mh: important elements - ua needs to incorporate aria-roles in to important elements designation

<mhakkinen> "non-important" elements can become important through use of ARIA role. E.g. <div role="heading" aria-level="2">

<jeanne> ACTION: change the name of 2.7.4 to "Direct Navigation to Important Elements" [recorded in http://www.w3.org/2011/04/14-ua-minutes.html#action02]

<trackbot> Sorry, couldn't find user - change

<jeanne> ACTION: jeanne to change the name of 2.7.4 to "Direct Navigation to Important Elements" [recorded in http://www.w3.org/2011/04/14-ua-minutes.html#action03]

<trackbot> Created ACTION-524 - Change the name of 2.7.4 to "Direct Navigation to Important Elements" [on Jeanne F Spellman - due 2011-04-21].

<JAllan> issue: navigate by element and semantic role (<div role="heading" aria-level="2">)

<trackbot> Created ISSUE-83 - Navigate by element and semantic role (<div role="heading" aria-level="2">) ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/83/edit .

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

14 Apr 2011

Attendees

Contents

reminder longer meeting on April 28

Quick survey F2F Santa Clara, CA at the Santa Clara Marriott Hotel from 31 October through 4 November 2011

Proposals from Simon, please see:

2.7.4 http://www.w3.org/2002/09/wbs/36791/20110405/results#xq4

Summary of Action Items

Scribe.perl diagnostic output