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

Note that there is nothing stopping implementations from having
internal events similar to DOMAttrModified. There is no reason to
limit accessibility tools to only use the feature set exposed to web
pages. Browsers should feel free to expose any API internally towards
accessibility tools that help these tools work as well as possible. We
do this internally in firefox a lot.

/ Jonas

On Tue, Feb 9, 2010 at 12:21 PM, James Craig <jcraig@apple.com> wrote:
> 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
>

Received on Tuesday, 9 February 2010 20:43:30 UTC