Fast Track to Web Accessibility in 5 Steps

I need an accessible site! NOW!

Sometimes you don't have the time to sit down and plan out the ideal web site. Maybe you've just recently been appointed as your organization's webmaster, or have recently been assigned to oversee accessibility operations at your organization, and you discover that your web site has gaping holes in its accessibility. Rather than panic, you should start with the biggest problems and work your way through the site until you have fixed all of the accessibility errors. After you've "plugged the holes," then you can start thinking about a new design, but not until then. This workshop presents a "fast track to accessibility" that prioritizes your tasks of sorting through and fixing your site's accessibility problems.

Step 1. Evaluate your current site. Determine what areas of your site need some work.

Run an accessibility evaluation software tool (e.g. the WAVE, WebXACT, etc.) on your pages.

In order to make a web site more accessible to people with disabilities, the designer must first identify the problem areas. There are several automated tools that can make part of this process easier. Some tools are free--such as the WAVE, WebXACT, Page Valet, and A-Prompt--while others are commercially marketed--such as the tools by UsableWeb, HiSoftware, Crunchy Technologies, SSB Technologies, and RetroAccess. Each of these tools has its own strengths and weaknesses, and each has its own style of providing feedback and helping the designer to make accessible web content. Some evaluate one page at a time, while others can evaluate entire web sites. Some only generate reports, while others incorporate a wizard-style interface to help the designer make the necessary changes to the Web page. It really doesn't matter which of these tools the designer uses. It is largely a question of personal preference and style. The important point here is that the designer should use some tool that can catch basic accessibility errors. It is also important to note that all of these tools have the same inherent weakness: they can't find every accessibility error. For example, although all of the tools can identify images without alt text, none of them can determine whether the alt text is accurate, appropriate, or adequate for the image in question.

Navigate the site without a mouse, using only the keyboard.

Set aside the mouse and see if you can navigate through the entire web site using only the keyboard. In most browsers, this means using the TAB key to navigate forward through links, SHIFT + TAB to navigate backward through links, and the ENTER key to follow links. The Opera browser uses the A, Q, and ENTER keys to perform these same functions. When inside forms, the arrow keys will allow you to select items within lists or radio buttons. Pay close attention to any interactive features, such as dynamic menus, drag-and-drop functions, or mouse rollover events. If the mouse rollovers are merely decorative (e.g. they create a “glow” effect), don’t worry about it. However, if the mouse rollovers expose additional important information, ensure that this information can be accessed by the keyboard alone, either on the same page or on other pages which are easily accessed.

Step 2. Fix the easiest issues on the home page first.

Start with the home page, because this is the first page that most of your users will access. Your users form an opinion about the rest of the site based upon their impression of the home page. If the home page is inaccessible, users may decide not to try to access subsequent pages.

Missing alt text

There is no excuse for missing alt text on a web page, especially on a site’s home page. Alt text should be descriptive and brief. In most circumstances, you should not include the words “link to” or “graphic”, since most disability tools already inform the users that the objects are graphics and/or links. For details on alt text techniques, see the image techniques tutorial.

Incorrect or inadequate alt text

Ensure that the alt text is not only present, but accurate. Remember that the alt text is meant to substitute for the image. Provide sufficient information in the alt text to make the image unnecessary—but keep it brief. If longer descriptions are necessary, either provide them in the context of the text on the page or use the longdesc attribute as described in the long description techniques tutorial.

Links that don’t adequately convey their purpose (e.g. “click here”)

Many users of screen readers like to navigate through web pages by tabbing from link to link. When they do this, the screen reader reads the text of the link. If the link text makes sense by itself, this process is effective. If, however, the link is too vague (e.g. “click here,” “here,” or “more”), users will not understand the purpose of the links without backtracking to read the context around the links.

Poor contrast

Some of the issues of contrast will likely be related to the templates used on the site (see step 3), but some issues may be easily fixable without tampering with the template. Important issues include the contrast of text against the background color, or “busy” backgrounds that clash with the text or that simply distract users by drawing their attention away from the central content on the page.

Frames without titles

It only takes a minute or so to add titles to frames. Appropriate titles may include “Navigational menu,” “Main content,” or “Additional Information,” depending on the actual content in each frame.

Step 3. Fix your templates. When you fix your templates, you fix a large portion of your accessibility problems.

Most sites make use of some sort of template system. The idea behind templates is to allow designers to reuse the same basic design, or “shell” on many pages, so that they do not have to recode the same information over and over again. When you use template systems, this substantially reduces the amount of work that you will have to do to make the site accessible, because when you fix the template, you simultaneously fix all of the pages that use that template.

Provide a way to skip over repetitive links (e.g. site navigation links).

Most sites can benefit from a link at the very top of the document that allows users to skip past all of the navigational links and go directly to the main content. Those who use screen readers, or those who simply do not use a mouse will then not have to tab through or listen to all of the same links over and over again on every page.

Make the navigation scheme as consistent and intuitive as possible throughout the site.

Everyone benefits from this guideline, especially those who have cognitive disabilities. Even those with relatively minor conditions, such as reading disorders or learning disabilities may be markedly better able to orient themselves more effectively on sites that are consistent and intuitive. Those using screen readers will also appreciate the added degree of predictability, because oftentimes it is the site’s usability problems that are most frustrating to screen reader users.

Ensure that the templates are keyboard-accessible.

Most of the errors that web designers commit with regard to keyboard accessibility can be fixed at the level of the template, rather than the main content. Where direct keyboard accessibility is not possible (e.g. most JavaScript dynamic menus), provide an alternative method of accessing the same content, either on the same or another page.

Use the simplest layout structure possible, ensuring that the reading order makes sense when both tables and styles are turned off. (It doesn’t have to look pretty this way, it just has to be understandable.)

In essence, screen readers ignore all formatting elements such as tables and style sheets, and read only the content itself. Complex layouts (e.g. multiple embedded tables) can lead to content that does not make sense when the formatting is removed. One way to test the “linearization” of your web pages is to open the page in the Opera browser (www.opera.com), then turn off tables in the user mode (File > Preferences > Page Style > User mode > tables). You can then toggle between the full layout and the linearized version with a single click of the mouse.

Step 4. Fix all HTML-related issues in the content pages.

If your content is in HTML format, it can be made accessible, and it’s not as difficult as some people think it is.

Data tables (simplify complex layouts; associate data cells with headers)

Data tables, especially complex ones, can be confusing to both visual and non-visual users, but screen reader users face the additional challenge of trying to understand the table layout and structure without having the benefit of seeing the entire table at once. To facilitate screen reader usability, apply correct table markup, as detailed in the table techniques tutorial.

Forms (provide labels using the <label> tag)

Forms can present challenges to users if they are not keyboard accessible. Forms that are automatically activated by JavaScript events are particularly problematic. All forms should have a “submit” button so that those who do not use a mouse can activate them. Also, all forms need to be marked up appropriately. See the form techniques tutorial for information on how to do this.

JavaScript (make sure that scripts are keyboard-accessible)

Ideally, all web content should be accessible even when JavaScript is turned off. Ocassionally, this approach is not possible. In such cases, developers should ensure that the JavaScript events can be triggered by the keyboard alone, and that any scripted content is accessible either in its native format, or in an alternative format.

Document structure (use correct headings, list elements, etc.)

When you use headings, lists, and other structural elements, you provide your users with a logical framework in which to access the content. Some browsers and assistive technologies allow users to navigate through the web page’s structure, in effect exposing the page’s “outline.” See the Content Structure techniques tutorial.

Step 5. Fix all non-HTML issues in the content pages. (In some cases, this means providing an HTML alternative.)

Videos (provide captioning)

Those who are deaf will need captioning and/or transcripts to be able to benefit from video content on the web. Those who are blind will need to have audio descriptions as well.

Flash (incorporate accessibility features)

Flash may not be the ideal medium for accessible content, but the most recent version allows authors to create content that is accessible to the latest versions of screen readers. Use these features. You should also be aware that there are some users who will not be able to access your Flash content at all, no matter what accessibility features you incorporate, either because the user does not have the latest screen reader or because they do not have the Flash player. Also, there are limitations to the accessibility of Flash, even when the accessibility features are incorporated. To the extent possible, you should provide equivalent functionality in a non-Flash format.

PDF (create tagged PDF)

Like Flash, PDF content can be made accessible to the latest versions of screen readers, but will be inaccessible to previous versions. To make PDF files accessible, they must be real text (not scanned), in tagged PDF format, with correct alt text, with logical formatting that can be linearized. The best scenario would be to provide an HTML version in addition to the PDF file.