IndieUI Task Force Voice Conference -- 05 Sep 2012

<scribe> scribe:jcraig\nagendum 1. "Admin Update: Repository; Tracker; Editor's Draft; TPAC"\nJoseph: 3D was a favorite of Katie ?

JS: I will post the 3D topic on list for a week

Recruiting Update; Polling for Telecon Time?

<scribe> scribe: jcraig

JS: rotating schedule may allow us to incorporate participation in ASIA/AU locales. Poll on me to complete.
... recruiting ongoing; e.g. Dominic is joining us today

Use Cases Walk-Through; Continued Discussion?

JS: Scott Gonzalez from jQuery also may be joining

<clown> http://www.w3.org/WAI/IndieUI/wiki/Use_Cases_and_Requirements

JS: Last phone call was productive going through minutes. Let's continue.

<clown> http://www.w3.org/WAI/IndieUI/wiki/Use_Cases_and_Requirements#S4:_Command_to_collapse_a_tree_branch.2C_expandable_grid_cell.2C_or_expandable_section

RS: reading from Use Cases "A user whose point of regard (focus) is on a UI object that support popups performs an action that causes the web application to render the popup. A popup could be a popup dialog box or a popup menu. The user would like to be made aware that either of these popup options are available and be able to cause the popup to render using a variety of device input interaction methods such as a keyboard command, a gesture, a voice command,

a right mouse click."

RS: Equivalent to Esc key, etc.

… "The device should post a notification to the UI object either by a bubbled event from a descendant object or directly.

The notification should not provide any device specific information about the devices that sent it.

The device must ensure that a keyboard device is capable of sending the notification."

JC: It was called EscapeRequest in the original. Two weeks ago was Dismiss. I don't have a problem with calling it dismiss.

RS: Next: Activation events

"A user whose point of regard (focus) is on a UI object, that can be activated, and would like to perform an action to activate it. Example UI objects that support activation are push buttons, radio buttons, checkboxes, and menu items. The action could be in the form of a tap, a gesture, a voice command, a mouse click, a keyboard key, or a command from an alternative input device."

JC: Don't need any additional events here. click suffices.

<smaug_> nope

RS: do we have click covered in the indieUI spec?

JS: I think a note regarding 'click' would be useful in the spec.

<scribe> ACTION: jcraig to add note regarding default DOM 'click' event as the main activation event [recorded in http://www.w3.org/2012/09/05-indie-ui-minutes.html#action01]

<trackbot> Created ACTION-6 - Add note regarding default DOM 'click' event as the main activation event [on James Craig - due 2012-09-12].

AB: seems like a good way to handle it for now

RS: S6 "A user whose focus is on a UI object that supports supports up and down navigation within the UI component would like to control the UI to move its current active item (usually rendered visibly as its point of regard) to the next item logically down within its internal navigation sequence. This might be the next item down in a listbox, tree widget, menu, menubar, or gridd, treegrid, select, or any other type of UI Component supporting this function.

action could be in the form of a gesture, a voice command, a right mouse click, a keyboard key, or an alternative input device. Some UI components may choose to force a selection of the item in response to the downward navigation notification."

<trackbot> Sorry, couldn't find user - could

… "We cannot assume we know all UI components capable of supporting this function.

Some UI components may move its internal point of regard back to the beginning of its navigation sequence after it reaches the end.

This movement is not response to a tab notification which should be designed to move among widgets and interactive controls that are not managed by another UI component."

RS: reqs: "The device should post a notification event to the UI object either by a bubbled event from a descendant object or directly. The notification should not provide any device specific information about the devices that sent it. The device must ensure that a keyboard device is capable of sending the notification."

JC: UIScrollRequestEvent with DOWN

<janina> scribe: janina

jc: One problem is no way to preload -- so need to indicate load more
... but Rich's use case unrelated ...
... Screen readers very fast moving around the dom
... Waiting for js to respond would be too slow
... Concerned this wouldn't be fast enough for sr users
... proposing sr can announce while app catches up

rs: Understood it was up to web app to manage focus, am I wrong?

jc: Cd handle dwn, but not tab
... As long as next logical element is loaded, sr can nav to it
... Rich, your approach would work, but would be slower

janina: +1 to jc

rs: So how to direct app to move down?

jc: We say let the sr move, we'll provide a way to detect so the app can catch up

dominic: Think we need a distinction between static pages with focusable objects; and other kinds of controls
... Situations where sr can't know what "next" is
... where setting the active descendent defines it
... If we're talking dom, then i agree, but if we're talking modern ARIA, then i don't think above approach solves it
... Think that's what Rich is getting at ...

jc: Would an additional set, focus blur, etc., resolve?
... Not sure I'm understanding the concern yet

dominic: currently only way to go to next active descendent is to trap keystroke

jc: Not so with Voice Over

dominic: Understand you can nav with VO, but how do you then select?

jc: After VO starts announcing the new focus, the web app gets a notification to allow it to update its state
... So, perhaps we need this regardless for Windows style sr's
... Other example, where the 'next' event not yet in the dom, not sure about how to handle that

dominic: Only major diff with Windows screen readers is that they're modal -- all keystrokes go to app
... only trick is that sometimes sr tries to interpret to decide whether keystroke intended for sr or app
... so this is common concept
... Cases I'm concerned about is where all possible values are not available via dom
... perhaps may be made accessible via treating them as list
... sr works fine, just can't explore screen with all possible values

jc: I'm concerned this not slow the user down

dominic: Not convinced we need a command for next/previous focus, just next/previous item within a focus control

jc: so perhaps registering where there's collection control
... and might alleviate performance control by only listening for particular events

<jcraig> Summary of discussion between James, Dominic, and Rich regarding "focus next item" event

<jcraig> James's concern was that blocking events may cause unnecessary lag in 99% of cases, where this was only necessary in 1%

<jcraig> Rich and Dominic brought up the point that this also applied where the "next focused element

<jcraig> " may not yet be in the DOM, so

<jcraig> this would be necessary even for event models that exposed separate focus and ATFocus events

<jcraig> performance concern was alleviated with implementation suggestion that this would only be useful/common on focusable collection widgets like grids and listboxes, and the rendering engine could expose additional actions (e.g. an AXAction on OS X) only on nodes that had these additional events registered.

<jcraig> in all other cases, the focus model would work as normal, but where this additional action was exposed, the AT could send first right of refusal to the web application, and fall back on its standard focus model if the event was not intercepted.

<dmazzoni> The only thing to possibly add is that maybe we shouldn't use the word "focus", or maybe we should clarify

<dmazzoni> It includes cases where a single control has focus, and it has an active descendant

<dmazzoni> But it also applies to real focus

<dmazzoni> Use case 1: a focusable control that implements an unusual graphical selection of some sort. The elements to be selected are not all in the DOM, so it's necessary for the web app to handle the next / previous commands

<jcraig> s/scribe:jcraig

<jcraig> agendum 1. "Admin Update: Repository; Tracker; Editor's Draft; TPAC"

<jcraig> Joseph: 3D was a favorite of Katie ?/scribe:jcraig\nagendum 1. "Admin Update: Repository; Tracker; Editor's Draft; TPAC"\nJoseph: 3D was a favorite of Katie ?/

<dmazzoni> Use case 2: a spreadsheet. The cells might actually be focusable dom elements with role=cell, but the grid is potentially infinite and not all of the cells are actually rendered in the dom at all times.

<dmazzoni> The web app might want to register event listeners for next, previous, up, down, left, and right on the container element, or on each grid cell

<dmazzoni> Another thought: for both of these cases, there should probably be events for next page, previous page, top of list, and bottom of list. (Page Up, Page Down, Home, End.)

<jcraig> I'm making a mess of this trying to get the agenda in order. I'm going to just past it in at the end. Perhaps Cooper can clean it up.

<dmazzoni> Right now I can't think of a case where a web app would need to handle "focus next item" and "focus previous item" outside of the context of a focusable container control.

<dmazzoni> That's it from me, thanks.

<jcraig> beginning of call unlogged by RRSAgent

<jcraig> Agendum 1. "Admin Update: Repository; Tracker; Editor's Draft; TPAC" taken up [from janina]

<jcraig> JS: Art, did you create a TPAC page for Indie-UI?

<jcraig> AB: I will create one similar to http://www.w3.org/wiki/Webapps/TPAC2012Meeting

<jcraig> … created a Webapps URI (link above)

<jcraig> JS: TPAC in Lyon, France from Oct 29 - Nov 2

<jcraig> JS: Hotel news is "shop around"; heard of better deals Expedia than the W3C rate

<jcraig> JS: Editors draft?

<jcraig> JC: Have a draft to check in, will go through the Mercurial tutorial today.

<jcraig> JC: Any other proposals to incorporate besides Andy Heath's and the one Joseph put together from the meeting last week

<jcraig> RS: Perhaps the 3D space features (zoom, tilt, yaw) should be tabled for a 2.0 release?

<jcraig> JC: I noted as much in editorial notes my working draft

<jcraig> Joseph: no objections to putting 3D events out of scope for ARIA 1.0

<jcraig> scribeNick: jcraig

<scribe> Scribe: James, Janina

- DRAFT -

IndieUI Task Force Voice Conference

05 Sep 2012

Attendees

Contents

Recruiting Update; Polling for Telecon Time?

Use Cases Walk-Through; Continued Discussion?

Summary of Action Items

Scribe.perl diagnostic output