[webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications

[James Craig]

Sorry for the delayed response, Tony. My answers inline.

On Sep 3, 2010, at 9:35 AM, Tony Chang wrote:

> I'm curious what elements the UIRequestEvents apply to.  Does it fire at the document level or does it fire for specific elements like textareas?

Focused element (or AX-focused element) where appropriate. Document body otherwise.

For example, the scroll request events should be fired on the focused node so they can bubble up the DOM tree, so any node that needs to intercept it can. An example of when this may be inappropriate to fire on a lower-level node DOM is in the case of a browsing context that does not have a focus model where something always has focus; e.g. many touch-screen mobile devices do not have a focused element unless a form element is selected, or an assistive technology application is running on top of the rendering engine. In this case, firing at the document level would be appropriate.

> The addition of undo/redo is similar to the proposal to add this to the textInput event.  There was some discussion of that here:
> http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0082.html

This may be answered my response to Doug Schepers' related question in this email from the www-dom list.
http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0051.html

Quoting from that thread:

Doug Schepers wrote:
>>> Note also that HTML5 defines editing actions and APIs [6], specifically the UndoManager interface [7].

>>> [7] http://www.w3.org/TR/html5/dnd.html#undomanager

James Craig responded:
>> The main difference seems to be that our Undo and Redo *request* allows the web application to determine what (if anything) should be undone, or redone, where the HTML5 undo manager requires that the user agent make the change directly to the DOM or editable content. The UIRequestEvent interface allows the app to determine the outcome of the events based on the business logic of the app, which the browser does not know about.

>> 
>> The reason these are all called 'request' events is because they don't change anything. They only send a 'request' to the web application (not to the user agent) to make a change on the user's behalf. The web application can then intercept or ignore the event as needed. If ignored (if the web app hasn't registered that event listener, or if the event is not canceled with preventDefault) then the user agent or assistive technology can fall back to whatever behavior is deemed appropriate, including then using the HTML5 undo manager.


Back to Tony's email:

> Ojan also proposed renaming the textInput event to just beforeInput because it seems like it can apply to more than just text (e.g., undo'ing the insertion of an image).  Do you think the use of textInput/beforeInput would meet the use cases needed by UIRequestEvent?

In some cases, it may be appropriate, but my response to the previous question may provide additional understanding of why textInput/beforeInput is not sufficient, and why these two proposals are not mutually exclusive, even if they do overlap in some places.

As I stated in the bug tracker comments, the W3C DOM and PF working groups discussed this, and the outcome was to work on a standalone specification as a joint effort of the two groups. The initial document editors will likely be Doug Schepers (W3C staff contact for www-dom) and me. From the teleconference discussions, these will be an add-on to DOM 3 Events and/or ARIA 1.0, because both of those documents are currently in Last Call. The only major change to the proposal so far that we're discussing a new method to the Event object (perhaps 'suppressEvents' or 'suppressRelatedEvents') so that we don't have to cancel the event by overloading the original use of the preventDefault method.

Thanks for your questions. We realize the proposal may not be clear unless the reader knows a lot about 1) screen readers and 2) WAI-ARIA, but we hope to improve the understandability of the document in future iterations.

Cheers,
James Craig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101027/bdde13e8/attachment.html>