After you put your next issue to bed, before you sit back and bask in that fleeting sense of accomplishment, take another look at your publication — with your monitor turned off.

That's the experience of millions of Web surfers with visual disabilities. If you've done your job well, they should be able to access your content using screen-reading software (software that reads the words on the page aloud). But chances are that lurking within your journal are tables, image maps, Flash animations, and Acrobat files that present the equivalent of a black screen.

Now let's say you've thought ahead, maybe spurred into action by my earlier column "Access Code," and put some work into making your journal accessible to the visually impaired. Congratulations. Unless, that is, your journal also includes audio or video content that's not accessible to those with hearing impairments.

A sizeable problem

The U.S. Census Bureau reports that more than 54 million Americans have a disability. In many cases, those disabilities do not interfere with use of the Internet. But people with visual, hearing, speech, and motor disabilities often face challenges in accessing online information. That becomes even more important when you realize that Web surfers with disabilities spend twice as much time online as their able-bodied counterparts — 20 hours a week, not counting sending and receiving e-mail — and in many cases they rely much more heavily on the Internet for research and shopping.[1]

Accessibility issues have taken on even greater urgency because of the changing ways people are beginning to access the Internet, a topic I mentioned recently (see "The X(HTML) Files.") For instance, Web access is an increasingly important selling point for cellular-phone users. Plenty of other people access Web content through Palm Pilots, WebTV, Internet kiosks, in-car PCs, and other non-standard means. Add to that the aging population — with its decreasing visual, hearing and motor skills — and you have a compelling argument to pay careful attention to providing universally accessible Web content.[2]

Here comes the judge

If those points don't convince you that you need to start thinking seriously about accessibility, perhaps this one will: Accessibility to Web content is becoming codified in the law, and lawsuits are not uncommon. Section 508 of the Federal Rehabilitation Act of 1998 states that Federal agencies must ensure that

• individuals with disabilities who are federal employees have access to information that is comparable to the access available to employees who do not have disabilities; and
• members of the public who have disabilities have the same access to information from federal departments and agencies as do people who do not have disabilities.

Obviously, these provisions have consequences for anyone working for the federal government, whether in a governmental agency or as a private contractor. But those are hardly the only people who should take notice. Lawsuits have already been filed against municipal agencies and America Online for failure to provide information in an accessible manner.[3](The suit against America Online by the National Federation of the Blind of Massachusetts was settled out of court. AOL has added accessibility features to the latest version of its software, and the company now displays its accessibility policy prominently and distributes it to all employees.)

Still doesn't sound like a ticking time bomb? Then listen to Michael Paciello, one of the leading experts on the topic: "I believe private publishers have plenty to be concerned with — particularly as laws including Section 255 of the Telecom Act, Section 508 of the Rehab Act, and the ADA are applied to the Web and Internet."[4]

Blame it on Mosaic

Virtually since the day the Web reached the public's consciousness, universal accessibility has been a goal. In its 1995 report, the National Information Infrastructure Advisory Council made that clear by making accessibility central to four of the seven principles in its first report. Among the most important points:

• Every individual should have access to the National Information Infrastructure (NII) by the year 2005. This goal would include defining basic levels of access and service capabilities and the deployment of an interactive, multimedia infrastructure.

• All individuals should be able to be both consumers and producers of information and services on the NII.

• Individuals with disabilities should have access to the NII and, therefore, design issues should be addressed as the NII is developed to ensure access for all individuals with disabilities.

• Information from all levels of government should be readily accessible over the NII.

Unfortunately, the Web scored much higher on accessibility for some users with disabilities in 1995 than it does five years later. In the early days, all information was textual and highly usable by those with visual disabilities. With the introduction of the Mosaic browser, the Web became much more graphical, in the process creating barriers for the visually impaired.[5] Increased multimedia content has caused similar problems for those with hearing impairments.

Basic guidelines

This brings us back to the present and the problems presented by a graphic-heavy Web. While they are many, they are not insurmountable. The best place to start your education in creating accessible content is the World Wide Web Consortium's Web Content Accessibility Guidelines. As an introduction to those guidelines, we'll look at several areas of particular importance in adhering to them.

Before focusing on any of the specific points that follow, however, it's critical that you first validate your code. HTML errors can render otherwise wonderful pages useless in many alternative browsers. As mentioned in a recent column, HTML Tidy does a great job of validating HTML, and is available as a standalone download or in the HTML-Kit editing software. A Macintosh equivalent, Tidy for Mac OS, is also available.

Once you've done that, you'll want to focus on several specific aspects of your content:

• Page organization

  If you haven't already broken the bad habit of using HTML for layout, here is yet another reason to do so. Use Cascading Style Sheets for design, and reserve HTML to present your content in a logical order (e.g., the H1 tag points to top-level headings, H2 to the next level, and so on) — as they were designed to do.

• Tables

  While some screen readers can make sense out of pages built with tables, others are not as successful (and alternative browsers used to access information may render pages built using tables as total messes). One solution is to create an alternative version of pages built on tables and add the LINK tag to the page's HEAD section. The LINK tag can specify what type of media the linked page supports: aural, Braille or tty (teletype). If a user's browser can support that type of media, it will automatically load the linked page. Here is an example of the code indicating that a linked page is available:

  <head>

  <title>Example of linked page</title>

  <link title="Accessible version" href="newfile.html" media="aural, Braille, tty"

  </head>

  If you're using tables for their intended purpose — the tabular presentation of information — you can increase the accessibility of information in them by using new features supported by HTML 4.0/XHTML 1.0:

  The CAPTION tag, inserted directly after the opening table tag, allows you to insert a short description of the table's content:

  <caption>Comparisons of three screen readers</caption>

  The SUMMARY attribute of the table tag summarizes the purpose of the table. It is not displayed on traditional visual browsers, but can help users interpret the output of voice- or Braille-based browsers:

  <table summary="This table provides a comparison of the features and cost of a range of screen readers and indicates which platforms they work on.">

  The HEADER attribute of the table data tag lets surfers who cannot see the relationships within a table still have a clear idea of them. This attribute is easy to use, but is too complex to deal with here. More information is available in the HTML 4.01 specification for tables.

• Images and image maps

  While most Web publications and journals rely primarily on text for presenting information, they also commonly include images and animations. Those items are used for a wide variety of purposes, from purely ornamental to providing illustration or navigation. The problem occurs when no alternative is offered for the visually impaired. For example, at the time of this writing, the home page of the university where I teach was composed almost entirely of images and image maps with no ALT attributes. If you compare the page as seen by a nondisabled user with what's available to a surfer using the Lynx text browser, you'll see that the user with visual disabilities loses the ability to access most options. The solution here is simple: Always make sure you include an ALT attribute for all images and image map links. The more important or complex the image, the more information you should provide. Two additional steps can help you present the most thorough information:

  Use the TITLE attribute rather than the ALT attribute. On some late-model conventional browsers, the text in the TITLE attribute will appear as a user mouses over an image. (Notably, this wasn't added to Netscape until version 6.0) Screen reader software will read the text to the user.

  If you need a great deal of text to explain an image, add the letter "D" (for "description") as a link directly under the picture and use it as a link to a separate HTML file that provides a lengthy description.

• Hypertext links:

  Avoid empty link text such as "click here" and instead use the link text to indicate what a click will bring. This is particularly important when links might be accessed out of context (such in a list of links generated by a screen reader program).

• Forms: Forms can present special challenges to the visually impaired. The SELECT, OPTGROUP and OPTIONS elements can help make forms more useful.

• Frames:

  Frames have been fading since their height of popularity in the mid-1990s, and that's a good thing. If you have to use frames, give them meaningful titles and provide a NOFRAMES option.

• Audio and video files:

  Audio files should always be accompanied by a text version of the content. Video files should be captioned. RealMedia, Windows Media and QuickTime all support captioning. WGBH's National Center for Accessible Media offers a free caption authoring tool known as MAGpie (Media Access Generator). MAGpie makes it easy to create captions for all three major multimedia formats.

• Acrobat files:

  While I praised Adobe's Acrobat format recently ("The Format Wars: HTML, PDF, and TXT"), PDF files can create a great barrier to the visually impaired. The best option is for publishers to provide text-only versions of all documents available as PDFs. To help prepare the text files, Adobe offers a selection of free tools for converting documents on a local PC (Windows only) or on the Internet.

• Flash movies:

  In a recent Alertbox column, Jakob Nielsen criticized the growing use of Flash animations for a host of reasons, most of them valid.[6] But Nielsen's assertion that "Flash reduces accessibility for users with disabilities" is not entirely accurate. Flash does allow developers to provide text representations of content, which can then be understood by browsers that use assistive technologies. In addition, zoom commands allow users with poor visibility to increase the size of Flash animations by up to 2,000 percent. (For more on this issue, see Macromedia's overview of Flash accessibility features [formerly http://www.macromedia.com/macromedia/accessibility/features/flash.html.])

Meeting the objectives

This list is by no means complete. But don't let that make you think that accessibility is an unrealistic goal. Several tools and online resources can help you produce accessible pages quickly.

Your first stop should be the Bobby online accessibility tester. There, you can enter the URL of a Web page and get a report of browser compatibility and accessibility errors. If you'd like to test your work before uploading it to the Web, a stand-alone version of Bobby [formerly http://www.cast.org/bobby/index.cfm?i=316] is available for download. That version can check multiple files or entire site, but it may not work with large files.

You also can check files during the development process if you use the proper tools. For example, Macromedia offers an accessibility extension [formerly http://www.macromedia.com/macromedia/accessibility/features/dreamweaver.htm] for its popular Dreamweaver program. In addition, Dreamweaver offers built-in support to increase accessibility of images, maps, tables and frames, as well as integration with a third-party product that allows users to interact with Web pages by using their voices.

Even after you've used these tools, it can still be an eye- or ear-opening experience to see how your pages perform for nontraditional users. If you have access to a Lynx browser, run some of your work through and see how it fares. It's also useful to hear how your content is delivered with a page reader. IBM offers a free trial of its Home Page Reader [formerly http://www-3.ibm.com/able/hpr.html], a great tool for this purpose.

Finally, there is no shortage of accessibility information online. A few of the best sites for accessibility information are WebAIM, WebABLE, CAST, and the Trace Center at the University of Wisconsin. The four provide links to tools, tutorials and a wealth of other information. Offline, Michael Paciello's Web Accessibility for People with Disabilities is must reading for anyone involved in Web publishing at the dawn of the 21st Century. And if you'd like to see a model of Web accessibility, check out the Smithsonian Institution's online virtual exhibition on the Disability Rights Movement.

The author thanks Steve Konick of Turner Consulting Group for editorial review.

Thom Lieb is an associate professor of journalism and new media at Towson University in Baltimore. Among his courses is Writing for the Web. He is the author of Editing for Clear Communication and has written and edited for magazines, newspapers, newsletters and online publication. He holds a Ph.D. in Public Communication from the University of Maryland at College Park and a master's of science in Magazine Journalism from Syracuse University. You may contact him by e-mail at [email protected].

Supplementary Images

Notes

1. Alison Stein Wellner, The Internet's Next NicheAmerican Demographics, September 2000. [formerly http://www.demographics.com/publications/ad/00_ad/0009_ad/ad000905e.htm]

2. Michael G. Paciello, Web Accessibility for People with Disabilities (Lawrence, Kansas: CMP Books, 2000), 211.

3. Paciello, "Web Accessibility," 26-30.

4. Michael G. Paciello, "Re: Information Request," 26 October 2000, personal e-mail (26 October 2000).

5. Paciello, "Web Accessibility," 139.

6. Jakob Nielsen, "Flash: 99% Bad," Alertbox, 29 October 2000

Links from this article:

Thom Lieb, "Access Code," Journal of Electronic Publishing, June 1998.

Thom Lieb, "The X(HTML) Files," Journal of Electronic Publishing, June 2000.

America Online Accessibility Policy http://www.corp.aol.com/ac cess_policy.html

World Wide Web Consortium's Web Content Accessibility Guidelines http://www.w3.org/TR/WAI-WEBCONT ENT/

HTML Tidy http://www.w3.org/People/Ragge tt/tidy/

HTML-Kit http://www.chami.com/html-kit/

Tidy for Mac http://www.geocities.com/SiliconValley/1057/tidy.html

HTML 4.01 specification for tables http://www.w3.org/TR/html4/struct/tables.html

HTML SELECT, OPTGROUP and OPTIONS element specifications http://www.w3.org/TR/html4/interact/forms.html#h-17.6

Thom Lieb, "The Format Wars: HTML, PDF, and TXT," Journal of Electronic Publishing, September 1999.

MAGpie caption authoring tool http://www.wgbh.org/wgbh/pages/ncam/webaccess/magindex.html

Adobe PDF Accessibility Tools http://access.adobe.com/

Macromedia's overview of Flash accessibility features [formerly http://www.macromedia.com/macromedia/accessibility/features/flash.html]

Bobby online accessibility tester [formerly http://www.cast.org/bobby/]

Downloadable version of Bobby [formerly http://www.cast.org/bobby/index.cfm?i=316]

Accessibility extension for Macromedia Dreamweaver [formerly http://www.macromedia.com/macromedia/accessibility/features/dreamweaver.html]

IBM Home Page Reader [formerly http://www-3.ibm.com/able/hpr.html]

WebAIM http://www.webaim.org

WebABLE http://www.webable.com

CAST http://www.cast.org

Trace Center at the University of Wisconsin http://trace.wisc.edu/world/web/

Smithsonian online virtual exhibition on the Disability Rights Movement http://americanhistory.si.edu/disabilityrights/

In the next issue of JEP, the Q.A. column takes a look at privacy practices and policies of online journals. Please let us know how you're addressing this sensitive topic by completing a brief survey [formerly http://www.press.umich.edu/jep/jepsurvey.html.] It will take only a minute or two. Your help is greatly appreciated.