- From: Doug Schepers <schepers@w3.org>
- Date: Sun, 14 Feb 2010 19:53:03 -0500
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- CC: James Craig <jcraig@apple.com>, David Bolter <david.bolter@gmail.com>, Jonas Sicking <jonas@sicking.cc>, "public-hypertext-cg@w3.org" <public-hypertext-cg@w3.org>, Sean Hogan <shogun70@westnet.com.au>, "w3c-wai-pf@w3.org PF" <w3c-wai-pf@w3.org>, w3c-wai-pf-request@w3.org, "www-dom@w3.org" <www-dom@w3.org>
Hi, Rich- Richard Schwerdtfeger wrote (on 2/14/10 7:02 PM): > James, I know you know this but for the rest - this change will break > more than just screen readers. It will break magnifiers, alternate input > devices, etc., and accessibility test tools across all the platforms. We > need to consider a deprecation runway to get these applications to > adapt. These applications just don't sit there and poll the browser. > Essentially, if we are not careful we will put the whole ecosystem > casters up. > If this is being planned we should look at the typical development > release cycles for the major ATVs. and time it properly. > > What I would do is state that an event is being deprecated and give ATVs > a runway to switch over before turning off the old event model. Like > anything else, the ATs will still be left with the baggage of supporting > the old browsers. For example, they are still saddled with IE6 support > as many customers have no reason to switch. We should also consider > doing the unthinkable and tell the ATVs the browser release time frame > for this change. I'm a bit confused. None of the events being considered for deprecation are currently supported in any version of Internet Explorer: not Mutation Events in general or DOMAttrModified in particular; not DOMActivate; and not DOMFocusIn or DOMFocusOut. Some of them are supported in Firefox, Opera, or WebKit, but not universally. As far as we can tell, very little Web content uses these events. Unless there are implementations of these events in the AT UAs themselves, I don't quite understand what we would be breaking. Can you expand on that, with some specific examples? The deprecation strategy we have outlined is exactly intended to transition from these poorly-supported events to equivalents which, by their more efficient design, are apt to be implemented more widely and thus enable better accessibility. Note again that we are not removing the events, but deprecating them in favor of replacements. If I'm misunderstanding your concern, or missing some specific part of the ecosystem, please let me know. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Received on Monday, 15 February 2010 00:53:33 UTC