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

[James Craig]

On Nov 5, 2010, at 7:03 PM, James Robinson wrote:

> On Fri, Nov 5, 2010 at 6:52 PM, Adam Barth <abarth at webkit.org> wrote:
>> I could be misunderstanding, but it sounds like these events originate with the AT software rather then when the DOM is modified.  In that sense, they sound more like KeyDown than DOMAttrModified.
> 
> I see - in that case the name doesn't seem very good, if the expectation is that this event will only be generated from AT software and not by any other mechanisms that result in attributes changing values.  Do we need this for any attribute that could change values, or just AX-related ones?

The primary need is for assistive technology, but there are several cases where this is appropriate in a mainstream user agent. For example, some mobile devices have a "scroll to top" feature if you click on the status bar chrome just outside the web content view. For web apps with custom scroll views (e.g. those that accept touchstart and touchend), it may be appropriate for the user agent to fire a single UIScrollRequest with a scrollType value of TOP_LIMIT.

http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html#UIScrollRequestEvent

> What happens if a single user action results in a large number of attributes changing values?

Do you have something in mind that may cause this? Part of what needs to be specified is what the user agent should request (and how often) when it interprets the intent of a particular user action, and I don't foresee the need for piling on a series of DOMAttributeChangeRequests. 

There are some cases where UIScrollRequests or UIValueChangeRequests might pile up. The spec should probably handle the case of key repeat; for example, what happens if an author has registered for UIScrollRequest and the user falls asleep on the PageDown key. We may want a way for the app to say "suppress this series of repeated request events."

James

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