Deprecation of DOMAttrModified (Was: DOMActivate vs. Activation Behavior)

On Feb 8, 2010, at 1:20 AM, Doug Schepers wrote:

> I had a nice chat with Gregory Rosmaita the other day, and he and I cleared up some possible disconnects on both our parts regarding the deprecation of 'DOMActivate'.  I incorporated the fruits of our discussion in the current editor's draft of the DOM3 Events spec [1], which I hope clarifies not only the details of activation behavior, but the intent and implications of deprecating 'DOMActivate'.
> 
> Here are a couple more important points that Gregory advised me to emphasize:
> 
> * 'DOMActivate' is not the same as "activation behavior". 

Thanks for that explanation, Doug. There is another issue for ARIA 2.0 that I noted on the PFWG list, now sharing here.

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 event type is defined in this specification for reference and completeness, but this specification deprecates 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.

Cheers,
James Craig