- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Mon, 29 Dec 2008 09:52:15 -0600
- To: James Craig <jcraig@apple.com>
- Cc: Aaron M Leventhal <aleventh@us.ibm.com>, Boris Zbarsky <bzbarsky@MIT.EDU>, Joseph Scheuhammer <clown@utoronto.ca>, Jim Allan <jimallan@tsbvi.edu>, w3c-wai-ua@w3.org, w3c-wai-ua-request@w3.org, WAI XTech <wai-xtech@w3.org>, wai-xtech-request@w3.org
- Message-ID: <OF7D67CEB9.94674637-ON8625752E.0056B260-8625752E.00573141@us.ibm.com>
This email is a bit hard to follow as I think my reply is to different people. Mutation events also tell an AT whether something has changed in the DOM, like a node removal or addition. Imagine marking a live region with ARIA but not telling the AT when a node was added - like text in a chat log. The mutation events may not be processed directly - the browser may translate these to accessibility API change events. Assuming that the property change events are the only things that are interesting to the AT is a false assumption. I agree that the ATs should not be forced to poll anything. They have plenty of other things they need to manage and polling will result in a very slow response. Rich Schwerdtfeger Distinguished Engineer, SWG Accessibility Architect/Strategist blog: http://www.ibm.com/developerworks/blogs/page/schwer James Craig <jcraig@apple.com > To Sent by: Jim Allan <jimallan@tsbvi.edu> w3c-wai-ua-reques cc t@w3.org Richard Schwerdtfeger/Austin/IBM@IBMUS, Boris Zbarsky <bzbarsky@MIT.EDU>, 12/18/2008 07:19 Aaron M PM Leventhal/Cambridge/IBM@IBMUS, Joseph Scheuhammer <clown@utoronto.ca>, WAI XTech <wai-xtech@w3.org>, wai-xtech-request@w3.org, w3c-wai-ua@w3.org Subject Re: ARIA should require DOM mutation event support for compliance. Rich Schwerdtfeger wrote: There needs to be some formal way for the AT to register and be notified of document mutation events whether they are through the DOM API or not. There are platform accessibility API that can be used to allow the AT to listen for these types of change events and not necessarily by accessing the DOM. To which Jim Allan replied: UAAG20 currently has the following success criteria [1] related to programmatic access by other technologies. Do they cover ‘notification of documentation mutation events?’ If not, is a new criteria needed (please provide proposed language)? Or, is the ‘notification’ assumed and elaboration should be provided in the techniques document? The requirement of DOM mutation events isn't a solution for UA providing notification to an assistive technology; it is a solution for making client-side scripts operable by receiving notifications from an assistive technology. Part of the idea is to make ARIA more compatible with MVC-style notifications and data bindings: design patterns that allow the visual display view is automatically synced no matter how the underlying data model is changed. For example, if the client-side script or the AT determines that a state or property (aria-activedescendant on a tablist, for example) should be changed, either one can change the DOM directly, and the CSS can by updated by the browser. If the script needs to make a secondary change based on that DOM change (such as displaying the appropriate tabpanel), the script can register for a notification of that particular DOM change, and update the view accordingly. This way, the application display can remained synced whether it's being changed by the AT, UA, or the client-side application itself. The view could be synced by forcing the script to poll for changes, but sending a change notification provides for the most flexibility and highest performance. Jim Allan also wrote: 2.1.6 Properties: If any of the following properties are supported by the accessibility platform architecture, make the properties available to the accessibility platform architecture: This criteria takes care of perceivability, but the problem one of operability. For example, on behalf of a disabled user, an assistive technology may tell a user agent to update a property in the DOM, but without DOM mutation events, there isn't any way for the UA to notify the web application script that the change has occurred, effectively making some web app controls inoperable. The DHTML Style Guide is trying to change this by advising that script authors all use the same key commands, but I think a more robust approach is to allow the native OS, AT, or UA to change the states and properties directly–let the user control that widget however they are used to controlling that type of widget on their native system–and tell the web application to update itself based on the user's changes. That said, I'm not sure that this requires a change to UAAG 2.0. All accessible UAs already change the DOM as appropriate on behalf of the AT, so this is just an extension of existing behavior. UAs already change the DOM on behalf of the UA, but the only way for a web application to react to that change is to constantly poll for any and all changes–not a very maintainable or well-performing solution. If there were a change required to UAAG 2, it would probably need to be in the operability section. Something like, "If a web application maintains a local representation of accessibility API roles, states, or properties (such as ARIA attributes), the user agent must provide a method to notify the web application when a change occurs to one of those roles, states, or properties." This kind of statement seems more appropriate for ARIA than for UAAG, so that's why I raised it an an issue for ARIA 1.0. Boris Zbarsky wrote: There could be a custom event for this one situation dispatched by the UA, for example. What the event would be would need to be standardized, of course. Alternately, page authors could poll the attribute value, without relying on mutation events at all. Even more alternately, authors could ignore the SHOULD-level requirement. The point being that none of this actually requires mutation events. If there is a more limited way to provide a general "ARIA state or property" changed event, I'll recant, but creating a new type of event would take a while to standardize and would be even longer before most user agents implement such a change. Using the client-side script to poll for changed attributes on everything is a very poor solution, and effectively turns a "rich" internet application into a sluggish resource hog for anything but the most basic interactions. James
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic01920.gif
- image/gif attachment: ecblank.gif
Received on Monday, 29 December 2008 15:53:02 UTC