Re: Deprecation of DOMAttrModified

Hi, James-

Thanks for following up with this.  I mentioned before that because 
Mutation Events are especially poor performance-wise, it's actually a 
serious accessibility issue that ARIA relies upon DOMAttrModified. 
Basically, the problem is that there is overhead involved in the DOM 
Events model, and that changes made to the DOM as a result of a mutation 
event would trigger additional mutation events, etc., setting up race 
conditions and eating up memory.  This is exacerbated in the AT case, 
because users of AT may not have other means to detect when the system 
is locked up or busy (the little spinning hourglass or beachball), so if 
they don't receive immediate feedback, they may inadvertently trigger 
the same mutation event multiple times trying to activate a control.

The use case you describe is real, and applies to more than AT, so we 
definitely need to have a replacement for the functionality, but one 
which is less likely to lead to a bad user experience.  There are a 
couple solutions we are working on that don't rely upon events, but 
rather a new notification system (perhaps based on the selectors API) 
[1][2].  Because it doesn't have the overhead of the event object 
initialization and event propagation path, and is asynchronous, it can 
actually perform much more responsively.

The benefit to the selectors-based proposal, in my opinion, is that you 
can listen for specific values in the notification registration itself. 
  For example, an author could use the following code to call functions 
based on the attribute value, rather than embedding that switch logic in 
the function:

  document.watchSelector("[aria-expanded=true]", doSomething);
  document.watchSelector("[aria-expanded=false]", doSomethingElse);

We will continue to develop these ideas, and hope to have a working spec 
that can be implemented as a replacement for 'DOMAttributeModified' very 
soon.  In any case, we will not recommend that 'DOMAttributeModified' is 
removed from implementations until the replacement is ready... this is 
the whole point of deprecating it, rather than removing it.

I hope this addresses your concern.

[1] http://www.w3.org/2008/webapps/wiki/MutationReplacement#AttributeChanged
[2] 
http://www.w3.org/2008/webapps/wiki/MutationReplacement#Replacing_Traditional_Mutation_Events

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


James Craig wrote (on 2/9/10 3:21 PM):
>
> DOMAttrModified is deprecated, but as far as I can tell, there is no
> suitable replacement. We'll need this (or something equivalent) in order
> to allow platform-, modality-, and device-independant access on anything
> other than the default action, which could be determined via click or
> DOMActivate. For example, on a treeitem element DOMActivate could
> indicate the default action of selection, but without
> DOMAttributeModified, there is no way for the user's assistive
> technology to convey the intent of a non-default action, such as
> expanding or collapsing the tree node. This currently relies on the
> author to assign de facto standard key events such as the left and right
> arrow keys. The deprecation of DOMAttrModified blocks the ARIA 2.0 issue
> of device-independence.
>
>  From the spec:
> "*Warning!* the |DOMAttrModified|
> <http://dev.w3.org//2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-DOMAttrModified>
> event type is defined in this specification for reference and
> completeness, but this specification deprecates
> <http://dev.w3.org//2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#glossary-deprecated>
> the use of this event type."
>
> http://dev.w3.org//2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-DOMAttrModified
>
> For example, the iPhone screen reader interface is completely gestural,
> without a keyboard unless the user is editing a text field. Although
> there could be a gesture to let the user convey their intent ("expand
> this tree branch") to the screen reader and user agent, there is no way
> for the user agent to convey that intent to the web application.
> DOMAttrModified or an equivalent event allows the web application to be
> notified when the specific DOM change occurs (e.g. @aria-expanded
> changed from "false" to "true") so the web application can update any
> relevant view after the attribute value has changed.
>
> For what it's worth, I don't foresee much need for rest of the mutation
> events (I could live with their deprecation), but DOMAttrModified is
> very useful from an accessibility perspective.

Received on Wednesday, 10 February 2010 02:11:08 UTC