See also: IRC log
<trackbot> Date: 03 April 2014
we left off at 2.3.3
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.
<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.
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> 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
... 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
discussed indiu UI and touch
seems related to UI events, and indieUI.
ja: do we need a use case?
all: no need for use case
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.
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]