User Agent Accessibility Guidelines Working Group Teleconference, 27 Jan 2011

W3C
- DRAFT -
User Agent Accessibility Guidelines Working Group Teleconference
27 Jan 2011

HTML: http://www.w3.org/2011/01/27-ua-minutes.html
IRC log: http://www.w3.org/2011/01/27-ua-irc

Summary of Action Items
[NEW] ACTION: Greg to write discussion of replacing the term "enabled 
element" as used in 1.3.1 Highlighted Items. [recorded in 
http://www.w3.org/2011/01/27-ua-minutes.html#action01]
[NEW] ACTION: Jeanne to add the following to implementing for 5.2 
[recorded in http://www.w3.org/2011/01/27-ua-minutes.html#action02]
[NEW] ACTION: jim to rewrite 1.8.5 to include exception for financial or 
other web application criteria (can't go back or charge credit card 
twice) [recorded in http://www.w3.org/2011/01/27-ua-minutes.html#action03]
[NEW] ACTION: sharper to rewrite 1.11.2 to include (perhaps) size and 
behavior indicator. [recorded in 
http://www.w3.org/2011/01/27-ua-minutes.html#action05]
[NEW] ACTION: simon to rewrite 1.11.2 to include (perhaps) size and 
behavior indicator. [recorded in 
http://www.w3.org/2011/01/27-ua-minutes.html#action04]

Attendees

Present
     +1.512.206.aaaa, +1.617.325.aabb, +1.425.895.aacc, Greg, JAllan, 
sharper, Jeanne
Regrets
     kelly
Chair
     JimAllan, KellyFord
Scribe
     Harper_Simon

Contents

     * Topics
          1. What do enabled elements mean?
          2. writing EIR 5.2.x
          3. writing EIR 1.11.2
     * Summary of Action Items

<trackbot> Date: 27 January 2011

Is this because th phone lines aren't working?

<JAllan> we are currently discussing the override of autoplay in video, 
and how that might happen. greg is writing it up now

<JAllan> it is possible that phone lines aren't working.

ringing

<Greg> We're discussing Autoplay, which came up in the HTML5 WG 
discussions. The question is, a user agent has implemented the ability 
to turn off autoplay (as required by UAAG20), but if a script implements 
autoplay directly, whose responsibility is it to make sure that autoplay 
doesn't happen? Greg suggested that whether autoplay is enabled or 
disabled in browser user preferences should be made...

<Greg> ...programmatically available to scripts as well as extensions 
and plug-ins, so that they can follow the user preference. Jim asked if 
the browser could simply refuse to play media when a script attempts to 
start it on load, but Greg's not sure that the user agent can 
distinguish that from attempts to start the media in response to some 
explitic user request. Providing a way for the script...

<Greg> ...to follow the browser's user preference settings also has the 
benefit of (if implemented correctly) stopping autoplay when done using 
media other than the HTML5 native media (e.g. flash).

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

<Greg> Kim and I are discussing tools that are useful for analyzing user 
agent behavior. One I find extremely useful on Windows is the Inspect 
tool (AKA Inspect Object) in the Microsoft Active Accessibility SDK. You 
can find it at least the most recent version on 
http://blogs.msdn.com/b/winuiautomation/archive/2009/06/03/windows-automation-api-sdk-tools.aspx.

<Greg> I'm not sure if that version is limited to Windows 7 or, like 
earlier versions, will work on any version of Windows with MSAA support.

<JAllan> Mozilla also has something similar. dom inspector - 
http://kb.mozillazine.org/DOM_Inspector,

<JAllan> and Firebug - 
https://addons.mozilla.org/en-US/firefox/addon/firebug/

<JAllan> discussion of F6 behavior in Firefox

<JAllan> need a clear focus indicator

<scribe> scribe: Harper_Simon

<scribe> ScribeNick: sharper
What do enabled elements mean?

<JAllan> 1.3.1 Highlighted Items: The user can specify that the 
following be highlighted so that each class is uniquely distinguished. 
It is not the intention that all recognized enabled elements be uniquely 
distinguished, just that they be distinguished from disabled elements.

GL: 1.3.1 Includes selection and focus etc - problem is recog enables 
elements - definition is unclear
... beyond just selection and performing action on selection
... Push button should be highlighted - listbox - do you want listbox to 
be highlighted or just items or both
... current wording is just about menus defined as part of content - 
question is - what is our end goal

KP: whats the top level - things that you have too - one of the place 
that the enable elements appears - therefore too broad - we only want to 
include useful things

enabled element, disabled element

An element with associated behaviors that can be activated through the 
user interface or through an API. The set of elements that a user agent 
enables is generally derived from, but is not limited to, the set of 
elements defined by implemented markup languages. A disabled element is 
a potentially enabled element that is not currently available for 
activation (e.g., a "grayed out" menu item).

<Greg> http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101215/#def-enabled-element

General discussion of the semantics and operation of radio buttons and 
check boxes to get some more insight into the meaning we are associating 
with enable.

<Greg> # ntent of Success Criterion 1.3.1 (former 3.5.1):

<Greg> Users need to be able to easily discover what web content they 
can interact with. Users with low vision need to be able to highlight 
selection, content focus, enabled elements and links (including recently 
visited links) in order to successfully discover and interact with the 
web content.

<Greg> # Examples of Success Criterion 1.3.1 (former 3.5.1):

<Greg> * A web site uses styles to override visited link color. A low 
vision user wants to know what links have yet to be explored. The user 
agent provides a dialog box for setting overrides to author-selected 
link colors.

<Greg> * An author has created a web site with CSS styles that removes 
the content focus outline. The user agent provides a dialog box for 
setting overrides to authors CSS focus outline declaration.

<Greg> Change the first example to "Thomas has low vision and difficulty 
distinguishing between closely related colors. A web site uses styles to 
override visited link color in a way which makes it impossible for him 
to distinguish between visited and unvisited links. As he wants, like 
most users, to know what links have yet to be explored, he users a 
dialog provided by the user agent to override...

<Greg> ...the author-selected link colors."

<Greg> Fred has difficulty with short-term memory, so it's very 
important to him to be able to tell which links he has already explored 
and which he hasn't. A web site's author uses styles to completely hide 
the distinction between visited and unvisited links, so Fred uses the 
browser's user preference settings to force all visited links to be one 
color and all unvisited links another color."

<JAllan> don't need to highlight all enabled elements at one time, only 
when they receive focus.

<JAllan> want the highlight classes to be distinguishable from each other.

<Greg> Yes, the list of highlighted classes should include links that 
have not been recently visited, to make it clear that visited and 
unvisited should be distinguished.

<JAllan> user should be able to tell which elements are actionable and 
which are purely decorative

<JAllan> link underlining vs link just in a different color

General Discussion: Aspects of which part of the highlighting will make 
the interface really cluttered.

<JAllan> most web pages make it clear which items are clickable (links, 
form controls)

GL: this would be optional to turn on and off so it could be left as is.

<JAllan> blue border for actionable images

<JAllan> author must do more work border=0 for images that are anchors

<Greg> If an option to highlight clickable items was turned on, the 
UAAG20 document would only have one change: the W3C icon would get a 
border identifying it as a link. On the other hand, Google Docs would 
have a huge number of highlighted items--everything on its custom menu 
bar and tool bar, etc.

<JAllan> sh: doesn't seem to be as relevant now, folks seem to 
'recognize' actionalbe elements

<JAllan> js: cites neilson research

<JAllan> kp: need granularity in what to highlight, only link text, only 
link images, both, etc.

JA: miss match in sentiment between content in the Intent criteria and 
interface in the sc

<Greg> I think we could distinguish between "must have" (Level A) vs. 
lower priority items. Many browsers already allow you to override the 
author-provided colors, and so make visited and unvisited links clearly 
distinguishable; I would consider that a must have. Similarly selection 
is nearly always clearly distinguished, but some web pages do make it so 
subtle as to be difficult to use. Overriding...

<Greg> ...that, too, I'd say is a must have, in part because it's 
usually already supported. On the other hand, highlighting all active 
elements is not generally done today, so we could reduce it's priority 
or delete it if no one does it.

<JAllan> sh: assumption that things are enabled unless otherwise 
indicated (low lighted - greyed out)

<Greg> Highlighting all recognized enabled elements and highlighting 
things with alternative content could be split out and reduced in priority.

<Greg> 1.3 Provide highlighting for selection, active keyboard focus, 
visited and unvisited links

<Greg> 1.3.1 (former 3.5.1) Highlighted Items: The user can specify that 
the following be highlighted so that each class is uniquely 
distinguished. It is not the intention that all recognized enabled 
elements be uniquely distinguished, just that they be distinguished from 
disabled elements. The user has the option to highlight the following 
classes of information so that each is uniquely distinguished. (

<Greg> Level A) :

<Greg> * (a) selection

<Greg> * (b) active keyboard focus (indicated by a cursor)

<Greg> * (c) active window

<Greg> * (d) recently visited links

<Greg> * (e) links that have not been recently visited

<JAllan> sh: why highlight only enabled element, why not just disabled 
elements

<JAllan> ... how does anybody know when anything is enabled.

<Greg> Simon points out that the user agent may not be able to tell 
which items are enabled or disabled if it's implemented in the element's 
event handlers.

<Greg> The current 1.3.1 though does limit it to "recognized" enabled 
elements.

<Greg> Recognized means programmatically determinable by the user agent.

<JAllan> ... if something has an onclick event, how does user know. this 
is disabled until the user does X that causes Y to be enabled

<JAllan> most users won't be able to tell about items with events, it is 
up to the author.

<JAllan> can UAs highlight elements with events

<Greg> Simon suggests the terms enabled and disabled are misleading here 
because the browser can tell whether something processes clicks and 
keys, but not whether it is currently in a state where it will perform 
an action--that is, when the enabled/disabled is handled in scripts.

<Greg> Anything the user can click on to perform an action, or give the 
keyboard focus to, which might include anything the browser sees as 
having mouse or keyboard event handlers.

<Greg> It is however important to distinguish between things that user 
can perform an action on directly vs. things the user can select and 
thereafter perform an action on the selection. For example, a block of 
text allows users to select some, bring up the context menu for that 
selection, or simply hit s key to copy that selection to the clipboard, 
but we don't feel that a block of text would be...

<Greg> ...considered actionable/clickable/whatever.

<Greg> We could invent a new term such as "actionable" element, 
distinguished from "enabled", for this purpose.

JA: GL and KP to take this from here

<Greg> ACTION: Greg to write discussion of replacing the term "enabled 
element" as used in 1.3.1 Highlighted Items. [recorded in 
http://www.w3.org/2011/01/27-ua-minutes.html#action01]

<trackbot> Created ACTION-489 - Write discussion of replacing the term 
"enabled element" as used in 1.3.1 Highlighted Items. [on Greg Lowney - 
due 2011-02-03].

<JAllan> update: autoplay 
http://lists.w3.org/Archives/Public/w3c-wai-ua/2011JanMar/0025.html

JA Update on Autoplay

JA: Opera say it can be done, browser can detect if the event comes from 
user to script and can set a preference to disable those to make sure 
they only happen on user interaction - would prefer this to be a prefs.
writing EIR 5.2.x

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

5.2.1 Web-Based Accessible: User agent user interfaces that are rendered 
using Web standard technologies conform to the relevant WCAG Level: "A", 
"AA", "AAA". (Level A)

<JAllan> ACTION: Jeanne to add the following to implementing for 5.2 
[recorded in http://www.w3.org/2011/01/27-ua-minutes.html#action02]

<trackbot> Created ACTION-490 - Add the following to implementing for 
5.2 [on Jeanne Spellman - due 2011-02-03].

<JAllan> * Intent of Success Criterion 5.2.x :

<JAllan> Web-based applications which are intended to replace or enhance a

<JAllan> desktop user agent or its functionality, but are in-fact built and

<JAllan> rendered using standard Web technologies, are becoming increasingly

<JAllan> common. These Web applications, windowless browsers, rich internet

<JAllan> applications, HTML5 canvas, etc., perform similar functions to 
their

<JAllan> desktop cousins and so must also conform to the accessibility

<JAllan> requirements placed on a desktop user agent.

<JAllan> * Examples of Success Criterion 5.2.x

<JAllan> Success criteria 2.5.1 requires that a user agent enable a user to

<JAllan> change settings that impact accessibility. In this case we 
would expect

<JAllan> that a Web-Based user agent should also enable a user to change

<JAllan> accessibility settings specific to its functionality, which may 
in some

<JAllan> cases enhance or override that of the platform on which it is 
executing:

<JAllan> window-less browser, native operating system, etc.

<JAllan> * Related Resources for Success Criterion 5.2.x

<JAllan> WAI-ARIA 1.0 User Agent Implementation Guide

<JAllan> W3C Web Design and Applications Activity.
writing EIR 1.11.2

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

JA: only sc in 1.11 and it is aaa - problem

<Greg> So, since 1.8.6 Open on Request allows the user to prevent a link 
from opening in a new viewport, it may not be necessary to provide an 
indication of whether a link is supposed to open in a new viewport.

<Greg> Simon points out that 1.8.5 Viewport History would create a 
security hole if the browser has to restore confidential information 
when the user presses the Back button.

<Greg> 1.8.5 does not require restoring the contents of form controls 
and the like, only point of regard, input focus, and selection. But it 
is somewhat ambiguous.

<Greg> I agree with Simon that we should probably revise 1.8.5 to make 
security precautions explicitly allowed.

<JAllan> ACTION: jim to rewrite 1.8.5 to include exception for financial 
or other web application criteria (can't go back or charge credit card 
twice) [recorded in http://www.w3.org/2011/01/27-ua-minutes.html#action03]

<trackbot> Created ACTION-491 - Rewrite 1.8.5 to include exception for 
financial or other web application criteria (can't go back or charge 
credit card twice) [on Jim Allan - due 2011-02-03].

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

<JAllan> sh: instead of technology type, say whats going to happen when 
you follow the link, instead of mimetype is pdf, say i am going to 
download a file

<JAllan> ... would be nice to know how big a file is

<JAllan> ... would be useful to know the size,

<JAllan> ... want to know ... opening a text file, download a file, it 
will take X long.

<JAllan> ... only in instance where something different than opening a 
web page will happen

<JAllan> ACTION: simon to rewrite 1.11.2 to include (perhaps) size and 
behavior indicator. [recorded in 
http://www.w3.org/2011/01/27-ua-minutes.html#action04]

<trackbot> Sorry, amibiguous username (more than one match) - simon

<trackbot> Try using a different identifier, such as family name or 
username (eg. sharper, spieters)

<JAllan> ACTION: sharper to rewrite 1.11.2 to include (perhaps) size and 
behavior indicator. [recorded in 
http://www.w3.org/2011/01/27-ua-minutes.html#action05]

<trackbot> Created ACTION-492 - Rewrite 1.11.2 to include (perhaps) size 
and behavior indicator. [on Simon Harper - due 2011-02-03].
Summary of Action Items
[NEW] ACTION: Greg to write discussion of replacing the term "enabled 
element" as used in 1.3.1 Highlighted Items. [recorded in 
http://www.w3.org/2011/01/27-ua-minutes.html#action01]
[NEW] ACTION: Jeanne to add the following to implementing for 5.2 
[recorded in http://www.w3.org/2011/01/27-ua-minutes.html#action02]
[NEW] ACTION: jim to rewrite 1.8.5 to include exception for financial or 
other web application criteria (can't go back or charge credit card 
twice) [recorded in http://www.w3.org/2011/01/27-ua-minutes.html#action03]
[NEW] ACTION: sharper to rewrite 1.11.2 to include (perhaps) size and 
behavior indicator. [recorded in 
http://www.w3.org/2011/01/27-ua-minutes.html#action05]
[NEW] ACTION: simon to rewrite 1.11.2 to include (perhaps) size and 
behavior indicator. [recorded in 
http://www.w3.org/2011/01/27-ua-minutes.html#action04]

[End of minutes]

Received on Thursday, 27 January 2011 19:54:20 UTC