Accessibility = Usability

By Rosalind Rogoff

Rosalind will give a more detailed presentation on this information at the Writer in the Workplace Conference in Sacramento in April.

I’ve been hearing about how we are in a recession and jobs are getting scarce. Technical writers are the first to be cut. Hasn’t that always been the case? But new jobs and technologies keep springing up, and technical communicators should be in line to grab them. Instead we seem to be as much in the dark over leading edge careers as the people whose accessibility needs are creating new potential career paths for technical communicators.

Ten years ago Congress passed the Americans with Disabilities Act. This resulted in improving accessibility in buildings, elevators, sidewalks, parking lots, and bathrooms. Most of these accessibility features were aimed at individuals with mobility problems, such as walking with crutches, or being wheelchair bound. Informational accessibility still resided in older technologies: Braille and audio books for the blind and TTY (Teletype) phones for the deaf.

With the popularity of the Internet and World Wide Web, access to information, especially for visually impaired, became an issue again. In 1998 the W3C formed the Web Accessibility Initiative committee (WAI). The WAI came up with voluntary guidelines for making web sites accessible. In December 2000, accessibility requirements, based in part on the WAI guidelines, were added to Section 508 of the Federal Rehabilitation Act. Section 508 mandated that information systems used by federal agencies meet these requirements by August of 2001.

Now information accessibility is the hot new technology. Even though the law only applies to federal agencies, many corporations and web sites are looking at voluntary compliance. The issue is one that should be familiar to any technical communicator—user interface and usability. A blind user cannot use a Graphical User Interface and a mouse, or not very easily. All the usability tests done on sighted people have no validity for the visually impaired.

Seeing the Web

So how do blind people "see" the Web? Usually with screen readers, or Braille readers. Braille readers convert text on a screen to a Braille pad. This is an older technology that worked with mainframe computers back in the 1980s. Screen readers use Text to Speech (TTS) to convert the text on the screen to voice.

The problem with some computer applications and web sites is they are not designed for screen readers. If text is in tables, which are viewed in columns, the screen reader might read the line horizontally, which would make no sense. If the page is full of graphics and flash animation, the visually impaired person cannot know what these graphics are unless they have <alt> tags to describe them.

There are many design elements in a web page or computer application that are inaccessible not only to the visually impaired, but to people with far more common disorders, such as color blindness, dyslexia, and other reading problems. For example, if color-coding is used to differentiate elements on a screen, these elements must be differentiated in some non-visual way as well.

Let’s Catch Up

Once again it appears that human factors engineers have leapfrogged over technical writers into the lead as accessibility consultants. STC members seem bogged down in the old-fashioned career path of technical writer, technical publications, help author, and now maybe Web content designer. But if accessibility equals usability, let’s get in line where we belong.

Quick Tips to Make Accessible Web Sites

Reprinted from the WAI web site.

  • Images & animations. Use the alt attribute to describe the function of each visual.
  • Image maps. Use the client-side map and text for hotspots.
  • Multimedia. Provide captioning and transcripts of audio, and descriptions of video.
  • Hypertext links. Use text that makes sense when read out of context. For example, avoid "click here."
  • Page organization. Use headings, lists, and consistent structure. Use CSS for layout and style where possible.
  • Graphs & charts. Summarize or use the longdesc attribute.
  • Scripts, applets, & plug-ins. Provide alternative content in case active features are inaccessible or unsupported.
  • Frames. Use the noframes element and meaningful titles.
  • Tables. Make line-by-line reading sensible. Summarize.
  • Check your work. Validate. Use tools, checklist, and guidelines at w3.org/TR/WCAG.

Accessibility References

Talk to Your Computer, Newman, Dan. Waveside Publishing, 1999.
Web Accessibility for People with Disabilities, Paciello, Michael G. CMP Books, 2000.
Computer and Web Resources for People with Disabilities, The Alliance for Technology Access, 3rd Edition, Hunter House, 2000.
Bobby WorldWide. On this web site you can download software that:

  • Analyzes sites using the U.S. Federal Government’s Section 508 guidelines
  • Analyzes sites using the WAI Conformance A, AA, and AAA guidelines

The Devil Mountain Views -- Mar/Apr 2002
(ebstc.org/newsletter/front.html)
For  suggestions, complaints, or (especially) compliments, contact dmveditor@spire.com