[webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications
James Craig
jcraig at apple.com
Fri Nov 5 18:32:19 PDT 2010
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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101105/60da72f6/attachment.html>
More information about the webkit-dev
mailing list