Go back to Articles menu

Practical accessibility: Core concepts

One of the defining principles of the Web is that it should provide all people, regardless of physical or technological readiness, with access to information. Since the Web took off as a visual medium, the goals of design have been at odds with the goals of accessibility. When designers began to use large images, proprietary media formats, and complex page layouts to produce well-designed documents, the Web became a better-looking place, but those users who require clean HTML for access were shut out from many pages. Today, the course of Web design is shifting back to its original purpose. HTML has matured to offer more visual controls, so designers have more tools at hand to create structured and navigable Web sites without resorting to hacks and workarounds. Around the world, initiatives are under way to mandate that disabled users have equal access to Internet resources, including the guidelines issued by the Web Accessibility Initiative of the World Wide Web Consortium and, in the United States, the amendments to Section 508 of the Rehabilitation Act of 1973. The result is that Web interface design is intricately tied to accessibility design. It is the responsibility of Web designers to understand and support the needs of disabled users.

In this article we will review some of the basic requirements for accessible design, with a focus on the overarching concepts and techniques that constitute an accessible Web page. For specific details at the code level, download the Accessible Design Guidelines from the Resources area of the site.

Accommodate assistive technologies

Blind users are most likely the people most affected by your Web design choices. Most blind users use screen reader software, a speech-enabled browser, or a braille display, and designing pages that are understandable when "read" by these devices is the biggest challenge for Web developers. Users with cognitive or learning disabilities also use screen reader software; having the text read aloud while reading along visually greatly enhances their ability to understand the materials. Assistive technologies transform text into something that is accessible. But the Web is not only about text, and any non-text item on a Web page presents a potential barrier for visually disabled users. Accessible design means supplying alternative text for any non-text element.

Design flexible pages

Many disabilities can be accommodated by standard browser software as long as the Web pages are flexible and can transform to meet the viewer's needs. For example, color-blind users can apply their own text and background color to a page to increase legibility, or low-vision users can scale type to a size they can read comfortably. Some low-vision users read better with white text on a black background. Accessible design means designing pages that hold up to these transformations - that remain legible and navigable under different viewing conditions.

Provide alternatives

Sometimes designing accessible pages is simply a matter of telling the same story different ways. For example, users with cognitive or learning disabilities benefit from having audio descriptions available as well as text, so you might include "audio notes" to accompany your text content. You might also use images for navigation and page content, which would make your pages more accessible to these users. Deaf or hearing-impaired users, as well as others, benefit from captions with video content. Accessible design means providing an equivalent version whenever you include content in a modality that may not be accessible to users.

How to design accessible Web pages

You can read guidelines until you're blue in the face, but until you experience Web pages as a disabled user would it's hard to put guidelines into practice. Most of the available guidelines make pronouncements about what you should and should not do, but don't explain why, what the gain is when you follow the guidelines, and what is lost when you do not: What does it mean to "Clarify natural language usage" and how do I do that? The best way to answer such questions is to work with screen reader software like IBM's Home Page Reader (HPR), and hear the glitches and bang up against the barriers on your pages. Most developers check their pages for consistency on different browsers and platforms. For an accessibility check, view your pages with different preference settings, and also using HPR. While there are likely even more non-standardized assistive devices out there than there are non-standardized Web browsers, you can establish a baseline: if the pages make sense in HPR then hopefully they will transfer with at least a measure of grace to other devices.

Designing accessible layout tables

Most people think that accessible design means giving up layout tables, which is currently the only way to really design Web pages. Indeed, the Web Content Accessibility Guidelines discourage the use of layout tables, but in the same breath they acknowledge that style sheet positioning - the only real option to layout tables for positioning elements on a page - is not adequately supported by browser software. So it appears that layout tables are still the only way to go, and the good news is that, when they are carefully designed, the newer screen reader software reads tables quite handily. As long as Web authoring tools like Dreamweaver and GoLive use layout tables as their underlying page formatting device, tables will not go away anytime soon. Assistive technologies will just get better at understanding them.

Design tables that make sense when linearized

Some screen reader software literally reads the screen, meaning it starts in the upper left-hand corner and reads from left to right. This turns Web pages with multi-column layouts - in other words, most Web pages - into complete gibberish. However, newer software actually looks at the underlying page code and reads that instead. Indeed, tests with HPR have been encouraging since the software is not reading the rendered screen but instead the parsed HTML code. With this software the table cells are linearized, or read cell-by-cell. To design a table that makes sense when read aloud in this fashion, make sure to group related content. For example, put all your navigation links in one cell and your main content in another. A good way to check your tables is to save a page as "text only" from the browser and see if the text flow makes sense in a single-column format.

Use flexible layout tables

A flexible layout table is fluid - it scales to fill the browser window, it resizes to accommodate its contents. Explaining the how-tos of designing flexible layout tables is beyond the scope of this article. For the purposes of accessible design, page layouts must be flexible to accommodate adjustments such as enlarged type.

Use logical markup

There are many good reasons for using logical markup. Machines cannot read pages that are formatted with presentation-style markup as effectively as with logical tags. For example, if you include italicized text in your body text is it for emphasis? Is it a foreign word? Is it a citation? If you mark it as <I> a machine cannot know what it means. If you mark is as <EM> then the machine knows it's for emphasis. If a screen reader reads the page it can convey emphasis to a blind user. If the text is italicized with physical markup the blind user will miss the emphasis entirely. For accessible pages, use logical markup to describe the structure of your document - to describe what you mean - and use CSS to control presentation - to describe how you want things to look.

Page information

Copyright 2001 Sarah Horton
Added: 15 June 2001
Updated: 29 June 2001, 30 Sept 2001

Go back to Articles menu