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 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.
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:
slider.setAttribute("aria-valuenow", '25');// Firefox, Opera, Safari, IE8 Standards Mode
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:
- Web apps that are only accessible in IE
- Web apps that are only accessible in Firefox and Opera/WebKit (once their ARIA and accessibility support is further along)
- Web apps that support both because they have made the transition to IE 8 standards mode
- 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.
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.