See also: IRC log
<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
<scribe> scribe: jcraig
JS: rotating schedule may allow
us to incorporate participation in ASIA/AU locales. Poll on me
... recruiting ongoing; e.g. Dominic is joining us today
JS: Scott Gonzalez from jQuery also may be joining
JS: Last phone call was productive going through minutes. Let's continue.
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.
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
... 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> 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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Joseph: 3D/agendum 1. "Admin Update: Repository; Tracker; Editor's Draft; TPAC"\nJoseph: 3D/ Succeeded: s/agendum 1/scribe:jcraig\nagendum 1/ WARNING: Bad s/// command: s/scribe:jcraig Found Scribe: jcraig\nagendum 1. "Admin Update: Repository; Tracker; Editor's Draft; TPAC"\nJoseph: 3D was a favorite of Katie ? Found Scribe: jcraig Inferring ScribeNick: jcraig Found Scribe: janina Inferring ScribeNick: janina Found ScribeNick: jcraig Found Scribe: James, Janina Scribes: jcraig\nagendum 1. "Admin Update: Repository; Tracker; Editor's Draft; TPAC"\nJoseph: 3D was a favorite of Katie ?, jcraig, janina, James, Janina ScribeNicks: jcraig, janina Default Present: hober, Michael_Cooper, Janina_Sajka, +1.408.423.aabb, jcraig, Caroline_Jay, Dominic, Art_Barstow, Rich, Joseph_Scheuhammer Present: Janina_Sajka Joseph_Scheuhammer Rich_Schwerdtfeger James_Craig Michael_Cooper Art_Barstow Edward_OConnor Dominic_Mazzoni Caroline_Jay WARNING: Replacing previous Regrets list. (Old list: Andy_Heath, Doug_Schpers) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ Andy_Heath, Doug_Schepers Regrets: Andy_Heath Doug_Schepers Got date from IRC log name: 05 Sep 2012 Guessing minutes URL: http://www.w3.org/2012/09/05-indie-ui-minutes.html People with action items: jcraig WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]