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

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

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

27 Jan 2011

Attendees

Contents

What do enabled elements mean?

writing EIR 5.2.x

writing EIR 1.11.2

Summary of Action Items

Scribe.perl diagnostic output