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:[EMAIL PROTECTED]
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; 
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected]
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 <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]

03/13/2008 01:16 PM

To

Anne van Kesteren <[EMAIL PROTECTED]>, Simon Pieters <[EMAIL PROTECTED]>, Dave 
Pawson <[EMAIL PROTECTED]>, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, Chris 
Wilson <[EMAIL PROTECTED]>

cc

Cullen Sauls <[EMAIL PROTECTED]>, Jon Gunderson <[EMAIL PROTECTED]>, Aaron M 
Leventhal/Cambridge/[EMAIL PROTECTED], Charles McCathieNevile <[EMAIL 
PROTECTED]>, David Poehlman <[EMAIL PROTECTED]>, "[email protected]" 
<[email protected]>, Richard Schwerdtfeger/Austin/[EMAIL PROTECTED]

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; [email protected]
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:[EMAIL PROTECTED] 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

Reply via email to