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

On Feb 10, 2010, at 2:54 PM, Jonas Sicking wrote:

> On Wed, Feb 10, 2010 at 1:32 PM, James Craig <jcraig@apple.com> wrote:
>> 
>> On Feb 9, 2010, at 5:26 PM, Jonas Sicking wrote:
>>> On Tue, Feb 9, 2010 at 5:20 PM, James Craig wrote:
>>>> On Feb 9, 2010, at 3:46 PM, Sean Hogan wrote:
>>>> 
>>>>> Currently IE has onpropertychange and Firefox / Opera have DOMAttrModified.
>>>>> Aren't they sufficient?
>>>> 
>>>> Even if DOMAttrModified wasn't threatened with deprecation and was
>>>> implemented consistently across all major browsers, it would still require
>>>> additional implementation on the part of a screen reader, but no screen
>>>> reader dev team is going to waste time implementing a feature at relies on a
>>>> deprecated event model.
>>> 
>>> They don't need to. They just need to set the attribute and rely on
>>> the fact that the browser will send *some* type of notification to the
>>> page. What that notification is currently varies between browsers, and
>>> likely will change at some point in the future, but that doesn't
>>> affect what the screen reader needs to do.
>> 
>> I don't agree with that logic. Most screen readers access the accessibility API rather than touching the DOM directly. This connection would likely rely on the browser to update the DOM based on a change to the accessibility API.
> 
> I don't understand how this changes things. If AT tools access and
> modify the DOM through an accessibility API rather than touching the
> DOM directly, they will still perform the same action today, when we
> have mutation events, as they will 2 years from now, when we have
> someCoolNewMutationNotificationAPI.
> 
> The only thing that I can see changing between now and then is what
> the *webpage* does in order to get notified about the changes to the
> DOM.
> 
> Am I missing something?

I tried to answer that with the remainder of my last email. Repeated here:

>> …it seems unlikely that a screen reader manufacturer would waste dev cycles on a conceptual programming model that may happen in the future but is extremely unlikely to be implemented by web authors until the notification model is standardized. It's almost the accessibility equivalent of asking web developers in 1999 to change all their images to SVG and 24-bit PNGs with the hope that, someday, browsers will support those image types.

That said, you're correct in that, "…if AT tools access and modify the DOM through an accessibility API rather than touching the
DOM directly, they will still perform the same action today…" I'm just pointing out that no one (web app authors, user agent developers, or assistive technology developers) is likely to spend any effort to further that goal until the notification model is standardized.