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