Hi, my name is Tony Ross and I’m one of the Program Managers for Internet Explorer. As JP mentioned in an earlier post, the IE Team has been working to make IE8 the most accessible web browser possible. We have also been working on improving interoperability and making things easier for web developers. Following these goals, I want to introduce you to a change we’ve made in the RC aimed at improving our support for ARIA, a syntax for making dynamic web content accessible. I’ll walk you through what IE did before, what IE does now, and what this change means overall.
What did IE do before?
We added support for ARIA in Beta 1, but some differences in syntax existed depending on the browser mode. In IE8 Standards Mode you could access ARIA attributes from script using the syntax defined in the standard:
value = elm.getAttribute(“aria-checked”);
In the compatibility modes, IE7 Mode and Quirks Mode, you needed to use a camelCased version of the attribute name:
value = elm.getAttribute(“ariaChecked”);
You may find the different syntax odd at first, but it results from how IE handles attributes and properties. Properties exist on script objects and are of the form elm.property. As a convenience to developers, IE automatically maps attributes to properties. When the name of a native attribute contains a dash, IE adjusts it to produce acceptable property syntax:
value = elm.ariaChecked;
Without this adjustment, each dash in the name would be treated as a minus sign by the script interpreter:
value = elm.aria-checked; // Attempting to access a dashed property
value = elm.aria – checked; // What the dash means to the script interpreter
Older versions of IE and the compatibility modes in IE8 use the same name for both properties and attributes. Consequently, adjusting the name for properties affects the getAttribute syntax as well. This adjustment applies to all native attributes with dashed names, not just those that are part of ARIA. IE does not alter unrecognized attributes, and will leave names like “foo-bar” alone. IE8 Standards Mode avoids this conflict altogether by maintaining separate names for attributes and properties.
What does IE do now?
We did not initially support the standardized ARIA syntax in IE7 Mode or Quirks Mode due to the issue mentioned above. Backwards compatibility is paramount for these modes, so we are cautious about making changes to their behavior.
Later we received feedback expressing concerns about having different syntaxes for ARIA. This feedback came from web developers, Assistive Technology Vendors, and members of the standards community. Their concerns primarily focused on pages not ready to run in IE8 Standards Mode, where adding ARIA support would require choosing one of the syntaxes or doing extra work to support both.
Based on this feedback, we reexamined IE’s handling of ARIA. Older versions of IE do not have ARIA support. They treat ARIA attributes as unknown and do not camelCase their names. This means that script can manipulate ARIA in these versions using the standardized syntax, although the information is not exposed via APIs like Microsoft Active Accessibility (MSAA).
Taking this information into consideration along with the feedback we received, we decided changing IE8’s behavior was the best option. IE8 will now preserve the dash for ARIA attribute names in all modes. As part of this change, we are eliminating camelCased ARIA properties to avoid the naming conflict discussed above. You now only need to use the standardized syntax to add ARIA support in IE8, no matter which browser mode is being used:
value = elm.getAttribute(“aria-checked”);
What does this change mean?
For Web Developers
This change should make using ARIA in your pages even easier. We have removed the need to support multiple syntaxes for ARIA and have left you with just one.
- One syntax that works across all IE8 modes
- One syntax that is interoperable with other browsers
- One syntax that is consistent with the standard
For End Users
This change should make even more sites accessible in IE8 because all IE8 modes now support the ARIA standard.
This change should help increase the adoption of the standardized syntax for ARIA, since developers no longer have to worry about dealing with an alternate syntax.
We’ve taken the multiple syntaxes for ARIA supported by IE8 since Beta 1 and reduced them down to one that is consistent with the standard. We’ve made this change because we believe it will have a positive impact on developers, end users, and ARIA in general. As always, we are grateful for the feedback we receive from the community as it plays a key role in making these types of decisions.