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

On Feb 9, 2010, at 1:03 PM, David Bolter wrote:

> That said, I'm not sure if this pattern is used a lot today.

As far as I'm aware, it's not used at all today, because there isn't a way to implement it.

That said, it's the only way I know of that will allow fully input-independent access to web applications. As the Web moves away from the standard 'desktop' interface that relies on a keyboard, alternate interfaces (touch screens, voice control, etc.) are arising as the primary input methods for mobile and other web-based devices.

The Multimodal Interaction Working Group may want to weigh in on this issue, too. A lot of their focus is spent on speech-controlled interfaces, which would benefit greatly from the deprecated, DOMAttrModified. 

James



On Feb 9, 2010, at 1:03 PM, David Bolter wrote:

> 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:38:10 UTC