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

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?

/ Jonas

Received on Wednesday, 10 February 2010 22:55:10 UTC