Legacy defeats consistency in IE 8′s Web 2.0 accessibility effort

Cooperating on Web 2.0 Accessibility

UPDATE: Microsoft has now listened, and is changing this in IE8 RC1. It is very much appreciated. The original article follows:

It’s exciting that IE 8 Betas have WAI-ARIA support in order to enable Web 2.0 and Ajax accessibility, and that Microsoft joined the W3C PFWG to work on standardization. With all of the major browser vendors collaborating on the WAI-ARIA web accessibility standard, addressing the modern, dynamic web seems in reach. We’re even collaborating on platform accessibility API specifics for ARIA, which is a major step forward to allowing a consistent experience for users with disabilities. The scope of cooperation between browser vendors on the technical aspects of accessibility is truly unprecedented. There is already an amazing amount of support for WAI-ARIA in browsers, JavaScript toolkits, assistive technologies and more.

It’s enjoyable working with Microsoft accessibility engineers. They care about what they do, and are easy to get along with. Except for one issue, we have always either agreed or could at least relate.

IE 8′s WAI-ARIA Incompatibility

Unfortunately, a disagreement has come up on an important compatibility issue.

In IE 8 Beta 1 Microsoft introduced their own unique method for setting ARIA properties without notifying the working group.  The feature was added to IE 8 standards mode as well as legacy modes. This was an unintentional side effect of IE’s legacy code. By adding a new feature and not implementing the existing standard, they broke something fundamental — how developers write JavaScript to change an ARIA property.

Here’s a concrete example: if a user presses the right arrow in a JavaScript slider, the slider’s keydown event handler should be able to increase the slider’s aria-valuenow property such that it is reported to any assistive technology such as a screen reader. It should work the same way no matter what browser you use. In this case, the author simply uses slider.setAttribute(“aria-valuenow”, theNewValue) and it normally just works. A screen reader user will hear the new value or be able to read it on their braille display. This is fundamental to ARIA — the ability to create interactive widgets in JavaScript, which correctly report their updated properties as they change. Unfortunately IE 8 breaks this by interjecting a non-standard method for changing ARIA properties.

The behavior also depends on which of IE8′s three operating modes a page loads in. Two of these modes require authors to use a non-standard method to change an ARIA property. Here’s a quick summary:

  • Correct slider.setAttribute("aria-valuenow", '25'); // Firefox, Opera, Safari, IE8 Standards Mode
  • Incorrect slider.ariaValuenow = '25'; // IE8 in all modes, including “standards” mode

So does IE support the standard method of changing a property or not? Only in one mode — IE 8 standards mode, but it’s tricky to know when IE 8 standards mode will be used. On the other hand, the non-standard method (we’ll call it ariaCamelCase) is supported in all IE modes. Only the standard is supported in other browsers. Many existing applications do not use IE 8 standards mode and it is realistic to say that many will not transition at the same time as implementing WAI-ARIA.

The Consequences of Incompatibility

The current state of affairs is going to create a mess. Authors will be confused about ARIA, because changing a property won’t work consistently. We’ll get a strange mixture of:

  1. Web apps that are only accessible in IE
  2. Web apps that are only accessible in Firefox and Opera/WebKit (once their ARIA and accessibility support is further along)
  3. Web apps that support both because they have made the transition to IE 8 standards mode
  4. Funky, messy code to check the user-agent string and attempt to get around the issue with browser-dependent code (exactly what the web is trying to get away from)

The whole situation is worsened by the fact that standards mode is not always the default. It depends on whether a page runs on an intranet, whether there is a doctype, and a whole host of factors. For most developers not versed in these details, the type of ARIA support you get in IE 8 will be a roll of the dice. Rather than face that confusion, developers are likely to use the nonstandard method, which confusingly works even in IE 8 “standards” mode.

No amount of documentation will prevent developer confusion. Users will be confused why some apps are accessible in one browser, and some in another. This will in turn slow down ARIA adoption. ARIA is built to make web apps accessible today.

Prioritizing Standards

Microsoft has also asked what can be done to enhance community trust in their handling of standards issues. Collaborative working groups are successful when the lines of communication are open, the implications of various strategies are discussed together, and participants follow up on issues. Microsoft never proposed that ariaCamelCase method should be a standard part of ARIA. However, when the community discovered the divergence back in March, just after Beta 1 we pointed out how important addressing this was for interoperability.  Microsoft agreed to move forward based on community consensus. They promised to look into a solution, and if none were feasible, at least warn authors not to use ariaCamelCase. They have not done any of these things. The community should not have to stumble upon these compatibility issues. Microsoft needs to communicate its awareness of the issues it is currently presenting, and help articulate the way forward.

While ariaCamelCase might be considered a neat feature, it is very likely not compatible with the future of ARIA where authors can define roles and properties. Naturally Microsoft has the ultimate say in what goes into it’s browser, but keeping this incompatibility makes a strong statement about how much it values the standards process and saving work and confusion for developers and users.

Microsoft doesn’t hold any ill intentions here. Understandably, Microsoft is not eager to add code that remove a feature which is arguably beneficial. They like the feature. Therefore, Microsoft should actually propose the technique as an official part of WAI-ARIA, and allow the community to accept or reject it. In fact, because it has currently not  been properly discussed, it does not currently address important issues. For example, it does author-defined properties. It does not address the cost to ARIA’s significant momentum. And as something non-standard and never proposed, it means other browsers have not implemented it and have no plans to.

ARIA is a great opportunity to solve many accessibility problems affecting the web.  If Microsoft wants to extend ARIA, that’s great; however, we must ask that Microsoft work with the community in good faith and extend ARIA with the full confidence that it’s right.

What are we asking Microsoft to do?

We’re asking Microsoft to keep WAI-ARIA from being convoluted by legacy code. Microsoft can ensure that all modes consistently support correct setAttribute() usage for changing ARIA properties. For the IE codebase it’s only necessary to add a condition to check for “aria-” properties when setting an attribute. It should not be a difficult change nor one that will cause a detectable performance hit.

We’re also asking Microsoft to communicate its awareness of the issues it is currently presenting, and help articulate the way forward. Microsoft can join the community in implementing whatever consensus is reached.

Accessibility is very important to both users and authors. Making it all simply work for users is more important than holding onto incompatibilities. Let’s do it right.

About these ads

13 Responses to Legacy defeats consistency in IE 8′s Web 2.0 accessibility effort

  1. [...] Legacy defeats consistency in IE 8’s Web 2.0 accessibility effort - Aaron Leventhal details a major problem with the current implementation of WAI-ARIA in IE8:  Microsoft introduced their own unique method for setting ARIA properties. Let’s hope that Microsoft are as good as their word and resolve this issue before IE 8 is out of beta. [...]

  2. Have you tried slider.setAttribute(‘ariaValuenow’, ’25′)? Because this in pre-IE8 Internet Explorer, you always have to use the property names for setAttribute (similar to div.setAttribute(‘className’, ‘something’) and label.setAttribute(‘htmlFor’, ‘myId’).

    This is not a new issue, and it would be understandable if they did not make an exception for ARIA in legacy mode.


  3. aaronlev says:

    Laurens, even if that suggestion works it is still nonstandard, so it still would require abstracting the basic operation of changing a property.

    I hear you on not making an exception for legacy mode, so I guess you agree they should fix it for what’s called standards mode?

  4. This is stupid.

    I guess I can concede that the camelCasing is a cool feature, It’s not often that I can say that about ie.. Using css filters to set opacity is particularly stupid. Having all kinds of weird proprietary things for adding event handlers is stupid. Not updating xmlhttprequest to work without needing to ask activex about it is stupid. Not being able to view visual markup languages with the XML parser is stupid. Not being able to incrementally load large flash movies if you use valid and sensible markup, is stupid. In some cases all they have to do is add an alias (or better, just change it to the correct way) but after a decade they still get it wrong, and of course it’s a shock that they have even implemented any of this aria stuff, given how technophobic they are in the IE team.

    I’d bet the guy who implemented the aria value stuff correctly in ie8 standards mode got sacked, due to their obvious and consistently implemented policy of “let’s do everything in the most verbose, inconsistent and difficult possible way, and if someone else comes up with something better let’s make sure we DON’T fix ours, and instead publish a lot of tutorials on how to do it WRONG. This should hold back the advancement of the internet longer so our bosses survive just by selling Windows.”

    You know this means we have two different kinds of browsers to work with, as always. Basically IE and not IE. You’re right, as usual we have to write a while extra alias function in userspace to abstract away the simplest and most primitive things in our code, and it’s – as always – because of Virus Explorer.

    Internet Explorer, I hate you!! Why won’t you just die!?

  5. But yes, if they could get it included in the standard, it would be nice, and a Good Thing (registered trademark).

    Also, I’m quite proud of my second paragraph there, which is two or arguably only one sentence/s. Lexical might!

  6. aaronlev says:

    Well, we can look at it for the standard, but I don’ t think it will work for author-defined properties.

  7. Jon Gibbins says:

    The work going into ARIA from different camps is really promising. I’ve long wanted to see assistive technology vendors, browser vendors and the W3C come together to work towards better accessibility standards.

    It’s a shame to see these legacy issues causing a problem now, when progress seems to be good. I’ll freely admit to being unaware of all the issues involved, but I cannot imagine that it is a difficult task to put this right. Too long have web developers had to yield to these inconsistencies.

  8. [...] Aaron Leventhal recently blogged about how ARIA in IE8 is a pain. (Aaron works for IBM making Firefox and Web applications accessible and is a member of the W3C PF [...]

  9. [...] Aaron Leventhal recently blogged about how ARIA in IE8 is a pain. (Aaron works for IBM making Firefox and Web applications accessible and is a member of the W3C PF [...]

  10. [...] will not provide great technical detail into what Microsoft is doing (Aaron Leventhal has provided the details), but in short, there are two major differences in the IE8 implementation of ARIA when compared to [...]

  11. James says:

    So does the latest IE8 private RC fix this?

    Accessibility-ARIA: ARIA attribute names containing dashes, such as “aria-checked”, no longer have to be referenced by their camelCased equivalent (ariaChecked) in IE 7 Mode and Quirks Mode. As a consequence of this change, the camelCased syntax no longer exists for these attributes.

  12. [...] listens, and addresses WAI-ARIA concerns A while back we wrote that Internet Explorer 8 beta 2 was not using standard syntax for WAI-ARIA properties. The syntax actually varied depending on the mode chosen for the page, which was confusing. [...]


Get every new post delivered to your Inbox.

%d bloggers like this: