In an attempt to address this problem, WebAIM is conducting a survey for screen reader users. If you are a full-time, part-time, or even occasional screen reader user, please take a few minutes to complete the survey and provide us with a few details on your screen reader usage and preferences. Your feedback will help influence the accessibility techniques that web developers implement.

We will be comparing results between those that rely on screen readers and those that primarily use them for evaluation and testing, so all screen reader users are invited to respond.

The results of the survey will be made public in a few months. We believe the results will be very useful to those who are developing accessible web content.

We are relying on all of you to help us spread the word. Please post to lists, blogs, etc. where screen reader users might participate. The survey is will take approximately 10-15 minutes to complete.

Access the survey at http://webaim.org/projects/screenreadersurvey/

Look forward to more detailed analysis and resources on WCAG 2.0 on the WebAIM site in the near future.

During the first phase of this project, which begins December 2008, we will develop a framework that facilitates the translation of WAVE. We will then begin translation of the WAVE evaluation rules and supporting documentation. A private alpha and public beta versions of the translated tool will be available in spring of 2009. The final Spanish-language version of WAVE will be released no later than June 2009.

You can help

Although WebAIM staff will provide the bulk of the translation work, you can help in several ways.

Improve translation of the WAVE feedback.

Every WAVE icon has a title, a description, and recommended actions that must be translated.

Improve the accuracy of WAVE rules.

For example, you can help us identify examples of inappropriate alt text (“image of”, “spacer”, etc.) or link text (“click here”, etc.) in Spanish.

Improve the translation of the WAVE site and toolbar.

We hope to translate additional content on the WAVE site and toolbar and toolbar (e.g., help files).

Identify WAVE bugs and offer suggestions for improvement.

While WAVE is a very stable tool, there are still bugs. As part of the translation process, we are going to refine our bug reporting process to make it easier for you to let us know what we can improve.

Spread the word.

We have provided a Spanish-language translation of this announcement. If you are able, please circulate this announcement to Spanish-language accessibility forums and discussion lists and to Spanish-speaking individuals.

Be ready for translation into other languages.

If you would like to help us translate WAVE into another language, let us know. We don’t plan on translating WAVE into other languages until this initial Spanish-language version is finalized, but we would love to hear from you now if you can provide or help with other language translations.

If you would be interested in helping in any of the ways mentioned above, contact Jon Whiting. A Spanish-language translation (traducción en español) of this announcement is available.

Read the article at http://webaim.org/techniques/aria/

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.

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.

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

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.

A summary of the settlement

• Target makes no admission or concession that its website is or ever was inaccessible.
• Target admits no violations of the ADA or any other law.
• The website will be brought into compliance with the Target Online Assistive Technology Guidelines (2MB Word Doc) and will be certified by NFB as compliant with these guidelines. NFB will monitor compliance over 3 years from initial certification.
• Target will pay NFB $90,000 for the certification and first year of monitoring and then $40,000 per year thereafter.
• Target’s web developers will receive at least one day of accessibility training, to be provided by NFB at a cost of up to $15,000 per session.
• Target will respond to accessibility complaints from web site users.
• Target will pay damages of $6,000,000 to the class action claimants, or at most $7000 per claimant, and will pay $20,000 to the California Center for the Blind on behalf of the primary claimant, Bruce Sexton, Jr.
• Payment of legal fees is yet to be determined.

Additional details on the lawsuit are available on the Disability Rights Advocates web site.

My thoughts on the settlement

While this is a great victory for the NFB and the claimants, I think the majority of the accessibility community was hoping for some long-awaited case law that might better define the relationship of the Internet and the Americans with Disabilities Act. While there have been many lawsuits claiming discrimination under the ADA because of inaccessible web sites, there is virtually no case law that clarifies that the ADA applies to web sites. This settlement clearly provides no additional insight into this matter. Instead of corporations receiving clarification that they are ALL legally obligated to make their web sites accessible, they can now take comfort in the fact that if they aren’t big/rich enough for NFB or others to engage in a complicated and expensive lawsuit, that they can maintain the status quo of, at best, marginal accessibility.

I also believe the 6 million dollar settlement to be rather insignificant for a corporation that had $63 billion in revenue and $3 billion in net income in 2007. Still, the settlement amount is significantly more than what it would have cost Target to implement a high level of accessibility in the first place.

Additionally, there is no indication that the Target accessibility guidelines include anything much that would benefit anyone except blind users. While the NFB is a blind advocacy group, the scope of changes required are very minimal.

UPDATE: Since originally writing this post, the guidelines were made available. There are a few requirements, while primarily intended for blind and low vision users, that may provide benefits to those with other disabilities.

Don’t get me wrong, I’m thrilled with the outcome and I do think it will motivate the largest corporate retailers to take accessible a bit more seriously, but without clarification of their true legal obligation, I fear the influence of this settlement will not be very significant.