WebAIM Blog

Momentum

WAI-ARIA, the W3C protocol for making rich internet applications more accessible, is gaining much momentum (Read the ARIA FAQ). Even though ARIA isn’t entirely finalized, it is currently supported in most of the major browsers and screen readers. New versions of browsers and assistive technologies are providing better and more extensive support with each release. Industry leaders, such as IBM and Mozilla, are pushing ARIA’s great momentum.

Implementing ARIA is getting easier. Tutorials and examples are being released each day. Common scripting libraries are providing better support - Dojo, YUI, and GWT have native support, with JQuery and many others beginning implementation of ARIA.

Developers can currently implement most of ARIA into their web applications with tremendous increases to accessibility.

Internet Explorer’s Non-standard Implementation

Perhaps the biggest barrier to ARIA implementation is that it is not yet supported in Internet Explorer. It’s difficult to truly recommend a technology that does nothing in the most popular web browser. The standards and accessibility community was thrilled to hear that Internet Explorer 8 will support ARIA. However, this excitement is being tempered by the fact that Microsoft is currently implementing ARIA in a non-standard way.

I 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 what the spec requires and what is supported by all other major browsers. The current beta of Internet Explorer 8 requires a different mechanism and syntax for setting ARIA properties and does not properly update certain page elements when ARIA properties are dynamically changed.

Suffice it to say that Microsoft’s non-standard implementation of ARIA will make it more difficult for developers to implement an ARIA solution that works universally across browsers and assistive technologies. If developers must choose between an ARIA solution that works only in Internet Explorer or one that only works in every other browser, or if they must implement difficult and often unreliable mechanisms to account for specific browsers and even versions of browsers, then the reality is that many web developers will simply not implement ARIA or accessibility at all. And that would result in decreased accessibility for people with disabilities.

A Call for Action

We, therefore, encourage Microsoft to increase their commitment to standards and to accessibility by implementing Internet Explorer 8 ARIA support according to the specification and the ARIA User Agent Implementation Guidelines. We also encourage all browser and assistive technology vendors and even web developers to look further into the great benefit that ARIA can provide for people with disabilities and implement it where necessary.

Eight months ago, WebAIM announced the first general release of the new WAVE Web Accessibility Tool version 4. Since that time, the WAVE team has been hard at work fixing bugs, improving efficiency, enhancing the test rules, and preparing for new WAVE features and projects. We therefore thought this would be a good time to give an update on what we’ve been doing, where we are now, and what we’re working on for the future. More detailed updates are always available on the WAVE blog. And if you’ve never used WAVE, you can learn more about how to use it in WebAIM’s WAVE article.

Since our initial launch in January, WAVE has been used by 60,000 unique users from all over the world to create over 500,000 reports for 163,000 distinct URLS. WAVE reports zero errors on almost half of the pages evaluated (the most errors on a single page is 1120!). Several thousand pages were remediated using WAVE - meaning they started with accessibility errors, but those errors were all later fixed.

In addition, the WAVE 4 toolbar for Mozilla Firefox has been downloaded many thousands of times and is being used to evaluate and the improve the accessibility of countless pages.

Fixing Bugs

Since our launch in January, hundreds of people have sent us feedback. While some just to tell us how awesome we all are (or at least how awesome WAVE is), many are reports of bugs, problems, or issues with the WAVE tool or website functionality. Each issue raised is carefully logged, investigated, and when possible, quickly fixed by a member of the WAVE development team. Through this process, many small (and sometimes not so small) bugs have been fixed, along with many others found as a result of our own internal testing and continual monitoring of the entire WAVE system. As a result, WAVE is significantly more stable and error-free than today than ever before. Still, we know there are yet bugs to be found, so if you notice any, please let us know.

Improving Efficiency

If there was one aspect of WAVE 4 that we weren’t very proud of on launch day, it was speed. Previous versions of WAVE were written on a very simply platform, and did a good job of evaluating very simple web content, which is really all there was at the time WAVE was first written. WAVE 4 was designed to perform the much more complicated tests required to evaluate modern advanced web sites and applications. As a result, evaluations in WAVE 4 were somewhat slower than in previous WAVE releases. The good news is that the WAVE development team has been hard at work on speed and efficiency issues since launch, and as a result of these improvements a typical WAVE report is over twice as fast (i.e., takes less than half the time) today compared to six months ago. And we’re not finished yet, so expect to see even more improvements in this area in the near future.

Enhancing Test Rules

In addition to bug reports, many of the emails we get about WAVE are from people who have suggestions (or complaints) regarding the test rules - the specific things and patterns that WAVE looks for in a page, and what it says when those things are found or not found. Several users found bugs in the things we’re looking for or in the resulting reports, while many others had suggestions for modifications or new rules. Based on these suggestions, along with our own continued experience, we have made numerous additions, modifications, and clarifications to the WAVE test suites, resulting in better, more accurate, and more complete reporting for all WAVE users.

WAVE Toolbar

We have also been hard at work on the WAVE 4 Toolbar, a free extension for the Mozilla Firefox web browser. This tool runs complete WAVE reports entirely on the local machine (without sending any data to the WAVE server), making it ideal for testing extremely large, password protected, confidential, or private documents. Because it uses the exact same tests and processor platform as the WAVE website application, the toolbar benefits from the majority of the WAVE improvements discussed above.

Coming Soon (we hope)

Although we cannot yet say for certain exactly how or when any of these features might be finished, here are a few of the things we’re planning on implementing with WAVE in the near future.

Internationalization

One of the largest current limitations of WAVE is that it is, for the most part, an English-only tool, whereas the internet as a whole is steadily moving in the opposite direction. With this in mind, we are currently preparing work on a localizable version of WAVE and the WAVE toolbar. We hope to have the ability to serve not only the WAVE website interface in multiple languages, but also have the WAVE tests themselves (those that depend on the language of the source document) run in the native language of the website being processed. If you are interested in translation or internationalization of WAVE, please contact us.

Cognitive Tests

WebAIM has also received funding to expand WAVE functionality to address several aspects of web content that affect cognitive accessibility. We will be adding these features to WAVE in the coming months.

Improved Testing and Reporting

We’re also actively and continually working on improving our evaluation rules and report views. While we don’t know the specifics yet, look for many small incremental improvements in this area in the future. As always, we welcome feedback on any part of the WAVE system, so if you have any suggestions, ideas, or bug reports, please let us know.

I was happy to be co-host of the most recent Web Axe podcast. Dennis and I discuss the Target lawsuit, YouTube captioning, Fangs for Firefox 3, and more.

Web Axe was recently nominated as “Podcast of the Year”. Be sure to check out the other excellent podcasts available.

In the beginning there was NCSA Mosaic, and Mosaic called itself NCSA_Mosaic/2.0 (Windows 3.1), and Mosaic displayed pictures along with text, and there was much rejoicing.

And behold, then came a new web browser known as “Mozilla”, being short for “Mosaic Killer,” but Mosaic was not amused, so the public name was changed to Netscape, and Netscape called itself Mozilla/1.0 (Win3.1), and there was more rejoicing. And Netscape supported frames, and frames became popular among the people, but Mosaic did not support frames, and so came “user agent sniffing” and to “Mozilla” webmasters sent frames, but to other browsers they sent not frames.

And Netscape said, let us make fun of Microsoft and refer to Windows as “poorly debugged device drivers,” and Microsoft was angry. And so Microsoft made their own web browser, which they called Internet Explorer, hoping for it to be a “Netscape Killer”. And Internet Explorer supported frames, and yet was not Mozilla, and so was not given frames. And Microsoft grew impatient, and did not wish to wait for webmasters to learn of IE and begin to send it frames, and so Internet Explorer declared that it was “Mozilla compatible” and began to impersonate Netscape, and called itself Mozilla/1.22 (compatible; MSIE 2.0; Windows 95), and Internet Explorer received frames, and all of Microsoft was happy, but webmasters were confused.

And Microsoft sold IE with Windows, and made it better than Netscape, and the first browser war raged upon the face of the land. And behold, Netscape was killed, and there was much rejoicing at Microsoft. But Netscape was reborn as Mozilla, and Mozilla built Gecko, and called itself Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826, and Gecko was the rendering engine, and Gecko was good. And Mozilla became Firefox, and called itself Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.5) Gecko/20041108 Firefox/1.0, and Firefox was very good. And Gecko began to multiply, and other browsers were born that used its code, and they called themselves Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040825 Camino/0.8.1 the one, and Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.8) Gecko/20071008 SeaMonkey/1.0 another, each pretending to be Mozilla, and all of them powered by Gecko.

And Gecko was good, and IE was not, and sniffing was reborn, and Gecko was given good web code, and other browsers were not. And the followers of Linux were much sorrowed, because they had built Konqueror, whose engine was KHTML, which they thought was as good as Gecko, but it was not Gecko, and so was not given the good pages, and so Konquerer began to pretend to be “like Gecko” to get the good pages, and called itself Mozilla/5.0 (compatible; Konqueror/3.2; FreeBSD) (KHTML, like Gecko) and there was much confusion.

Then cometh Opera and said, “surely we should allow our users to decide which browser we should impersonate,” and so Opera created a menu item, and Opera called itself Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 9.51, or Mozilla/5.0 (Windows NT 6.0; U; en; rv:1.8.1) Gecko/20061208 Firefox/2.0.0 Opera 9.51, or Opera/9.51 (Windows NT 5.1; U; en) depending on which option the user selected.

And Apple built Safari, and used KHTML, but added many features, and forked the project, and called it WebKit, but wanted pages written for KHTML, and so Safari called itself Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5, and it got worse.

And Microsoft feared Firefox greatly, and Internet Explorer returned, and called itself Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0) and it rendered good code, but only if webmasters commanded it to do so.

And then Google built Chrome, and Chrome used Webkit, and it was like Safari, and wanted pages built for Safari, and so pretended to be Safari. And thus Chrome used WebKit, and pretended to be Safari, and WebKit pretended to be KHTML, and KHTML pretended to be Gecko, and all browsers pretended to be Mozilla, and Chrome called itself Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13, and the user agent string was a complete mess, and near useless, and everyone pretended to be everyone else, and confusion abounded.

Web Accessibility Gone Wild presents a wide variety of mistakes, misconceptions, over-indulgences, intricacies, and generally silly aspects of modern accessibility.