Section 508: Making Technical Publications Accessible

Home/Publications/Best Practices Newsletter/2005 – Best Practices Newsletter/Section 508: Making Technical Publications Accessible


June 2005

Section 508: Making Technical Publications Accessible

CIDMIconNewsletter Judy Kessler, Sybase, Inc.

What is Section 508-and Why Should I Care?

You are reading this article either from a printed newsletter or in a PDF file on the CIDM web site. Some time today, you answered e-mail, used a web site, a Word file, an electronic spreadsheet, or other software essential to your job. How would you do that if you couldn’t see the screen, use a mouse, or read a printed document?

If you think this is an isolated problem that affects a small minority, think again. Fifty-four million Americans have some sort of disability:

0.5 million are legally blind

1.5 million have low vision

1 in 8 males is color blind

22 million are hearing impaired

0.5 million have cerebral palsy1

Enter the US government. In 1998, Congress amended Section 508 of the Rehabilitation Act to “require Federal agencies to make their electronic and information technology accessible to people with disabilities… Agencies must give disabled employees and members of the public access to information that is comparable to the access available to others.”2

The law affects the private sector too. With rare exceptions, in order to sell to the US government, companies must make their software products comply with the accessibility standards of Section 508. Technical support, documentation, and web sites needed to use the products must also be accessible. Many states have similar laws, and Canada and the EU have rules on adherence to World Wide Web Consortium (W3C) standards for accessibility. Providing access to everyone is not just the right thing to do-it’s good business.

Many assistive interfaces exist to help users with various disabilities. Screen readers read text aloud. Screen enlargers aid low-vision users. Some operating systems, including Windows, allow users to control colors and contrast. By complying with Section 508 standards, information developers ensure that users can take advantage of these tools.

How Sybase Implemented Section 508

Our challenge was to make Sybase user documentation comply with Section 508. Based on our experience, we recommend these eight steps for a successful compliance project.

1.    Learn

2.    Clarify

3.    Plan

4.    Coordinate

5.    Select tools

6.    Create compliant documents

7.    Test

8.    Maintain

1. Learn
Before you begin your project in earnest, learn as much as you can about what the law requires and what your organization hopes to accomplish.

Resources. Most of the resources we consulted are available on the web. Many useful sites exist, though most focus on making web sites accessible. We extrapolated from the web accessibility details to determine what was most needed in our user documentation. If you can, attend meetings that focus on accessibility of electronic information. See the Resources section at the end of this article for a list of sites and groups we found most helpful.

2. Clarify goals and priorities
Making information fully accessible can be a huge task. You must set priorities.

Organizational goals. Find out what’s important to the organization you serve. Is accessible information a life-and-death matter for some of your users? Is it a marketing tool to reach the broadest possible set of potential customers? Is it a business requirement to sell to the federal government? Does your web site or documentation serve the general public? Answering these questions can help you determine where to focus your efforts for the biggest payoff.

Product goals. Within the organization’s overarching goals, your product may have specific goals. For example, the law exempts products whose essential functions would be impaired by following the standards. Sybase chose to make all future user documentation and online help accessible but set priorities on which products to make accessible first. Consult with your product or program manager in setting accessibility goals and timetables.

Focus for documentation. Vision and hearing disabilities are the primary focus of accessibility efforts for information developers. Because our documentation does not include multimedia, we had no need to consider hearing impairment.

3. Plan
Plan your approach to accessibility at the organizational level first. Then plan the implementation for individual products.

At the organizational level

  • Create a project team:
    • Project owner-the senior publications manager in your organization
    • Project sponsor-preferably a VP-level executive, with the clout to ensure you have a budget and cooperation across the organization
    • Project manager-someone who can work across the organization to make sure all the pieces come together
    • Publications advisors-documentation managers, writers, and editors
    • Toolsmiths-authors, programmers, or IT staff who can create whatever scripts, styles, templates, macros, and so on you need, or select appropriate commercially available tools
    • Production or release team manager-whoever can integrate 508 compliance with your release processes
  • Create a task list and schedule for the organization-level project.
  • Determine scope. Decide what your project will include: user documentation, online help, error messages, web sites, or any other forms of information your users may need.
  • Determine deliverable format. HTML? XML? PDFs? Word files? Each of these formats can be made accessible, but each has its drawbacks.

Sybase chose HTML for 508 compliance because it is now our standard means of delivering user documentation, both on CD included with product and on the web. If you deliver the same information in multiple formats, only one needs to be accessible. Note that in order for a software product to be considered accessible, its online help must also be accessible.

A word about PDFs: Many PDF documents and forms are not accessible to the screen readers used by blind persons. For greatest accessibility, create tagged PDFs that can be made accessible. You need Acrobat 6 or 7 to produce them, and screen reader users need Acrobat Reader 5, 6, or 7 to read them. The JAWS 6.x screen reader can read accessible PDFs. Keep in mind, though, that PDFs coded for accessibility may not be the best option for use with screen enlargers used by persons with limited vision. For complete information on creating or reading accessible PDFs, see the Adobe web site, <>.

  • Identify structural elements needed for compliance. Sybase identified these elements and attributes as required for our documentation to be 508 compliant.
    • Structured format-screen readers use structure tags to navigate documentation.
    • ALT text for graphics-the ALT attribute contains a text description of the image that a screen reader can read aloud. Even if the accompanying text adequately describes the image, compliance testing tools usually require an ALT attribute.
    • Table navigation aids-these include table titles and column headings visible to all users, as well as table summaries, column scope, and optional column head abbreviations used by screen readers. Tables should be used for tabular information, not just to lay out information.
    • Color usage-avoid using color alone to distinguish information. For instance, you can precede warning text with a red “Warning!” indicator. But you cannot simply make the text of the warning red without some other text or icon to indicate that this text is a warning.
    • Hypertext links-include a description of the link in addition to the actual URL.

This is not an exhaustive list. Other rules also apply, especially for web sites and multimedia content. Be sure to read the standards for details.

  • Identify support requirements:
    • Technical support-if your tech support group refers users to documentation, that documentation must be accessible.
    • Browser version support-older browser versions may not support the latest accessibility attributes. JAWS, the most popular screen reader, works with Internet Explorer.
    • Platform support-will your company claim compliance on all operating systems or only Windows? Only newer versions of JAWS support Java.
  • Ensure funding. We funded our 508 implementation by including it in a larger project to update our electronic documentation infrastructure.

At the product level:

  • Create a task list and schedule for individual documentation sets or sections of your web site. We used a count of graphics, tables, and pages to estimate the task of adding 508 attributes. This estimate turned out to be high. (On the other hand, our estimate of the time it would take to create infrastructure was low, due to both technical issues and the availability of staff to create and test new tools.)
  • Determine if any optional 508 elements are appropriate. For example, while some screen readers use attributes like capitalization as pronunciation clues, they often get it wrong-especially for the non-words that proliferate in software documentation, like syntax and file names. You can include pronunciation guidance in ABBR and ACRONYM elements, but it takes a lot of effort and some blind users may not care. We allowed each documentation team to decide how much pronunciation guidance to include.

    4. Coordinate
    We found these project elements crucial in coordinating our geographically and organizationally dispersed documentation teams:

    • Monthly conference calls
    • Internal web site
    • E-mail aliases
    • Full team agreement on enterprise
      strategy and infrastructure
    • Small team implementation of
    • Documentation team manager
      integration of 508 plan with other project plans

    5. Select or create tools, templates, guidelines, and other infrastructure

    • Define authoring tool requirements. Whether you use FrameMaker structured documents as we do, MS Word, or any of the many HTML or XML editing tools, you need to ensure that your templates and styles support any required 508 attributes and elements.
    • Define scripting requirements. You may need to create or alter any scripts you use to transform information from the authoring environment to the end format. Remember to include 508 elements in the tools you use to create online help as well.
    • Select testing tools. Many tools exist for testing web site accessibility. For a list of some of the popular ones, see the Boston-IA or Section 508 government sites (see Resources section for URLs). We added 508 validation to our existing conversion scripts.
    • Document internal standards. 508 project team members created guidelines for authors based on our research and monthly discussions and added them to our style guide. Our toolsmith updated our internal FrameMaker User’s Guide with instructions for using our templates and other tools to implement the guidelines. We also added boilerplate text on accessibility to our preface and release bulletin templates.
    • Define release processes. Evaluate your release processes to be sure they support your 508 compliance deliverables.

    June 0528

    Figure 1. Sample VPAT for Documentation and Support

    6. Create 508 compliant documents
    Each documentation team:

    • Adds accessibility elements and attributes to FrameMaker 7 source files.
    • Edits boilerplate accessibility text to reflect product specifics.
    • Creates content on accessibility features of the product: keyboard shortcuts or guidelines for creating accessible applications using Sybase products.
    • Produces a Voluntary Product Accessibility Template (VPAT) section on documentation.

    A word on VPATs. Section 508 compliance is self-certified. Companies may publish a VPAT to specify in detail how their products support each compliance requirement. The VPAT has sections for all major compliance categories, including Section 1194.11, Information, Documentation, and Support. For a documentation VPAT we created for one Sybase product, see Figure 1. Complete VPATs for several Sybase products are available on the Sybase web site, at <>. For more information on creating a VPAT, see the Information Technology Industry Council site at <>.

    7. Test
    Use whatever tool you selected to validate your documentation or web site for 508 compliance. But remember-there is no substitute for experiencing your information the way a user with a disability does.

  • Install a screen reader and use it to navigate through and read aloud your electronic content. It’s a good idea to try this before and after you add 508 attributes.
  • Use a screen enlarger at different magnification levels. Notice what happens when you can only see a tiny portion of your document or web site.
  • Adjust colors on your system and make sure your information communicates everything it needs to.
  • Shut off your screen and try to use the product you are documenting without a mouse, using only the keyboard shortcuts you list.

p class=”Basic-Paragraph”>If you can afford it, hire a blind or visually impaired person to test your information products for compliance.

p class=”Basic-Paragraph”>8. Maintain
Once the initial effort is done, make sure authors continue to maintain and enrich 508 content as they update information. You may need to review evolving standards to ensure ongoing compliance. CIDMIconNewsletter

About the Author

June 0526

June 0524

Screen readers: a primer

  • Experienced users scan auditory information rapidly just as a sighted user scans visual information, but even so, it takes them much longer to read a page (even with adjustable speed)—the average blind user takes ten times longer
  • First time web site users must read an entire home page—keep it simple!
  • Users jump around—navigation help is crucial (layout, links, and column scope for tables)
  • Table summaries and column title abbreviations help users decide what to read and get to the important part quickly
  • Label links with text—Don’t hide links inside pictures. Some users have difficulty using links embedded in text
  • Anything they don’t need just slows users down and may annoy them
  • Group hot keys at the top—Most users go right to the top or bottom of a page or help window

Use markups the way they’re designed to be used


  • JAWS from Freedom Scientific—Download a free JAWS demo from
  • The most widely used screen reader
  • Slow and cumbersome at best, with a long learning curve to use effectively; highly configurable
  • JAWS cursor helps navigate when good links are not easily accessible
  • Handles nested tables
  • Reads underscored list items as “link.” It helps users if links are all first letters of the link list and link names vary. (Think of a menu with eight options where one character is underlined-that’s the hot key. Get users to it quickly)
  • To use Java-based products with JAWS, you need JAWS 5.x or higher and Sun’s Java Accessibility Bridge, downloadable at <>
  • Some companies provide a JAWS dictionary for pronunciation
  • Window-Eyes from Synapse Adaptive—used mid-country
  • HAL and Supernova—used abroad
  • Linux:

    • BEAM XVI for Linux—Screen Reader and Magnifier for X-Windows
    • Jupiter—Features accumulated log of your interactive session plus screen review mode-outputs contents of console and provides other useful console navigation functions via a kernel patch
    • Screader—Screen reader based on Screen package- reads Linux virtual console screen and transmits to speech synthesizer without disturbing the running process
    • Speakup—Outputs contents of the console to the Double Talk internal synthesizer
    • YASR (Yet Another Screen Reader)—For various *nix derivatives; tested with Speak-out, DEC-Talk Express, and DoubleTalk synthesizers
    • ZipSpeak—Talking mini Linux distribution, works with many hardware synthesizers