Four Web Accessibility Myths — Busted

There's no doubt that following best practices for Web accessibility is an important step in ensuring that your organization's Web site is open to all visitors, regardless of disability. But keeping tabs on what those best practices are can be difficult, especially when Web technologies are changing so rapidly.

The World Wide Web Consortium (W3C), the body that oversees many Web standards, last published its Web Content Accessibility Guidelines in 1999. Though an update is in the works, the intervening years have led to a number of debates and myths about how certain guidelines should be applied.

TechSoup recently checked with the experts to help clarify four of these accessibility myths. Here's what we learned.

The Myths

Myth 1: You must provide alternate text for every image on a Web page, via the alt attribute.

Using the alt attribute to describe an image for visitors with visual impairments is great — except when you start describing images that don't provide much additional information to a page. Then, you could actually be making the experience worse for visitors who are using screen-reader technology, like Freedom Scientific's JAWS, which reads the text on your Web site in a linear fashion.

"Many developers assume that blind users will want to know details about every graphic," said Jane Berliss-Vincent, Director of Adult and Senior Services at the Center for Accessible Technology. "However, most blind users I've worked with are much more interested in being able to traverse the page quickly, and dislike having to listen to large amounts of text that they may deem irrelevant."

Berliss-Vincent recommends the following guidelines for developers:

• Provide some type of text description for graphics that convey information — for instance, bitmapped text and charts. You can provide this information via alt attributes or in the body of the page, such as in a caption — but not both. If you provide a caption, just include a blank alt attribute (alt="") in your IMAGE element; otherwise, screen readers will speak both the attribute and the caption, which is redundant.
• Images that are used purely for presentation and decoration should be inserted into the page via cascading style sheets (CSS) or else you should provide a blank alt attribute (alt="") in the IMAGE element.
• Use your best judgment on graphics that fall somewhere in between, taking your cues from the context of the page. For example:
  • On U.S. Vice President Dick Cheney's Web site, a stock photo of him would probably merit a blank alt attribute.
  • On a satiric Web page that says, "Here's something you don't see every day!" alongside a photo of Cheney smiling — with no other description — an appropriate alt attribute would be alt="Dick Cheney smiling".
  • On a page that covers sartorial trends among vice presidents, use a blank alt attribute if Cheney's clothing is described elsewhere; provide fewer than 80 characters of alt text if you are only describing one feature, like "Dick Cheney's tie is red with purple spirals"; or provide an inline description (or use the related longdesc attribute) to describe his entire outfit in detail.
• No matter what the graphic, short alt attributes are usually better than long ones and should not exceed 80 characters.
• At the least, a blank alt attribute is necessary in every IMAGE element. This is critical for meeting accessibility requirements because, without it, many screen readers will speak the location of the image, which is an impediment to users trying to scan a page quickly.

Myth 2: You must fill out the title attribute for every link.

Some Web browsers display the text of the title attribute as a "tool tip" — a little box that pops up when a user puts the mouse cursor over the link or other element where a title has been specified. Unfortunately, this has led many Web content developers to get lazy about writing clear and unambiguous link text. (After all, why rework a sentence to make it clear where a link points to when you can just provide additional information about the link in a tool tip?)

To make matters worse, Web usability expert Jakob Nielsen tied the title attribute to accessibility when, in a 1998 Alertbox column, he stated incorrectly that "auditory browsers will read the text aloud and not display it visually."

In truth, many users of screen readers don't enable the option to access the title attribute information, according to a survey of title attribute access by Web Accessibility Consultant Steven Faulkner. Likewise, visitors who use screen-magnifying technologies may not be able to see the entire text of the title attribute when it pops up in a tool tip.

As Faulkner points out in a related presentation on the title attribute, the title has its place — but the most accessible thing you can do for a link is make sure that the link text is well written.

One way to test the clarity of your link text is to imagine all your links listed sequentially. (Many assistive browsers, like JAWS, will actually list your links this way to help users navigate your site more quickly.) If you notice that several links that appeared fine in the context of the Web page now seem ambiguous, go back and make them more descriptive. For instance, a link to "article" may be better as a link to "John's article about accessibility."

Myth 3: You should only use TABLE elements for displaying data and never for laying out the components of your Web page.

Before Cascading Style Sheets (CSS) offered a way to lay out Web pages independently of the content itself, innovative Web designers figured out that they could use HTML tables to visually display content in neat rows and columns. Problem was, many assistive technologies at the time were designed to treat tables in their originally intended manner — which was to present tabulated data.

The developers of many assistive technologies have since upgraded their products to cope with most table-based layouts. For instance, JAWS by default ignores any tables that have just one row or just one column; and users can further customize these settings according to their own preferences.

Still not convinced? The Web sites of the Center for Accessible Technology, Freedom Scientific, the American Foundation for the Blind, and the American Disability Association all use tables for layout.

Now, this is not to say that you shouldn't bother to learn how to lay out Web pages with CSS — because you should. But if you're maintaining a number of existing Web pages that rely on table layouts, you have more leeway than you might think.

Myth 4: You shouldn't use JavaScript on your Web site.

Many Web designers and developers avoid creating rich user interfaces with JavaScript under the assumption that the scripting language will foil assistive technologies. But when used wisely, JavaScript can actually extend the accessibility of a site.

For instance, JavaScript can be used to enable keyboard shortcuts that trigger certain actions on a Web page — an important part of making sites accessible for users who can't use a mouse.

"That's proof that JavaScript is not the culprit," said Nate Koechley, Senior Engineer and Design Liaison at Yahoo. "The culprit is not thinking about all the different interface actions and the effects they have."

By staying away from JavaScript, many developers and designers unnecessarily hold themselves back from using common user interface tools that can enrich a Web site, like sliders and pop-up calendars. However, as Koechley and Yahoo's Accessibility Project Manager Victor Tsaran recently pointed out in a presentation on Yahoo's experiences (3MB PPT), these tools can be accessible so long as developers adhere to Web standards, provide other means of input, and think carefully about how the tools will work.

A 2003 FAQ by Freedom Scientific offers these guidelines for ensuring that JAWS users will be able to access JavaScript features:

• The scripts must be activated by clicking a link or clickable item and the script dynamically updates the HTML source.
• The scripts should not update the page without user intervention.

Testing, Testing

The W3C hopes to clear up a lot of the confusion surrounding Web accessibility with the release of Web Content Accessibility Guidelines 2.0. Whereas the first version focused mainly on HTML, WCAG 2.0 provides accessibility techniques for a broader range of technologies, including style sheets, multimedia, scripting, and applet technologies. The W3C will also provide supporting materials to help developers better understand the reasoning behind the new guidelines.

It's unclear when the new version will be officially released, but until that time, Berliss-Vincent recommends that Web designers and developers continue to follow WCAG 1.0 — and to seek assistance from accessibility experts. "It is also crucial to involve users with disabilities in the Web site testing process," she said. "Collect their feedback on what works and doesn't work for them, and compensate them for their time."

Koechley agrees that testing is critical to determining the accessibility of your site. "There's no real substitute for testing and putting it in front of users," he said. "You know how when you print out a map from a service like Yahoo Maps and there's a disclaimer that you should 'verify the directions with reality'? It's the same thing here."