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

[James Robinson]

On Fri, Nov 5, 2010 at 6:52 PM, Adam Barth <abarth at webkit.org> wrote:

> On Fri, Nov 5, 2010 at 6:40 PM, James Robinson <jamesr at google.com> wrote:
> > On Fri, Nov 5, 2010 at 6:32 PM, James Craig <jcraig at apple.com> wrote:
> >> Ojan Vafai wrote:
> >>
> >> How is [ DOMAttributeChangeRequestEvent ] any different than
> >> DOMAttrModified? The spec claims it doesn't have the problems that
> >> DOMAttrModified has, but I don't see how that's the case.
> >>
> >> DOMAttrModified is a notification, but DOMAttributeChangeRequestEvent is
> a
> >> request. The reason these all inherit from UIRequestEvent is because
> they
> >> are all requests, not notifications. For example, the following
> sequences
> >> may occur in a real user scenario.
> >>
> >> DOMAttrModified
> >> 1. An attribute in the DOM changes (for whatever reason).
> >> 2. UA fires DOMAttrModified. This may recursively fire a series of other
> >> mutation events, hence the performance problems.
> >> 3. Web application (web page author) can do whatever, but this is a
> >> notification of the change, not a request to make the change.
> >>
> >> DOMAttributeChangeRequestEvent
> >> Path 1: ignored by the web application, so no DOM change occurs.
> >> 1. User performs some UI action. (e.g. VoiceOver user may press
> >> Ctrl+Opt+\)
> >> 2. AT interprets the intent of that action. (In VoiceOver, that key
> combo
> >> means expand or collapse a tree node.)
> >> 3. UA fires a single DOMAttributeChangeRequestEvent (e.g. "Web
> >> application, please change 'aria-expanded' value of Node to 'true'")
> >> 4. Web application (web page author) ignores the event, so no DOM change
> >> occurs.
> >> 5. AT receives the unsupressed/uncancelled event at the end of the
> bubble
> >> phase. (e.g. VoiceOver may beep to indicate to the user that no change
> >> occurred.)
> >>
> >> DOMAttributeChangeRequestEvent
> >> Path 2: received by the web application, which makes the change on the
> >> user's behalf.
> >>
> >> 1. User performs some UI action. (e.g. VoiceOver user may press
> >> Ctrl+Opt+\)
> >> 2. AT interprets the intent of that action. (In VoiceOver, that key
> combo
> >> means expand or collapse a tree node.)
> >> 3. UA fires a single DOMAttributeChangeRequestEvent (e.g. "Web
> >> application, please change 'aria-expanded' value of Node to 'true'")
> >> 4. Web application (web page author) has registered for the event, and
> >> receives it.
> >> 5. Web application (web page author) interprets the "request", and
> >> calls Node.setAttribute('aria-expanded', 'true')
> >> 6. Web application (web page author) cancels or suppresses the
> >> event. (e.g. "UA, I have received your request, and have changed this
> DOM
> >> attribute on your behalf.")
> >> 7. AT receives the supressed/cancelled event which indicates that the
> >> 'request' was successful.
> >> 8. AT can indicate to the user what happened. (e.g. VoiceOver might
> review
> >> the AX API and speak "expanded. 7 items enclosed.")
> >>
> >>
> >> Or, phrased another way:
> >> DOMAttrModified
> >> "I took your dollar. By the way, my dad and granddad are probably gonna
> >> some cash from you, too."
> >> DOMAttributeChangeRequestEvent
> >> Path 1: "Can I have a dollar? No? Okay."
> >> Path 2: "Can I have a dollar? Yes? Sweet."
> >
> > This is far worse than an async DOMAttrModified since it means that all
> code
> > that attempts to change an attribute has to deal with the case where the
> > page cancels the change or makes arbitrary other changes.  It also has
> worse
> > performance characteristics since it means that the browser would have to
> > fire the DOMAttributeChangeRequestEvent synchronously when it wanted to
> > change the attribute and wouldn't be allowed to batch up the events at
> all.
>
> 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?  What
happens if a single user action results in a large number of attributes
changing values?

I also agree with Ojan's comment above that the 'Request' naming scheme is
not very consistent with the rest of the web.

- James


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