Re: [webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications
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."
On Fri, Nov 5, 2010 at 6:32 PM, James Craig <jcraig@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. - James
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Fri, Nov 5, 2010 at 6:40 PM, James Robinson <jamesr@google.com> wrote:
On Fri, Nov 5, 2010 at 6:32 PM, James Craig <jcraig@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. Adam
On Fri, Nov 5, 2010 at 6:52 PM, Adam Barth <abarth@webkit.org> wrote:
On Fri, Nov 5, 2010 at 6:40 PM, James Robinson <jamesr@google.com> wrote:
On Fri, Nov 5, 2010 at 6:32 PM, James Craig <jcraig@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
On Nov 5, 2010, at 7:03 PM, James Robinson wrote:
On Fri, Nov 5, 2010 at 6:52 PM, Adam Barth <abarth@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/UserInterface...
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
Heh. There's clearly still a good deal of confusion about what the intended behavior here is. Well, I'm confused anyways. :) On Fri, Nov 5, 2010 at 9:32 PM, James Craig <jcraig@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.
I think this is the core of my confusion. In some cases I get that these events are requests. In this case, it's a request to change an attribute. But there are other cases where it seems like they have a default action. For example, when the user scrolls, we fire a UISrollRequest and if the web page does nothing, then the page scrolls, right? And if they user hits the delete key, we fire a DeleteRequest and delete if the web page doesn't cancel it. But then the AT software can also fire a DeleteRequest that does nothing if the web page doesn't cancel it? Am I misunderstanding? If the events are always requests with no default action, calling these request events might make sense, but then it seems that these would only be for AT software and should be named appropriately. My first intuition is that we should not try to do AT specific events *if* we can avoid it because web developers will largely ignore them, but I'd like to understand the current proposal first. *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."
Heh. I see they these are different. DOMAttributeChangeRequestEvent is not actually a notification that something changed or that something is about to change? On Fri, Nov 5, 2010 at 10:29 PM, James Craig <jcraig@apple.com> wrote:
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."
Actually, I'm not sure we need to worry about this. For example, we don't worry about this with keydown events. We'll just keep firing them until the user wakes up. :) Ojan
On Nov 10, 2010, at 3:40 PM, Ojan Vafai wrote:
Heh. There's clearly still a good deal of confusion about what the intended behavior here is. Well, I'm confused anyways. :)
On Fri, Nov 5, 2010 at 9:32 PM, James Craig <jcraig@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.
I think this is the core of my confusion. In some cases I get that these events are requests. In this case, it's a request to change an attribute. But there are other cases where it seems like they have a default action. For example, when the user scrolls, we fire a UISrollRequest and if the web page does nothing, then the page scrolls, right? And if they user hits the delete key, we fire a DeleteRequest and delete if the web page doesn't cancel it. But then the AT software can also fire a DeleteRequest that does nothing if the web page doesn't cancel it?
Am I misunderstanding? If the events are always requests with no default action, calling these request events might make sense, but then it seems that these would only be for AT software and should be named appropriately.
From another email to the list (On Nov 5, 2010, at 7:29 PM, James Craig wrote): 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/UserInterface...
My first intuition is that we should not try to do AT specific events *if* we can avoid it because web developers will largely ignore them, but I'd like to understand the current proposal first.
I agree, but even if these were AT-specific events, I don't think we could avoid them. There is currently no good way for assistive technology to control a web application. The existing de facto approaches are a crappy workaround at best. That's what the problem description is about: http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterface...
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."
Heh. I see they these are different. DOMAttributeChangeRequestEvent is not actually a notification that something changed or that something is about to change?
Correct. It's up to the web application to make any requested changes. In this case, to hand out the cash… or not. James
On Nov 5, 2010, at 6:40 PM, James Robinson wrote:
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.
No need to batch because these are only triggered by discrete user actions, and don't even need to be fired unless the web app author has registered for the event. Also, please note that much of the time, these would not be used in a mainstream interface. For example, you're NOT going to getting a series of synchronous UIScrollRequests when the user scrolls a mouse wheel. For that, you'd receive a series of asynchronous WheelEvents or ScollEvents. You might however, receive a single UIScrollRequest when the user pressed the PageDown key.
participants (4)
-
Adam Barth
-
James Craig
-
James Robinson
-
Ojan Vafai