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.
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.
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.
|
|
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.
|
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
|
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>
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.
|
|
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.
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.
Return to the JavaScript and CSS DevCenter.
Copyright © 2007 O'Reilly Media, Inc.
