Minutes: User Agent Accessibility Guidelines Working Group Teleconference 07 Jul 2011

- DRAFT -
User Agent Accessibility Guidelines Working Group Teleconference
07 Jul 2011

See also: IRC log<http://www.w3.org/2011/07/07-ua-irc>

Attendees
Present
Simon, Jeanne, Kim, Jim, Mark, Kelly, Greg, Jan
Regrets
Chair
jimallan, kellyford
Scribe
kford
Contents
*         Topics<http://www.w3.org/2011/07/07-ua-minutes.html#agenda>
1.    ATAG http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JulSep/0002.html<http://www.w3.org/2011/07/07-ua-minutes.html#item01>
2.    Survey http://www.w3.org/2002/09/wbs/36791/20110620/<http://www.w3.org/2011/07/07-ua-minutes.html#item02>
3.    Patrick Comments on 4.1.4 http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JulSep/0000.html<http://www.w3.org/2011/07/07-ua-minutes.html#item03>
4.    HTML 5 review status<http://www.w3.org/2011/07/07-ua-minutes.html#item04>
*         Summary of Action Items<http://www.w3.org/2011/07/07-ua-minutes.html#ActionSummary>
________________________________

<trackbot> Date: 07 July 2011

trackbot, start meeting

<trackbot> Meeting: User Agent Accessibility Guidelines Working Group Teleconference

<trackbot> Date: 07 July 2011

<mhakkinen> mark will be on the phone in about 5min
ATAG http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JulSep/0002.html

<scribe> Scribe: kford

<JAllan> jr: atag had def of platform and a11y platform,

JR: We were talking about platforms in ATAG. Issues came up so I came up with some new wording.

JR reads definition of platform from ATAG.

<JAllan> "Platform":

<JAllan> The software environment within which the authoring tool operates.

<JAllan> Platforms provide a consistent operational environment on top of lower

<JAllan> level software platforms or hardware. For web-based authoring user

<JAllan> interfaces, the platform will be user agents (e.g., browsers). For

<JAllan> non-web-based user interfaces, the range of platforms includes, but

<JAllan> may not be limited to, desktop operating systems (e.g. Linux, MacOS,

<JAllan> Windows, etc.), mobile operating systems (e.g. Android, Blackberry,

<JAllan> iOS, Windows Phone, etc.), or cross-OS environments (e.g. Java), etc.

<JAllan> Note 1: Many platforms mediate communication between applications

<JAllan> operating on the platform and assistive technology via a platform

<JAllan> accessibility service.

<JAllan> Note 2: Accessibility guidelines for developers exist for many platforms.

JR: Main point here is that on some platform you have a user agent or authoring tool. You also have assistive technology. The accessibility service is how the two communicate.

GL: talking about some small clarifying points around be in second sentence.
... When I talk about platform, I also include hardware.
... Hardware can often define capabilities.

JR: We use the term operating environment for hardware and to be inclusive of the entire situation where things are happening.

GL: That seems reasonable.

JS: What's our current definition of platform?

JA: We don't have one.

<JAllan> in UAAG2 platform issues are covered in 4.1.1, 4.1.2 (Mostly principle 4) and guideline 5.3

<jeanne> ACTION: jeanne to add the above definition of Platform and link some key phrases to it. [recorded in http://www.w3.org/2011/07/07-ua-minutes.html#action01]

<trackbot> Created ACTION-582 - Add the above definition of Platform and link some key phrases to it. [on Jeanne F Spellman - due 2011-07-14].

GL raises question about web-based and non-web-based.

JR: ATAG makes this split because WCAG is so handy for the web requirements. Non-web is for apps that are not on the web.

<JAllan> +1 to using relevant platform

<Greg> "For web-based authoring user interfaces, the RELEVANT platform will be user agent..."

<Greg> JR: "For web-based authoring user interfaces, the MOST RELEVANT platform will be user agent..."

Group now discussing how you determine relevant platform?

JR: Let's say Android makes some programatic hooks available to something running inside the browser.

<Greg> Just suggesting the example actually describe layers, e.g. browser running using a runtime library running on a window manager running on an operating system running on a bios...

JR: : I think I'd like to keep this the way it is. If we want more detail it can be in implementing.

JA: I like that idea.
Survey http://www.w3.org/2002/09/wbs/36791/20110620/

<JAllan> http://www.w3.org/2002/09/wbs/36791/20110706/results

JR: I rewrote this to make it clearer that we want an indicator close to content.

<Greg> My comment was that I can accept it, although I am somewhat concerned that "content" is less specific than the term "elements" it used before. Wouldn't the new wording would let a browser comply even if it only displayed an indicator next to large blocks of content that had alternative content within it, or even next to viewports, rather than by every individual image that had alt text?

JR: What is an element in makrup doesn't always translate into something recognizable on the screen.

<JAllan> related to this...Anthony Ricaud. has developed a new Longdesk 0.1, FireFox Extension. It is a " simple add-on that adds a link to the longdesc under images that provides one..." https://addons.mozilla.org/en-US/firefox/addon/longdesk/

<Jan> user interface component

<Jan> A part of the user interface or content display (including content renderings) that is perceived by authors as a single control for a distinct function.

<Jan> WCAG2 version: http://www.w3.org/TR/WCAG20/#user-interface-componentdef

<Jan> "a part of the content that is perceived by users as a single control for a distinct function"

<Greg> If we keep the term "content" then should clarify it in the Implementing document, explaining that putting an indicator next to a viewport is *not* sufficient to meet the intent.

<jeanne> ACTION: jeanne to update 1.1.2 with updated text from the survey http://www.w3.org/2002/09/wbs/36791/20110706/results [recorded in http://www.w3.org/2011/07/07-ua-minutes.html#action02]

<trackbot> Created ACTION-583 - Update 1.1.2 with updated text from the survey http://www.w3.org/2002/09/wbs/36791/20110706/results [on Jeanne F Spellman - due 2011-07-14].
Patrick Comments on 4.1.4 http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JulSep/0000.html

JA summarizing e-mail exchange with Patrick.

JA: Maybe this needs to be in the survey.

Discussion of edits to text under discussion.

GL: I think it is safe to say that for a user agent a DOM will provide a richer accessibility experience than an accessibility API because the former is specific to the environment while the API is intended to work over all apps.
... I see value in having both things be required if there is a platform accessibility API.

<Greg> I see value in having both things by required. If there is a platform accessibility API (e.g. MSAA or JAA) expose stuff through that so that general-purpose accessibility aids that are designed to work with all applications on that platform can work reasonably well with your browser. However, if you implement a technology that defines of DOM, you should ALSO expose the DOM so that specific-purpose

<Greg> accessibility aids can have a much richer interface to your content and provide additional functionality for users.

JA: GL How does what you are talking about merge with PL's e-mail?

GL: Exposing screen order seems good.
... Things like name role and such are pretty standard now.

<Greg> As for Patrick's suggestion that 4.1.2 and/or 4.1.4 require exposing some structure and relationship info through a platform accessibility API, it seems at first glance reasonable. However, those terms are broader and less well defined than name, role, etc. But exposing at minimum the document order or screen order of the elements seems reasonable.

JA: This can go in a survey and I'd encourage people to talk about this on the list since Patrick is there.

MH: Do we define screen order?

GL: I did mention reading order in some stuff I put on the wiki but we don't talk about screen order.

Group continues to look to see if we do this.

Conclusion seems to be that screen order really sin't defined.

MH: I am just curious if this is really reading order or if we need to do more?

<Greg> Minimum would be exposing document order (which we don't define but apparently use to mean the order things are defined in the source code), and next step beyond that would be exposing suggested reading order (for non-naive user agents that have such a concept).

JA: Talks about an app he was reviewing where on the screen it looked fine but where source code order was reverse of what was being shown so screen reader started at the bottom of the form.

<mhakkinen> +1

<KimPatch> +1

<jeanne> +1

<sharper> +1

JA: Do we need a definition of document order in our glossary?

+1

MH: I looked in html 5 spec and see document order used once but not defined.

<Jan> correct reading sequence

<Jan> any sequence where words and paragraphs are presented in an order that does not change the meaning of the content

<Jan> navigated sequentially

<Jan> navigated in the order defined for advancing focus (from one element to the next) using a keyboard interface

<Jan> same relative order

<Jan> same position relative to other items

<JAllan> html5 - The term tree order means a pre-order, depth-first traversal of DOM nodes involved (through the parentNode/childNodes relationship).

Group continues to talk about if these terms are defined or not.

JA: It sounds liike we agree we need a definition. Who will write it.

MH: I'll take a go at it.

<Greg> Document order: the order in which elements are defined in the source language?

<scribe> ACTION: MH to write definition of document order [recorded in http://www.w3.org/2011/07/07-ua-minutes.html#action03]

<trackbot> Created ACTION-584 - Write definition of document order [on Markku Hakkinen - due 2011-07-14].
HTML 5 review status

KF: I'm the one who asked for this. Whatever we are doing for review needs to be to PF by next Friday.

<JAllan> UAAG html5 comments http://www.w3.org/WAI/UA/work/wiki/HTML5_review_by_UAWG_notes

GL: Goes over his mail sent with issues on HTML 5 review.

<JAllan> Keyboard Concepts for HTML5 Discussion http://www.w3.org/WAI/UA/work/wiki/Keyboard_Concepts_for_HTML5_Discussion

GL: One big concern is accesskey. This is fine for the underlined sine letter but not good enough for hotkeys.
... I think content should be able to register the global hotkeys and negotiate these with the user agent.
... Writing a web app is fundamentally different from a native app in that you have an entire environment to work through because all that surrounds the environment where the web app runs i.e. user agent, plug-ins and such.

KP talks about speech on phones.

KP not complete speech access but hear rumblings that things are coming.

KP Dragon on iPhone has improved in noisy environments.

Summary of Action Items
[NEW] ACTION: jeanne to add the above definition of Platform and link some key phrases to it. [recorded in http://www.w3.org/2011/07/07-ua-minutes.html#action01]
[NEW] ACTION: jeanne to update 1.1.2 with updated text from the survey http://www.w3.org/2002/09/wbs/36791/20110706/results [recorded in http://www.w3.org/2011/07/07-ua-minutes.html#action02]
[NEW] ACTION: MH to write definition of document order [recorded in http://www.w3.org/2011/07/07-ua-minutes.html#action03]