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.

Advertisement