Re: Agenda: DOM3 Events Telcon, 21 April 2010

Hi Doug, I'd like to address the comments that this is partially covered by the HTML5 Undo Manager and WheelEvent. My comments inline below.

Also, please familiarize yourself with the basic interface of VoiceOver on iOS devices, because this will likely come up in the discussion.

Direct link to a demo video (5 minutes, Quicktime MOV format)
http://movies.apple.com/media/us/iphone/2009/accessibility/apple-ed-accessibility-iphone_navigation-us-20090909_r640-9cie.mov

Someone also reposted a lower-quality version on YouTube.
http://www.youtube.com/watch?v=WxQ2qKShvmc


On Oct 12, 2010, at 9:15 AM, Doug Schepers wrote:

> Agenda:
> * discussion of UI Independence for ARIA proposal [1], ISSUE-135 (30 minutes)
> * overview of UIScrollRequestEvent, UIValueChangeRequestEvent, and DOMAttributeChangeRequestEvent interfaces [2] (10 minutes)

> [2] http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html


…snip…

> We are inviting some of the WAI Protocols and Formats WG to discuss these issues with us.  We have many issues to cover, so we will be adhering to a strict queue for this telcon.
> 
> There are two separate proposals to add features to DOM3 Events to get editing actions, the UIRequestEvent Interface (with events like 'UndoRequest', 'RedoRequest', 'EscapeRequest', and 'DeleteRequest') [2], and the 'beforeInput' proposal [3], which have some overlap in intent and use cases.
> 
> 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

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.

I also believe that WheelEvent is an inappropriate alternative to our UIScrollRequest proposal, because ours is a semantic request from the user agent or assistive technology to the web application (which could be triggered by any number of low-level physical events), whereas a WheelEvent is a low-level physical event that is only appropriate to trigger with a pointer scroll event. For example, UIScrollRequest could be triggered by any number of events, including AT API events, mainstream UA keypress events (such as SpaceBar, PageDown, etc). Squeezing API or keyboard events into a physical MouseEvent designed specifically for mouse wheels (even if it could be also be used for physical trackpad events) seems like a bad idea.

We can discuss this more on the call tomorrow.

Thanks,
James