User Agent Accessibility Guidelines Working Group Teleconference

03 Apr 2014

See also: IRC log


Jeanne, Greg_Lowney, Jan, Kim_Patch, Kelly, Jim_Allan
JimAllan, KellyFord


<trackbot> Date: 03 April 2014

we left off at 2.3.3

<jeanne> https://www.w3.org/users/


blog about password change http://www.w3.org/blog/2014/03/w3c-password/

<scribe> scribe: allanj

open item 2

js: suggest having a use case for important issues.

gl: important - full screen, screen orientation, pointer lock. others are speculation, haven't read the spec in detail.

full screen

<Greg> Jackie uses an on-screen keyboard that lets her "type" by hovering a head pointer over buttons on the on-screen keyboard window. If she starts a web app which switches into full-screen mode and covers up the on-screen keyboard window, she is unable to perform any input, including commands to exit that mode. She's totally stuck, and has to request human assistance. If the full-screen API took...

<Greg> ...into consideration reserved areas of the screen, such as those being used by such critical utilities, the browser would not have covered the tools she relied on.

screen orientation


jr: ATAG has a copy/paste requirement for within document.
... want the information copied to retain accessibility information.

js: copy/paste should include accessibility information, except where the a11y information is outside the selection area
... this is a question.
... should there be an exclusion for accessibility information that is outside of the selection to be copied. (i.e. aria-labelledby)

<Jan> http://www.w3.org/TR/2013/CR-ATAG20-20131107/#sc_b122

<Jan> B.1.2.2 Copy-Paste Inside Authoring Tool (WCAG): If the authoring tool supports copy and paste of structured content, then any accessibility information (WCAG) in the copied content is preserved when the authoring tool is both the source and destination of the copy-paste and the source and destination use the same web content technology.


js: say something like ... if DOM3 does this, then do xxx.

gl: AT is watching DOM, user speaks a command to activate a control, the AT searches the DOM to activate the control. or


gl: the content of some field is updated, does the AT get the information
... input events may apply to UI events. they say only mouse and keyboard. what about speech or switch.

kp: with speech you mostly use the keyboard emulation. except, you can say the name of a button, single word buttons work poorly. e.g. email -- to: from: and the cursor moves, rather than jumping to the field.
... there are a host of problems. should look at indieUI. ultimately, the user needs to be able to change commands or names of actions for speech.

gl: dom3 event type list related to UI events. possibly have speech_begin, speech_end, special buttons for switch users

UI events

discussed indiu UI and touch

Input method (IME)

seems related to UI events, and indieUI.

ja: do we need a use case?

all: no need for use case

Custom elements

gl: does aria allow the relabeling of custom element?
... if the custom element uses some new novel event that may break AT.

js: say - must communicate name, role, and state

jr: no, more than that, because it will be entirely new - name, role, state of what?
... if author can define a new machine readable form....maybe AT could read the same machine readable information and create something to communicate to the user

gl: thats a possibly, right

jr: a11y is rarely thought about when creating a command

use case - screen reader user reading a document with custom elements, the screen reader must be able to communicate some accessible name, the content within, and any actions associated with it.

jr: for existing DOM components/controls AT know what behaviors are expected and can communicate human understandable info to the user, and interact with the elements in a machine readable way

ja: scenario - list name element <ln>, programmatically associate a name with the <li> in a list. how is that communicated to the AT

gl: thumbnail control, use mouse wheel to zoom the thumbnail to full size. component made of 3 scroll bars, and a graphic

jr: what's missing, is some behavior/event, something happens on the screen, but that info isn't communicate to AT

ja: should add " can aria be used to label custom elements? what happens when new element falls outside realm of aria. then AT knows nothing of new element. this is a PF issue"

<Greg> An example of a custom element might be a thumbnail map that shows a tiny version of the document with a highlighted region indicating the visible portion, and allowing the user to drag the highlight to move the visible region (scroll the main window), and also use the scroll wheel to zoom in and out. How would this be conveyed to a blind user, how would a speech input utility drive it, etc.?

js: need to close out editorial comments. edit the document to incorporate necessary changes.

ja: regrets for next week.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-04-03 18:32:54 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: allanj
Inferring ScribeNick: allanj
Default Present: Jeanne, Greg_Lowney, Jan, Kim_Patch, Kelly, Jim_Allan
Present: Jeanne Greg_Lowney Jan Kim_Patch Kelly Jim_Allan
Found Date: 03 Apr 2014
Guessing minutes URL: http://www.w3.org/2014/04/03-ua-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]