Minutes: User Agent telecon 3 April 2014

from: http://www.w3.org/2014/04/03-ua-minutes.html
User Agent Accessibility Guidelines Working Group Teleconference 03 Apr 2014

See also: IRC log
http://www.w3.org/2014/04/03-ua-irc<http://www.w3.org/2014/04/03-ua-irc>
Attendees
PresentJeanne, Greg_Lowney, Jan, Kim_Patch, Kelly,
Jim_AllanRegretsChairJimAllan,
KellyFordScribeallanj
Contents

   - Topics <http://www.w3.org/2014/04/03-ua-minutes.html#agenda>
      1. full screen <http://www.w3.org/2014/04/03-ua-minutes.html#item01>
      2. screen orientation<http://www.w3.org/2014/04/03-ua-minutes.html#item02>
      3. Clipboard <http://www.w3.org/2014/04/03-ua-minutes.html#item03>
      4. DOM 3 <http://www.w3.org/2014/04/03-ua-minutes.html#item04>
      5. UI events <http://www.w3.org/2014/04/03-ua-minutes.html#item05>
      6. Input method (IME)<http://www.w3.org/2014/04/03-ua-minutes.html#item06>
      7. Custom elements<http://www.w3.org/2014/04/03-ua-minutes.html#item07>
   - Summary of Action
Items<http://www.w3.org/2014/04/03-ua-minutes.html#ActionSummary>

------------------------------

<trackbot> Date: 03 April 2014

we left off at 2.3.3

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

https://www.w3.org/users/myprofile/edit/password

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 Clipboard

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.
DOM 3

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

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html

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]

-- 
Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964