RE: IE8 incompatibility issues (was: Re: Issue: IE 8 adds new DOM Properties for ARIA -- not compatible with other impls)

Thanks Aaron! From glancing at the TOC this document looks like it will help keep our implementations in sync. We’ll take a look at it over the next week or two and send comments and questions your way.

In general it would be good to get an official WAI ARIA UA Best Practices document, which we could either include in our existing WAI ARIA Best Practices doc or create separate ones for Web Developers and UA Developers.

From: Aaron M Leventhal [mailto:aleventh@us.ibm.com]
Sent: Thursday, March 13, 2008 11:16 AM
To: Marc Silbey
Cc: Anne van Kesteren; Charles McCathieNevile; Chris Wilson; Cullen Sauls; Dave Pawson; Jon Gunderson; David Poehlman; Richard Schwerdtfeger; Simon Pieters; w3c-wai-pf@w3.org; w3c-wai-pf-request@w3.org; www-archive@w3.org
Subject: RE: IE8 incompatibility issues (was: Re: Issue: IE 8 adds new DOM Properties for ARIA -- not compatible with other impls)


Take a look at the user agent implementors guide before going too much further. It will hopefully save you lots of work in the long run!
http://developer.mozilla.org/en/docs/ARIA_UA_Best_Practices


Much of the job of mapping ARIA  from the DOM is straightforward, but not all of it is.

- Aaron


Marc Silbey <marcsil@windows.microsoft.com>
Sent by: w3c-wai-pf-request@w3.org

03/13/2008 01:16 PM

To

Anne van Kesteren <annevk@opera.com>, Simon Pieters <simonp@opera.com>, Dave Pawson <dave.pawson@gmail.com>, "w3c-wai-pf@w3.org" <w3c-wai-pf@w3.org>, Chris Wilson <Chris.Wilson@microsoft.com>

cc

Cullen Sauls <cullens@microsoft.com>, Jon Gunderson <jongund@uiuc.edu>, Aaron M Leventhal/Cambridge/IBM@IBMUS, Charles McCathieNevile <chaals@opera.com>, David Poehlman <poehlman1@comcast.net>, "www-archive@w3.org" <www-archive@w3.org>, Richard Schwerdtfeger/Austin/IBM@IBMUS

Subject

RE: IE8 incompatibility issues (was: Re: Issue: IE 8 adds new DOM   Properties for ARIA -- not compatible with other impls)







I'm sorry for my delayed reply - as Chris mentioned, I was at MIX last week, on vacation until Tuesday and out of the office yesterday with a sinus infection...it's been a busy :)

Before I dive into the details of this thread, I want to step back and say that I'm excited for IE to be a part of ARIA and to be mostly in-line with other browser implementations with our beta - I think we're working together to make a very positive change in web accessibility.

We've been testing our implementation and will continue to test it using the test cases linked to in the best practices document. That said, we're clearly not done with ARIA yet. I appreciate the open feedback we’re getting on our implementation now and I'd like the feedback to continue to flow so we can release IE8 with as close to 100% ARIA interoperability with other browsers as possible.

Now I want to respond to the specific issue this thread started with:

Chris is right that our top goal for ARIA is to be interoperable with other browsers. He's also right that we did not intentionally add functionality to our ARIA implementation. I want to share our implementation details with the group to help answer folks questions:

Cullen (on CC) is one of our OM developers and he implemented ARIA:

------
"In IE, attributes need a name. The name needs to be defined such that we can provide programmatic access to it. For example, a name of “aria-busy” cannot be used in the COM accessor method names (get_aria-busy() is invalid syntax). Therefore, the property needs a way to expose both the dash-syntax as well as a way for the COM interface to access the property. Our convention in IE is to camel-case the name in place of the dash (aria-busy becomes ariaBusy). Then, we specifically say that the property’s true name is “aria-busy” such that it is parsed in the HTML and that get/setAttribute() methods work as expected (in IE8 mode). Because the attribute name contains a dash, the accessor syntax in JavaScript that uses the format of element.foo cannot use the true name of the property (element.aria-busy is invalid syntax), so IE exposes the property via the camel-case format.

All of this is done automatically by our tools that take our interface definitions (including property and method definitions) and generate the necessary code for them. Our ARIA implementation did not add anything in the way attributes are handled. The behavior being observed is just how IE exposes properties/methods that have a name that contains invalid characters for programmatic purposes."
------

If together we decide that we don't want to allow this DOM attribute behavior then we can either advise developers not to use it in the best practices document or we (IE) will look into doing extra work to remove the functionality in our ARIA implementation. I'd like to talk about these options and any others on one of the next wg calls.

Regards,
Marc


-----Original Message-----
From: Chris Wilson
Sent: Wednesday, March 12, 2008 3:19 PM
To: Anne van Kesteren; Simon Pieters; Dave Pawson
Cc: Jon Gunderson; Aaron M Leventhal; Charles McCathieNevile; Marc Silbey; David Poehlman; www-archive@w3.org
Subject: RE: IE8 incompatibility issues (was: Re: Issue: IE 8 adds new DOM Properties for ARIA -- not compatible with other impls)

Anne van Kesteren [mailto:annevk@opera.com] wrote:
>In IE8 you can do
>   element.ariaDisabled = true
>This is not possible in any other browser. In other browsers you are
>required to do
>   element.setAttribute("aria-disabled", "true")

Yup, that's clear now.  (To be more clear - the latter works in IE as well.)

>So if people use the former it will only work in IE8. Also, the idea was
>that ARIA scripts would work for older browsers as well as AT could simply
>read the DOM. If you introduce DOM attributes (such as ariaDisabled) this
>whould no longer be true.

That sounds like "we should never introduce DOM attributes again, and everyone should just always use getAttribute()?"

>> Yeah, I see that, and I've been thinking about that very issue.  Not
>> clear to me if Opera is happy if we simply make it so a standards-mode
>> DOCTYPE is necessary, as some of the invective is still demanding
>> removal of IE7 compatibility altogether.
>
>We're not happy with documentMode, but making X-UA-Compatible work just
>for standards mode would be an improvement. Just like doing IE8 mode by
>default is an improvement.

That sounds like a no.

-Chris