Re: ARIA should require DOM mutation event support for compliance.

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