Web DevCenter    
 Published on Web DevCenter (http://www.oreillynet.com/javascript/)
 See this if you're having trouble printing code examples


A Primer for Accessible Web Pages

by Matt Margolin and Apple Developer Connection
11/30/2001

Section 508

On December 21, 2000, the Access Board, a committee created by the Federal Communications Commission (FCC), published regulations regarding the accessibility of Internet sites. These new regulations require that any web site built or procured by the Federal government must be accessible to the public in the same manner as buildings equipped with curb-cut sidewalks, braille-enhanced elevator buttons, or ramped building entrances. The Access Board's Electronic and Information Technology Accessibility Standards put Web design best practices into law for the first time.

The new regulations became a part of government procurement as of the summer of 2001. That means that web design contracts and federal agency Internet content are subject to strict procurement guidelines and that a company can lose out on a contract if they fail to comply with these guidelines.

The Access Board has been sending out questionnaires and offering specific technical guidelines to each federal agency Web site. Though the Board has found that accessibility problems exist throughout the federal government's sites, many of the problems that they have discovered are easily fixed.

History of a Rule

Before discussing some of the HTML that will make a site compliant with government regulations, it's helpful to understand a little of the guidelines' background. The history of Section 508 demonstrates just how long the government has been involved in aiding those who cannot effectively use a graphical user interface (GUI).

The Access Board, once known as the Architectural and Transportation Barriers Compliance Board, is an independent agency under the aegis of the FCC. Since its creation in 1975, it has supervised guideline development under Section 508 of the Rehabilitation Act, The Americans with Disabilities Act, The Telecommunications Act of 1996, and The Architectural Barriers Act. Section 508 is a part of the Rehabilitation Act of 1973, which requires that any electronic and information technology developed, procured, maintained, or used by the Federal government must be accessible to people with disabilities. Section 508 was originally added to the rehabilitation Act in 1986, a time when activists were lobbying for awareness that the new and popular GUI operating systems were actually less accessible to assistive technology than command-line interfaces.

The government set up the Electronic and Information Technology Access Advisory Committee (EITAAC) as a part of the FCC's Access Board. As one of the committee's several members, the World Wide Web Consortium's Web Access Initiative (WAI) has been very involved in creating official guidelines for Web authoring, including the manufacture of authoring tools and user agents. The majority of the guidelines in Section 508 are taken directly from the WAI's Web Content Accessibility Guidelines 1.0.

Accessible HTML

People with disabilities most often surf the Web using assistive technologies like screen readers and braille displays. These technologies enable people with varying abilities to experience Web content through visually displayed text, tactile reading of braille displays, or hearing speech synthesis of text. The key to each of these methods is that the content all comes from text. Because of this textual foundation for assistive technologies, a simple test can be very useful in determining if a site is accessible. This test is included in a recent report from the Department of Justice regarding Federal agencies' web pages. The test is this: download a text-only browser like Lynx ( Mac, PC), and access the site to make sure that the content renders meaningfully in a text browser. If the content not only renders but is also navigable and conveys the same information, chances are that it is a universally accessible Web page.

As in the past, the government is finding that the problems of making universally designed web pages are wide-spread yet easy to fix. Of the dozen or so web design ideas mentioned in section 508, there are several common critical solutions for authoring Web pages that support assistive technologies. These solutions include <ALT> tags for images, image maps, and tables that visually organize pages.

Comment on this articleWe heard a lot about web accessibility late last year when Section 508 was big news, but not much has been stirring since. What have you heard and seen around this issue?
Post your comments

Web design experience will probably show you that if the web pages you build effectively address these issues, you have gone a long way toward separating a document's content from its design. Early HTML standards and browsers treated Web documents like paper documents; one read them and looked at the pictures simultaneously. Designers used, for instance, <i> tags to italicize text. A tag like this integrates design and content yet doesn't tell a speech synthesizer what to do with the text in italics. The speech synthesizer can't tell if the author intends to indicate emphasis, a citation, or something else. A better choice is to use the <em> tag for emphasis. This tag is more meaningful and can be rendered as emphatic (in italics) by a graphical browser or spoken emphatically by a speech synthesizer.

Following recently released standards like XHTML or HTML 4.01 provides an excellent framework for separating content from design. That leaves only minor changes necessary to come into compliance with the new rules.

ALT Text

Many web sites can solve the bulk of their accessibility issues by providing alternative text for images, especially when images are used for navigation elements. Naturally, then, the first rule in Section 508 (1194.22, part a) concerns alternative text descriptions. Correlating to the W3C's Web Content Accessibility Guidelines 1.0, checkpoint 1.1, this rule requires use of the alt attribute for the <img>, <applet>, and <input> tags, and text equivalents within the <object> and <applet> elements.

Related Reading

Web Design in a Nutshell, 2nd EditionWeb Design in a Nutshell, 2nd Edition
By Jennifer Niederst
Table of Contents
Index
Sample Chapter
Full Description
Read Online -- Safari

HTML 4.0 includes support for "long descriptions" with the longdesc attribute. If a user agent supports longdesc it will render a separate file containing more extensive alternative text in place of the image, applet, or other element.

For example, imagine a Federal agency's web page with a logo for the agency at the top. If there is no alternative way of describing that image in text, a screen reader (or Lynx) will describe that image as just "image" or, at best, it will give the name of the image.

Using the attributes mentioned above would lead to more meaningful results. The following is the proper way for the Federal agency to present an image:

<img src="accessbrdlogo.gif" alt="Access Board logo" longdesc="accessbrd.html">

Given the above tags, there should be an additional file called accessbrd.html, which contains text like the following:

"The Access Board is an independent Federal agency devoted to accessibility for people with disabilities. It operates with approximately 30 staff members and a governing board of representatives from Federal departments and public members appointed by the President."

Additionally, for user agents that don't support longdesc, provide a link to the file that describes the graphic:

<img src="accessbrdlogo.gif" alt="Access Board logo" longdesc="accessbrd.html"><a href="wdadesc.html" title="Description of the Web Design Agency">[D]</a>

Note that this anchor won't show up for GUI browsers because there is nothing within the anchor element.

When using the <object> tag, specify a longer text equivalent within the element's content:

<object data="accessbrdlogo.gif" type="image/gif"> The Access Board's <a href="projected.html">projected budget</a> for Fiscal 2005 is ... </object>

Image Maps

Graphical navigation is a more challenging issue. Image maps, which are frequently used for navigation, have been the subject of much scrutiny. To make image maps accessible, Section 508 requires the use of the <object> tag, alternative text links, and proper separation of text. Here's an example of an image map that has been made accessible with an <object> tag.

<OBJECT data="navigation.gif" type="image/gif" usemap="#mapnav">
<MAP name="map1">
<P>Navigate the Access Board site.
[<A href="guidelines.html" shape="rect"
coords="0,0,118,28">Access Guide</A>]
[<A href="news.html" shape="rect"
coords="118,0,184,28">Go</A>]
[<A href="search.html" shape="circle"
coords="184.200,60">Search</A>]
[<A href="faqs.html" shape="poly"
coords="276,0,276,28,100,200,50,50,276,0">
Top Ten</A>]
</MAP>
</OBJECT>

If you decide to implement this solution, be aware that Navigator 4 does not support the <object> tag. It will render the text links instead of the image.

Notice that the map element is placed within the object element. That way the alternative text links will be displayed only if the image map is not. Additionally, text links are separated by brackets. You should always separate adjacent text links with a space, a printable character, and a space. If they are not separated in this manner some screen readers will read the text as a single link and choke as a result. The best option is to use brackets, as in the code above, or the "pipe" ( | ) character. For example, take a look at the above example and the W3C's front door (which uses pipes) as seen in Lynx.

Image of W3C site in a text browser
W3C Site in Text Browser

Tables

Screen readers read text linearly; that is, they read across the line from left to right. That causes a problem when attempting to render tables meaningfully for assistive technologies. To solve this problem for simple tables, the guidelines call for labeling of table headers.

Use the summary attribute to indicate the meaning of the table and the headers attribute to associate data cells with their proper row or column. In the following example, notice the use of id attribute in the table headers. Each cell in the body of the table then has a headers attribute which relates it to a specific column.

<TABLE border="1" summary="This table charts the number of web pages analyzed by each agency head, what kind of media the pages contain, and whether or not the page is part of the Executive Branch.">
<CAPTION>Web pages Analyzed by Agency Heads</CAPTION>
<TR>
<TH id="header1">Agency Head</TH>
<TH id="header2">Number of pages</TH>
<TH id="header3" abbr="Type">Media</TH>
<TH id="header4">Executive Branch?</TH>
<TR>
<TD headers="header1">A. Jackson</TD>
<TD headers="header2">20</TD>
<TD headers="header3">text, images</TD>
<TD headers="header4">No</TD>
<TR>
<TD headers="header1">B. Franklin</TD>
<TD headers="header2">10</TD>
<TD headers="header3">text, images, video</TD>
<TD headers="header4">Yes</TD>
</TABLE>

A speech synthesizer might render this table as follows:

"Caption: Web pages Analyzed by Agency Heads
Summary: This table charts the number of Web pages analyzed by each agency head, what kind of media the pages contain, and whether or not the page is part of the Executive Branch.
Name: A. Jackson, number of pages: 20, Type: text, images, Executive Branch: No
Name: B. Franklin, number of pages: 10, Type: text, images, video, Executive Branch: Yes"

For more sophisticated tables, like scientific or financial tables that contain a lot of discreet data, use the scope attribute instead of the header attribute. The above example shows how table headers can associate data cells with header id's; scope allows more complex association because it takes attributes for row, col, rowgroup, and colgroup. In other words, scope allows you to group cells together for rendering through another device, which is useful if there is a lot of information. Spoken rendering of the table below will be identical to the table above.

<TABLE border="1" summary="This table charts ...">
<CAPTION>Web pages Analyzed by Agency Heads</CAPTION>
<TR>
<TH scope="col">Agency Head</TH>
<TH scope="col">Number of Pages</TH>
<TH scope="col" abbr="Type">Media</TH>
<TH scope="col">Executive Branch?</TH>
<TR>
<TD>A. Jackson</TD> <TD>20</TD>
<TD>text, images</TD> <TD>No</TD>
<TR>
<TD>B. Franklin</TD> <TD>10</TD>
<TD>text,images, video</TD> <TD>Yes</TD>
</TABLE>

For more information on the use of attributes within tables, see the WAI's tips on working with tables.

A word about using tables for layout: if a table is necessary for laying out a Web page, the guidelines say that the table should "linearize." That means that the contents of the cells should render as a series of paragraphs from the top to the bottom of the page. Cells should make sense when read in row order and should include structural elements, creating paragraphs, headings, and lists.

Why Section 508 Works

Since the discourse over creating accessible Web pages began, the standards organizations that helped inform the new Federal rules have stressed the separation of design and content. If the Internet is to reach its full potential, content will need to be authored so that it can be rendered by a broad array of devices: browsers, assistive technologies, PDAs, and devices that have yet to be imagined. Only by separating content from design will this be possible.

By following the rules in Section 508, you will be doing more than providing access for those with disabilities; you will be creating content that is available to all users, no matter what devices are used to read it.

Matt Margolin


Return to the JavaScript and CSS DevCenter.

Copyright © 2009 O'Reilly Media, Inc.