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

Hi Jonas,

The idea is that AT can (through API) cause the modification of an 
attribute, and the web developer should have a standard way to tell that 
modification happened (without js timer/polling). For example perhaps 
visual focus changes (aria-activedescedant). That said, I'm not sure if 
this pattern is used a lot today.

cheers,
David
On 09/02/10 3:42 PM, Jonas Sicking wrote:
> 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 21:04:17 UTC