AHRQ Publishing and Communications Guidelines
Appendix 2-C. Creating Accessible Files and Technologies
Complying With Section 508
Section 508 of the Rehabilitation Act of 1973 requires Federal agencies to make all electronic and information technology accessible to individuals with disabilities, unless an undue burden would be imposed on the Agency. If an undue burden is determined by HHS—an extremely high bar—the information or data must still be provided in an alternative format.
Agency-sponsored Web sites and resources operated either directly, or by grant or contract, must comply with Section 508. Ensuring compliance and accessibility is not optional. AHRQ and HHS take accessibility very seriously. In addition to doing the right thing by ensuring access to Government information for all Americans, Section 508 is a legal requirement and AHRQ must comply with it.
HHS employees must ensure that all electronic information and technology comply with accessibility requirements, including new or revised information made available on the Internet and Intranets. Electronic and information technology includes:
- Software applications and operating systems.
- Web resources and applications.
- Telecommunication products.
- Video and multimedia products.
- Self-contained and closed products (such as information kiosks).
- Desktop and portable computers.
Specific guidance is available from these sources:
- Technical guidance on Section 508 standards by the U.S. Access Board
- HHS 508 Web standards and guidance
- AHRQ 508 Coordinator (Web):
Biff LeVee, 301-427-1897, email@example.com.
Keep these broad accessibility guidelines in mind; specific requirements are in the Section 508 standards.
Content must be readable by screen readers (which read text aloud) or Braille readers. Contrast must be sufficient for persons with certain visual disabilities. Ensure that any information conveyed with color is conveyed equally well when color is not available. Asterisks or other textual cues can be used in addition to the color to convey information.
Links and hot spots should be large enough so someone with limited fine muscle control or mobility and vision impairments can click the link.
Synchronized captioning or transcripts for multimedia files must be provided in various circumstances. For example, if multimedia objects with sound are embedded in PDF documents, both the deaf and the deaf-blind are excluded if there is no transcript. In addition, synchronized captions for video must be supplied for users who are deaf; they need these if the video does not make sense without sound.
Web Development Features
Accessibility needs to be built into the development process for any new or updated Web-based resource. Basic features to be addressed include:
- Providing text equivalents for images, sound, and multimedia features, such as alternate descriptive text ("alt text") for images for the blind and captions for audio-video files for the deaf. All streaming media must have written transcripts or captioning.
- Ensuring that information does not rely on color for sense without alternate text and that color contrast enhances readability for the sighted and does not create barriers for the color-blind.
- Coding so that tables, content or interface elements provided by scripts, and image maps may be read with assistive technology, such as screen readers.
- Controlling the screen flicker rate and the use of blinking or flashing features.
- Using text-only pages as alternatives if needed for accessibility, while maintaining these pages on the same schedule as primary pages.
- Linking to applets, plug-ins, or other applications that must be downloaded.
- Creating accessible forms for business processes on the Web.
- Allowing users to avoid repetitive navigation links and to request additional time on pages that require timed responses.
- Ensuring that navigation and functions such as forms and drop-down lists can be used if only a keyboard is used.
If fully accessible, HTML documents are the gold standard for users with disabilities because assistive technologies make the information accessible across platforms and without proprietary technologies.
Alternate Text for Accessibility
For all images with content (such as buttons, figures, and charts), alternate text must be used so disabled users can access the information in the image. Every image must have an alternate text tag, even if it is null (alt="") for decorative images. Refer to the Section 508 Web standards for more information.
The “alt” tag in HTML code is read aloud by screen readers or Braille readers. With many browsers, you can see it by holding the cursor over the image (below). Alternate text can also be provided as content in the document.
For basic images, alternate text is straightforward and it should:
- Be accurate and equivalent in presenting the same content and function as presented by the image.
- Be succinct. The correct content (if there is content) and function (if there is a function) of the image should be presented as succinctly as is appropriate.
- Avoid using the phrases "image of ..." or "graphic of ..." to describe the image.
Alternate text is provided for complex images in other ways. The alt tag must still be used, with a longer description elsewhere. There are two recommended methods:
- Provide the full description in the document itself. For example, alternate text can be under the image (as in a caption) or refer to a description elsewhere in the document.
- Provide a link to a full description with a normal text link. For example, under the image of this figure, there is a link to "Read Text Description" which goes to a dedicated page of alternate text.
Some images are too complex to meaningfully explain all of their information as alternate text. In such cases, capture the essence of the image—what it means—without all the detail. For example, giving the 80 data points in a graph might be less informative than describing a trend and what it means. If a graph is meant to present the data, however, the alternate text must reflect that.
The context of the image should determine the content of alternate text. For example, the specific characters in a "screen shot" would not be helpful if the image is only intended to convey what the screen looks like. In that case, describing the interface might be more important.
Creating Accessible Files and Formats
All downloadable files and Web technologies must either be accessible or have accessible alternatives. This appendix addresses:
- Word documents.
- PDF documents.
- PowerPoint® presentations.
- Excel files.
- Multimedia, audio, and live Web events.
AHRQ strongly recommends that AHRQ Web managers create accessible alternatives to Word files rather than accessible Word files. HTML is the gold standard for accessibility and works reliably regardless of user platform or software version. Web pages are generally easier to use than Word or PDF files, and when users download them from the Web, they must switch to a different set of commands.
However, starting with already accessible Word files does make it easier to develop accessible PDF documents as accessibility tags in Word files carry over to PDFs. HHS has developed a helpful guide on creating accessible files in various formats. See the section on Microsoft Word.
Key Points About Word
Many features that make it easier to create or use Word documents also support accessibility:
- The Styles feature in Word should always be used for formatting (heading subordination, bullet and number lists, table of contents levels). Styles delineate structure and organization for assistive technologies such as screen readers.
- Tables of contents, bookmarks, indexes, and hyperlinks all aid navigation.
- The Column feature should always be used when making a multicolumn document to ensure that assistive technologies will be able to properly read it. Never use the Tab key to separate columns.
- Alternate text for images allows them to be accessible to disabled persons.
- Tables created with the Word Table feature with row and column headings make tables more accessible. Precede tables with a description.
- Form fields should be labeled.
The Styles feature in Word makes your documents faster, easier to edit, and more consistent. Styles also greatly increase accessibility because they give a document a hierarchical structure that disabled users need in order to understand the document’s organization. Use styles to indicate:
- Heading subordination or importance (heading 1, 2, 3, etc.).
- Lists of information (bulleted and numbered lists).
- Table of contents levels.
If the Word document is converted into a PDF file, each assigned style generates a PDF accessibility tag. Styles also generate PDF bookmarks. Styles can be applied to large documents quickly. Select all elements to be formatted and click on the desired style.
Tables in Word can pose accessibility challenges, especially complex tables. Refer to the section on tables in the HHS Word Document 508 Checklist.
Forms in Word
Two steps increase a form’s accessibility:
- Use concise descriptions next to the objects inserted into the form.
- Add Help Text to each form item.
To add Help Text:
- Right click on the object that is in the form (i.e. text box, check box, calendar control, and so forth).
- Click Properties.
- Click Add Help Text.
- Enter text that describes the field’s attributes. For example, if it is a drop-down menu in the field provided, enter text that can help the user with navigation: “This is a drop-down menu to select the class you would like. Use the arrow keys to scroll through the list.”
- Click OK twice.
Images and Diagrams in Word
Screen and Braille readers will pass over images if they are not accessible. The key to making images accessible lies in using alternate text to identify image content. Alternate text cannot be seen but is read by assistive technologies. More information on alternate text appears later in this appendix.
Typically, diagrams require lengthy descriptions to ensure accessibility because both the appearance and meaning must be communicated. Handle this requirement by providing text in the caption or the figure’s description that explains what the image represents as a whole and then try to step the reader through what the image is trying to convey.
Adobe PDF documents are widely used because they can be produced quickly while preserving the look and feel of the source document, regardless of the application and the platform used to create them. PDF-only files are great for printing, but reading them online can be challenging.
Unless a PDF document on the Web has an accessible equivalent (such as HTML), it must be fully accessible.
Broad requirements for PDF accessibility include:
- The PDF document must contain actual text. It must have characters that can be picked up by screen readers as opposed to scanned pages that contain only images. Actual text is made from word processing or desktop published files.
- The PDF document must have accessibility tags (similar to HTML tags). Tagged PDF documents contain information on the structure of the contents of the file. Examples of accessibility tags include heading subordination and paragraphs. Tagging should also ensure logical reading order.
Word Files and Accessible PDF Documents
The best way to create accessible PDF documents is by first making the files accessible in the authoring application, such as Word. For details, refer to the section on Word documents above as well as HHS Guidance on PDF Accessibility.
PowerPoint Files and Accessible PDF Documents
There are two options for making a PowerPoint presentation accessible. The best option with PowePoint presentations is to convert them into Web pages. The other option is to create an accessible PowerPoint file.
Use the HHS PowerPoint Document 508 Checklist when developing accessible PowerPoint files. PowerPoint files must be tested comprehensively against the HHS checklist before AHRQ can accept them or post them on AHRQ Web sites.
Using Excel for interactive tools is not recommended except when Excel-based tools are intended to be used offline. Web-based versions of Excel tools are easier to make accessible and do not require proprietary software. Excel files can be made accessible, though developers often do not do so.
Multimedia, Audio, and Live Web Events
Captioning and Transcripts
If a multimedia product contains speech or other audio, that content must be made accessible through synchronized captioning. The captioning may be open (visible all the time) or closed (visible when a user turns it on).
Video. Multimedia presentations, including video, must have captions synchronized with the presentation. Presenters may embed video into a PowerPoint presentation or have the contractor videocast it. Either way, the video must be captioned. HHS guidance on captioning video may be helpful.
Audio tracks of multimedia must be delivered as text files with time stamps to allow proper synchronization. If created from live captioning, misspellings, missing words, and punctuation errors must be corrected before a final version is provided to AHRQ.
Audio. Transcripts must be provided on the Web next to links to audio-only files such as podcasts.
Refer to the section in this appendix on PowerPoint presentations and accessibility.
Live Broadcasts and Other Events
Webcasts, Webinars, and other live events must be captioned on the fly. Archived events must have synchronized captioning.
Temporary registration sites must be 508 compliant and resemble an AHRQ Web page.
Planning Tips for Hosts
Organizations that plan to host an audiocast or a Webcast should ask for presentations about 2 weeks before the event to ensure sufficient time is available to create a transcript. To facilitate the creation of slide scripts, hosts should ask each presenter to provide the context narrative in the Notes section of PowerPoint slides.
Planning Tips for Presenters
Presenters should use complete sentences in the Notes section of the PowerPoint slides so users can understand the main points. If presenters are using visuals to make a point, they should also explain that point verbally. Presenters should avoid using acronyms and abbreviations in slides or when speaking. Further, they should provide a list of medical terms, names, and other unusual terms to the host before the event to increase the accuracy of live captioners and transcribers.
Page originally created April 2009