In five years, ARIA-unaware browser share will being to approach zero. Let's not just design for next year.
-----Original Message----- From: Simon Pieters [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 5:27 PM To: T.V Raman; Marc Silbey Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Chris Wilson; Cullen Sauls; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected]; [EMAIL PROTECTED] Subject: DOM attributes for ARIA (was: Re: IE8 incompatibility issues) On Fri, 21 Mar 2008 00:24:37 +0100, T.V Raman <[EMAIL PROTECTED]> wrote: > > As a Web developer, I would vote in favor of retaining the > element.ariaFoo properties, and encourage other browser vendors > to support > that in upcoming versions. We've dropped namespace support in the > name of developer and author convenience; AIUI, namespace support was dropped because ARIA needed to work in HTML and it was desired for it to be consistent syntax-wise and DOM-wise between HTML and XML and between shipped browsers; the convenience benefit was more of a side-effect. http://lists.w3.org/Archives/Public/www-tag/2008Mar/0028.html > this falls in the same > bucket. Not really, IMHO. > Writing > e.ariaChecked = true > is far easier than the more convoluted > e.setAttribute(...) It's more convenient, indeed, but: the attributes won't get updated properly in ARIA-unaware browsers (like IE7 or Safari 3) so ARIA-aware ATs can't just read the DOM and get the right ARIA information. AIUI, it is desirable that ARIA-aware ATs are able to work with ARIA-unaware browsers, and hence only setAttribute() should be used. -- http://lists.w3.org/Archives/Member/w3c-wai-pf/2008JanMar/0348.html -- Simon Pieters Opera Software
