- From: James Craig <jcraig@apple.com>
- Date: Thu, 18 Dec 2008 17:19:11 -0800
- To: Jim Allan <jimallan@tsbvi.edu>
- Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, Boris Zbarsky <bzbarsky@MIT.EDU>, Aaron M Leventhal <aleventh@us.ibm.com>, Joseph Scheuhammer <clown@utoronto.ca>, WAI XTech <wai-xtech@w3.org>, wai-xtech-request@w3.org, w3c-wai-ua@w3.org
- Message-Id: <27FAB399-84F9-4220-8439-3F59F454192B@apple.com>
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
Received on Friday, 19 December 2008 01:19:56 UTC