Read the W3C press release

Findings

Skip to content links

Of the 97 pages that contained repetitive navigation, 85, or 88%, had missing or broken skip to content links. This made it the most commonly violated checkpoint. Of the many sites that provided skip to content links, only 12 had functioning links. The rest were broken. A few had the link in place, but the corresponding anchors were missing or incorrect. I also found that about one page in ten had a skip to content link that had been hidden using visibility:hidden or (more often) display:none, making it inaccessible to keyboard and screen reader users. There were only a handful of pages, no more than five, with a hidden skip to content link that was both screen reader and keyboard accessible.

Form labels

Of the 76 pages that had form elements, 63, or about 83%, of the pages had at least one element with a missing or incorrectly-associated label. The vast majority of the pages had only one form element–the search box. That raises a question–if a screen reader user encounters an unlabeled form element on an unfamiliar site, can they assume that it is a search box?

Alt text

Each of the 100 pages that I evaluated had at least one image. 71 of the pages (I’ll let you figure out the percentage on this one) had at least one image–most had more–with missing or inappropriate alt text. Although 71 pages is still a high number, I am encouraged that almost 30% of the pages I evaluated had appropriate alt text. That is a higher percentage than any other 508 studies that I have seen. Of course, I was fairly liberal in my interpretation of an "alternative." I passed alt text that was a little lengthy or slightly inaccurate, so I suppose it would be more accurate to say that almost 30% of the pages that I evaluated had images with accessible alt text that reached a minimal standard of equivalence.

Even though I am encouraged that more sites seem to be using alt text, I would argue that it is still the highest priority accessibility concern on the web. Even though I came across more pages with missing skip to content links, I came across far more instances of missing alt text. If I had tracked number of errors, missing or inappropriate alt text would have been the clear winner (or loser).

It is also much more difficult for a screen reader to compensate for missing or inappropriate alt text. If a page has missing form labels or table headers, a screen reader will often be able to compensate. If an image has a missing alt attribute, the screen reader will either ignore the image or read the filename

Despite the apparent improvement in the use of alt text, there seems to be a disturbing increase in the number of images as links that are missing alt text (every image that is a link needs alt text). This is a trend that we have noticed during this evaluation and on the web in general. Either that or we just notice it more because we now have a rule or icon for it in WAVE 4. This is unfortunate because while many images with missing alt text probably do not need alt text, every image that is a link needs alt text.

Headings

Even though it is not specifically addressed in 508, except possibly as a method to skip repetitive navigation (o), I also decided to see how many pages provided a heading at the beginning of the content. I was surprised to find that only 46% of the pages did this.

In my opinion, good semantic structure is one of the most essential and overlooked accessibility issues. A clearly-structured site is usually easier to understand, navigate, and is more accessible to users, particularly those with cognitive disabilities.

Other findings

• Five of the pages that I evaluated had data tables, none of which identified table headers.
• I came across one frameset, which did not have titles.
• 94 pages had scripting. 17 of these pages (18%) contained inaccessible scripting.
• 51 pages had links to files that require a plugin. Almost all of these were PDF files. 36 pages, or 71%, did not provide the required link to the plugin. Since modern browsers automatically detect missing plugins for common formats, this is arguably an outdated requirement.
• There were no pages with server-side image maps.
• There was one video. It was not captioned.

Musings

508 Falls Short

WebAIM is often asked to conduct accessibility evaluations, and many times we are asked to evaluate a site for Section508 compliance. Sometimes this is appropriate, but when possible, we try to convince our clients that 508 is not an acceptable criteria for accessibility. Section 508 is very important in the United States. If you live in the US, and are involved with web accessibility, you should be familiar with the 16 checkpoints that relate to the web. For those of you who are not familiar with 508, you may want to review our Section 508 checklist. It is important that anyone familiar with web accessibility be familiar with Section 508. However, as a standard for accessibility evaluation, 508 falls short. A good deal of the information is repetitive (e.g., image maps) and dated (e.g., links to plugins). Fortunately, 508 is currently in the process of being updated.

College Websites are Behind the Times

I don’t know if it is because colleges often have decentralized web development teams, or because website development and maintenance is not a part of their core mission, or if I am just spoiled by the many good sites that I visit, but I was a little surprised at the low quality of many of the college websites. Many of the sites seemed dated, poorly structured, and not very accessible. Quite a few of them loaded slowly, and many links that were functioning when they were randomly selected were dead a couple of weeks later when I evaluated them. Some of the sites were from small, two-year colleges that probably operate on smaller budgets, but many were not.

We still have our work cut out for us

WebAIM started as a grant-funded project with the primary goal of dissemination and awareness. Even though our funding sources have changed, these are still our primary goals. As we travel to conferences and trainings, it seems that the knowledge and awareness of the people that we interact with is growing. Their level of familiarity with accessibility principles is, as a group, higher than it was a few years ago. Most of the people we train have seen a screen reader in use and are familiar with basic accessibility concepts like alt text or form labels. This wasn’t the case even five years ago.

That is why it was surprising, and even a little disappointing, to see that the accessibility of many of the sites that I evaluated seemed to be almost the same as, and in some ways worse, than sites designed five years ago. There are clearly many people who have not learned the basics of accessible web design or do not appreciate its impact. We still have a lot of work ahead of us.

If you know of any company who is looking for an expert accessibility review, please point them to the information for companies.

This comprehensive human rights treaty provides many fundamental rights to those with disabilities. Among the sections of the 50-article Treaty are explicit references to the accessibility of information and communications. The most prominent is Article 9 - “Accessibility”, which places accessibility of information, communication, and technologies (ICT) at the same level as Articles on “The right to life”, “Equal recognition before the law”, “Access to justice”, and “Freedom from torture or cruel, inhuman or degrading treatment or punishment”. You can see that accessible ICT is being taken very seriously.

One of the General obligations of States Parties (Article 4) is “To undertake or promote research and development of universally designed goods, services, equipment and facilities…” and “To undertake or promote research and development of, and to promote the availability and use of new technologies, including information and communications technologies…”

Once in effect on May 3rd, this new international law will apply to only those countries that have both signed and ratified the CRPD (currently 23 and rising). Over a hundred additional countries have signed onto the Convention. For now, their work is to align their national legislation to the CRPD. Thus, countries such as Japan, Canada, S. Korea, Australia, China, and the United Kingdom are expected to ratify when they complete this internal process, which may take a few years.

There will be no force in effect for those countries that have neither signed nor ratified the CRPD, such as the U.S. It is interesting to me that our government has not signed the Convention, even to underscore its importance in principle. Our nation currently sits in a minority of countries who have not signed, such as Iraq, Haiti, the Congo, and Fiji. U.S. officials have indicated that domestic laws, especially the ADA, are stronger than those of the CRPD. However, how many of us are aware of unequivocal rights in the U.S. to accessible information and communications technologies in both public and private sectors? Many are calling on all Americans to sign a petition in support of the U.S. becoming a signatory to the CRPD.

It is not possible for me to convey how important this event is on a worldwide stage, not just for electronic accessibility efforts, but also for the broad human rights issues that face those with disabilities, particularly in developing countries. Perhaps my fervor for this can’t be separated from the more general issues of human rights and discrimination that those with disabilities face worldwide. For those interested in the rights of persons with disabilities I urge you to read the Preamble for the Convention and its General Principles. They are compelling beyond words. Finally, the world has a chance to enact these principles.

For those of us passionate about making the world a more accessible place, now is the time to help in the global transformation. The basic human right to access information and communication can happen in our lifetime, if we work together. The ratification of this treaty is a major step forward in this process. The important thing here is not that the train has left the station, but that it is well down the track.

The outline CSS property allows you to define the visual outline that displays when elements are selected or have focus. Otherwise known as the focus indicator, it is seen as the dotted lines that surround links and buttons when you tab to them with the keyboard.

In some rare instances where designs are rigidly defined with pixel precision and when the browser improperly changes the size of an element when the outline appears, pages can break (even though the CSS spec indicates that the outline should take no space). In other cases, designers are annoyed by the fact that the focus indicator remains visible when a user activates a link and then returns to the original page. As a result, developers are more and more removing the outline behavior from their page elements. By doing so, they can make it nearly impossible for sighted keyboard users to effectively navigate the page.

For example, try to navigate cnn.com in Firefox while using only your keyboard. There is no visual indication of which link currently has the keyboard focus because the outline and the text-decoration for links have been removed. The result - total keyboard inaccessibility. I am beginning to see this very regularly across the web even though most browsers now properly implement CSS outlines.

The prevalence of this is increased by the inclusion of outline:0 in many CSS reset files, such as Eric Meyer’s CSS Reset. It applies outline:0 to all page elements. While he clearly indicates that focus styles should be re-implemented,…

/* remember to define focus styles! */
:focus {
outline: 0;
}

… the inclusion of outline:0 in the default code does not provide anything useful. This recommendation is almost always either misunderstood or ignored as evidenced by the many sites that use this code as is. Simply changing the focus code to outline:1px would result in better accessibility and understanding.

If a linked image already provides a visual indication of focus (with either CSS or scripted image replacement), the focus indicator may not be required. And sometimes a linked element contains content that is positioned off-screen, resulting in an overly large focus indicator. You can also provide focus indication using any number of styles (change the background, add a border, etc.) in place of or in addition to the outline property. The WebAIM site underlines and changes the background color for focused links, in addition to maintaining the default outline.

In most cases, particularly for text links, it is vital that visual focus indication be provided. The use of outline:0 or outline:none is not recommended. In almost all cases, this CSS can be removed from links with absolutely no impact on the layout or functionality of the site, but with the result of increased accessibility.

WebAIM’s Steppingstones project is one of the first in-depth explorations into web content and cognitive disabilities. Our literature review provided us much insight into the types of things that authors reference as having an impact on web accessibility for people with cognitive and learning disabilities. The survey results will give us more insight into the level of impact these elements might have and how useful it might be for developers to receive feedback regarding these elements in their web design. As part of this project, WebAIM will be developing an evaluation tool that will report on the cognitive load and implications of some of these design elements. The survey results will help us determine which elements we will incorporate into such a tool.

The survey is available online and takes approximately 10 minutes to complete. By completing this survey you will greatly inform our process and support the creation of better tools for increasing accessibility of web content to this important audience.

You can download the WAVE Firefox Toolbar at http://wave.webaim.org/toolbar

We have also launched a new WAVE blog and will be posting WAVE updates and information there. You can read more about the WAVE Toolbar or subscribe to the RSS feed now.

It’s not a real secret that I, like many other developers, have experienced a vast amount of frustration in attempts to build standards compliant, accessible web sites that work in Internet Explorer. From the infamous hasLayout bug to CSS inconsistencies, I’ve been long waiting for the day that IE would either go away or step up to the standards table.

Then behold, Microsoft announced this week that IE 8 will support the ARIA specification and will no longer require developers to target a specific IE rendering engine (unless of course, they want to target an older rendering engine). Read the CIO.com article, the IE Blog posting, the press release, or the IE8/ARIA Whitepaper.

These announcements signify a significant victory for developers, for standards, and for accessibility. As Bruce Lawson documented, Microsoft’s previous plan to require developers to target specific browsers could have resulted in perpetual inaccessibility on sites that did not opt-in and implement the IE specific meta tag. Now, IE8 will default to the most current rendering engine and will support a true standards compliance mode. Developers will not be required to tell IE to act compliant. As such, screen readers and other assistive technologies can take full advantage of existing and future accessibility specifications (such as ARIA) in Internet Explorer without relying on the page author to trigger standards compliance mode specifically for that browser version.

The ARIA specification has much potential for making dynamic, AJAX-driven, interactive web sites more accessible. Despite it’s potential, developers have not taken it seriously due to the fact that there were no plans for Internet Explorer support. The announcement that IE8 will support ARIA means that developers can begin implementing ARIA very soon. While ARIA is not the panacea of accessibility and won’t solve all problems, it does provide a framework for making rich internet applications more accessible in a formalized, (and now) cross-browser compatible way.

Advanced Web Accessibility Evaluation with WAVE

Wednesday, March 12, 2008 - 1:50-2:50 PM
Jared Smith and Aaron Andersen

An overview of the updates to the WAVE accessibility tool and toolbar, and a methodology for evaluating web sites using WAVE and other tools will be presented.

Web Accessibility Gone Wild

Jon Whiting and Jared Smith
Friday, March 14, 2008 - 8:00-9:00 AM

In this presentation, we will discuss how accessibility can decrease if some accessibility techniques are applied incorrectly or excessively.

Accessibility of Next Generation Web Applications

Jared Smith
Friday, March 14, 2008 - 10:40-11:40 AM

Dynamic HTML and AJAX are beginning to dominate the internet. Next generation web applications can impact accessibility of the web for better or worse.

What is WAVE?

WAVE is a web accessibility evaluation tool. Rather than providing a complex technical report, WAVE shows your original web content with embedded icons and indicators that reveal the accessibility information within your page. WAVE cannot tell you if your web content is accessible - only a human can determine true accessibility - but WAVE can help you evaluate the accessibility of your web content. You can submit web content to WAVE for evaluation by providing a URL, uploading a file, or entering/pasting HTML code.

What’s New in Version 4?

New evaluation rules

WAVE 4.0 beta features 28 new accessibility tests. These provide more detailed checking of accessibility issues and features found in your web content. For instance, instead of simply identifying missing alt text, WAVE 4.0 indicates if the element missing alt text is a decorative image, a link, an image map hotspot, etc. New tests check for empty headings, broken skip navigation links, missing or poor page titles, small text, pop-up windows, hidden content, and much more.

A new evaluation framework

An entirely new evaluation framework makes WAVE more powerful and flexible. Rather than relying on complex tests and if/else statements, a simple, XML-based language is used for writing evaluation rules. This allows easy creation and modification of evaluation rules, icons, and reporting features. Eventually, WAVE may allow user-authoring, editing, or submitting of evaluation rules to allow custom evaluation of web or other content. This framework will allow us to implement future testing under our cognitive disabilities initiative.

Powered by Mozilla

When web content is submitted to WAVE, WAVE uses the Mozilla Gecko rendering engine (this is the rendering engine used in Firefox) to generate a virtual representation (or DOM) of the page. This rendered content, rather than the raw HTML code, is then evaluated against the evaluation rules. This allows WAVE to evaluate elements after cascading style sheets have been applied to them. WAVE can now identify overly small text, for example, even if it is small due to multiple CSS inheritances. It also allows for better evaluation of documents that are not structured or coded to web standards.

Better reporting interface

WAVE 4.0 reporting is simpler and more user-friendly. Tooltips for WAVE icons now provide additional details. Four different report views allow you to evaluate different aspects of your web content. New functionality is available for copy/paste of HTML code and viewing your evaluation history. Additionally, the number of preference options available has decreased. In fact, there really are NO user preferences in WAVE 4.

The interface is also more stable, allowing inline reporting for complex, CSS-driven web site. Despite the improvements, we cannot account for all possible styles and some reports may be rendered with unreadable or layered elements. In such cases, an option is available for disabling CSS styles within reports.

While the interface is javascript driven, all functionality is available with scripting disabled. We implemented the hijax approach which uses scripting to enhance an already-functional interface.

In future versions, more detailed reporting and report customization will be available.

WAVE Toolbar

The WAVE Firefox Toolbar will be available late January 2008. This toolbar will perform all of the WAVE evaluation work directly within your web browser. Because there will be no WAVE server interaction, this will allow for private and secure evaluation of password protected, intranet, dynamically generated, or script modified/AJAX powered web pages.

Beta Resources

During beta testing, a set of test case documents will be available at http://wave.webaim.org/report These provide an excellent way to become familiar with how WAVE works and what its capabilities are. Additionally, the Icons Key can be used to identify new WAVE icons and tests.

WAVE is very much in beta, so if you encounter bugs or have recommendations, please use the feedback form to notify us.

We will be holding an EASI webinar on Monday, January 28th, where we’ll present on the new features of WAVE 4 and what to expect in the future.