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

On Wed, Feb 10, 2010 at 3:38 PM, James Craig <jcraig@apple.com> wrote:
>
> 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.

Ah, I understand your argument now. I mostly agree, though I think
that web authors are more interested in what works in browsers than
what standards say. That has been my experience over the years. I also
have some other reservations with regards to if authors will do
anything at all when it comes to anticipating the browser modifying
the page. But I already expressed those reservations so I won't repeat
them here.

In any case, I don't think mutation events is the path forward here.
We at mozilla want to phase them out due to the various problems that
they have, and my guess is that microsoft won't implement them for the
same reason. This won't change no matter what the spec says.

/ Jonas

Received on Thursday, 11 February 2010 00:07:21 UTC