AHRQ Publishing and Communications Guidelines
Appendix 2-C. Creating Accessible Files and Technologies
Complying With Section 508
In brief, Section 508 of the Rehabilitation Act of 1973 requires that Federal agencies make all electronic and information technology accessible to individuals with disabilities, unless an undue burden would be imposed on the Agency. Qualifying for an undue burden is difficult. If an undue burden were to be determined, AHRQ would receive an exception and post a disclaimer on the Web site.
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, AHRQ must comply with Section 508 because it is a legal requirement.
HHS employees must ensure that all electronic information and technology comply with the 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 by the U.S. Access Board:
- HHS 508 Web standards and guidance:
- AHRQ 508 Coordinator (Web):
Biff LeVee, 301-427-1897, firstname.lastname@example.org.
Keep the following accessibility requirements in mind:
Content must be readable by screen readers (which read text aloud) or Braille readers. For people with low vision or color blindness, contrast must be sufficient. Ensure that any information conveyed with color is conveyed equally well when color is not available. Asterisks or some 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 different 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 because people who are deaf need synchronized captions if the video does not make sense when the sound is turned off.
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 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 provided does not depend on color for sense without alternate text and 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, as well as 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 requiring timed responses.
- Ensuring that functions such as forms and drop-down lists will be executable 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. See the Section 508 Web standards at http://www.access-board.gov/sec508/guide/1194.22.htm#(a).
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 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.
- Not use 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. Two methods are recommended:
- Provide the full description in the document itself. For example, alternate text can be under the image 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 analytic framework, "Select for Text Description" goes to the alternate text: http://www.uspreventiveservicestaskforce.org/uspstf07/chlipid/chlrevfig2txt.htm.
Some images are too complex for all of the information to be meaningful 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—either have to 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 dependably 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, making Word files accessible does make it easier to develop accessible PDF documents—accessibility tags in Word files carry over to PDFs. For a helpful guide by HHS about making Word files accessible, go to the section on Microsoft Word at http://www.hhs.gov/web/508/accessiblefiles.
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 so assistive technologies will be able to properly read the document. Never use the Tab key to separate columns.
- Alternate text for images permits images 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 word processing faster, easier to edit, and more consistent. Styles also greatly increase accessibility because they give a document a hierarchical structure that disabled users need to understand document 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 can generate 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. Use the section on tables in the HHS 508 checklist: http://www.hhs.gov/web/508/accessiblefiles/checklistword.html.
Forms in Word
Two steps increase a form's accessibility:
- Use concise descriptions next to the objects that have been 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, etc).
- 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 unless they are 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. The way to handle this is to provide a 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 (Portable Document Format) 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 PDF documents on the Web have accessible equivalents (such as HTML), the PDFs must be fully accessible.
Broad requirements for PDF accessibility include:
- The PDF document must contain actual text. The PDF document 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 logical structure about the contents of the file. Examples of accessibility tags include heading subordination and paragraphs. Tagging also should 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, go to the section on Word documents above and HHS guidance at http://www.hhs.gov/web/508/accessiblefiles/pdfaccessibility.
Word accessibility tags are converted to PDF accessibility tags by Adobe® Acrobat Professional 8 or later. Well-tagged Word documents are required to make accessible PDF documents. Word's structural and accessibility features (styles for paragraphs, headings, and lists; alternate text and captions for images; hyperlinks; lists; tables of contents; and accessible forms) will produce special tags when the Word file is converted into PDF. In addition, the resulting PDF document will be automatically bookmarked because of styled headings, aiding navigation.
The resulting PDF documents will probably require additional work to be fully accessible. To ensure accessibility of newly created PDF files, refer to the section below on testing PDFs for accessibility. You may also use the HHS checklist for PDF accessibility at http://www.hhs.gov/web/508/accessiblefiles/checklistpdf.html.
Tags define the document's structure and reading order, describe graphics, and improve navigation. PDF tags are embedded in the document and are not visually seen. Tags can only be edited with the Tags Palette in the full version of Acrobat® (View/Navigation Panels/Tags).
Examples of tagging problems include heads not tagged, tags incorrectly subordinated, images without alternate text descriptions, or incorrect tags. Artifacts such as page numbers from the original document should be tagged as artifacts (Tags Palette/Find Artifacts). When tagged, artifacts are invisible to screen readers.
Improperly marked content can create reflow and accessibility problems. If tagged content creates problems for reflow or accessibility, these can be manually corrected by marking content and assigning element types.
Editing PDF tags—caution. Operations performed in the Tags tab cannot be undone with the Undo command. Save a backup copy of a document before you begin work on it in the Tags tab.
Tables require special treatment so that visually disabled users can understand row and column information for each cell. Problems can be minimized when each column has its own head. Table formats in the authoring application should be used, such as table column heading, row heading, and table cell data.
Use the HHS 508 Guidelines for PDF tables at: http://www.hhs.gov/web/508/accessiblefiles/checklistword.html.
Tables pose a special challenge for screen readers because they present textual or numerical data to be easily referenced visually. Content within table cells can be complex and might contain lists, paragraphs, form fields, or another table. The TouchUp Reading Order Table Editor automatically analyzes the selected table into cells and applies the appropriate tags.
The table must be tagged as a table before you can use the Table Editor command. For best results, use the application that you created the document with to add tags before you create the PDF. If a PDF isn't tagged, you can add tags by using the Add Tags To Document command. Most tables are properly recognized using this command; however, the command may not recognize a table that lacks clear borders, headings, columns, and rows. Use the TouchUp Reading Order tool to determine if the table has been properly recognized and to correct recognition problems. To add specialized formatting to tables and table cells, use the Tags tab.
You can use the Table Editor to automatically analyze a table into its components and apply the appropriate tags, but you may still need to check and correct some of these tags manually. By viewing table tags, you can determine whether columns, rows, and cells have been correctly identified. Tables that lack well-defined borders and rules are often tagged incorrectly or contain adjacent page elements. You can correct poorly tagged tables by selecting and redefining them, and you can split combined cells by creating a tag for each cell. To do this:
- Select the TouchUp Reading Order tool, and then click Show Tables and Figures.
- If the table isn't clearly labeled in the document pane, drag to select the entire table, and then click Table in the dialog box.
- Click Show Table Cells to make sure that all cells in the table are defined as individual elements. If cells don't appear as separate elements, do one of the following:
If one or more cells are merged, use the TouchUp Reading Order tool to select the area within a single cell, and then click Cell in the dialog box. Repeat for each merged cell.
If cells aren't highlighted, the table might not use standard table formatting. Re-create the table in the authoring application.
Table headings. Table headers are not always properly defined after the conversion from Word to PDF. Use the TouchUp Reading Order Table Editor to change table data cells that should be table headings to table headers or change the table data tags directly into table header tags within the tags panel.
For more detail, go to the Adobe® Acrobat® 9 Pro Accessibility Guide: Best Practices for Accessibility: http://www.adobe.com/accessibility/products/acrobat/pdf/A9-access-best-practices.pdf (Plugin Software Help).
PDF Alternate Text for Figures and Images
Figures and images are ignored by screen readers unless alternate (descriptive) text is used. All information or data in figures and images must be made available. (Imagine you can't see the image: What needs to be described to convey all information in the image?) To identify the document elements that still need tags, open the Tags Palette, right click, and click Turn on Associated Content Highlighting.
If you want screen readers to describe graphical elements that illustrate important concepts in a document, you must provide the description using alternate text. Figures aren't recognized or read by a screen reader unless you add alternate text to the tag properties. If you apply alternate text to text elements, only the description, not the actual text, is read.
To create alternate text descriptions:
- Select the TouchUp Reading Order tool.
- Select Show Tables and Figures in the dialog box. Figures that are missing Alternate Text will have a flag indicating "Figure—No alternate text exists".
- Right click the figure and choose Edit Alternate Text from the pop-up menu.
- In the Edit Alternate Text dialog box, type a new (or edit an existing) description for the figure, and then click OK.
Accessible Hyperlinks in PDFs
Adding alternate text descriptions to links makes the links' purpose or use clearer for readers using screen-reading software. To make links in the text accessible:
- Use the Select Text tool to select the link.
- Right click and select Properties.
- Select Tag tab; enter description in Alternate Text box.
- Select Close.
PDF Document Language
The PDF's global language (such as English) must be established to improve readability and accessibility. This must always be done with PDFs converted from Word files. To set the language:
- Select File/Properties.
- Select Advanced in the Document Properties dialog box and then choose a language in the Language menu.
Forms require special techniques so they are accessible. Use the HHS 508 checklist at: http://www.hhs.gov/web/policies/webstandards/508pdfforms.html.
No software can fully test a PDF file's accessibility. Acrobat's Full Check feature can help find problems but cannot verify full compliance with Section 508. For example, the Full Check feature ignores tables and cannot judge if an alternate description for an image adequately communicates information in it. Screen readers, such as JAWS®, should also be used to test PDF files for 508 compliance.
To Use Acrobat's Accessibility Checker:
- Click Advanced/Accessibility/Full Check.
- Select every option for checking, and then select Start Checking.
- A summary dialog box will appear, along with an Accessibility Report that will include hints for repair. Most problems can be fixed using the Forms Tool or the Tags Palette.
- Correct the issues and save the file as a copy because Acrobat has no Undo feature.
- Test again with Full Check.
- Check the file for accessibility using a screen reader.
PDF tab order and structure order. In some cases, even though the tags have been inherited from the source file, the Accessibility Checker will indicate that tab order is inconsistent with structure order. To fix this issue:
- Open the Pages icon or select View/Navigation Panels/Pages.
- Click on any page icon and type Ctrl + A to select all the pages.
- From the Options button on the pages panel, select Page Properties.
- In the Tab Order Panel, check Use Document Structure.
Other issues. Issues that may not be identified using accessibility checks include:
- Is the document free of scanned images of text? This type of image will be identified as needing alternate text, but it should be real text and not an image because a screen reader cannot read an image.
- Are table headers and scope tags properly tagged? An accessibility check may not catch incorrectly tagged fields in tables, especially if there are multiple headings and subheadings in a complex table. The Table Inspector Tool can help identify whether proper tags are used.
Tools for testing PDF accessibility. No single tool can be used to ensure compliance, but the following tools and tests can be used in combination:
- HHS PDF File 508 Checklist (http://www.hhs.gov/web/508/accessiblefiles/checklistpdf.html).
- Adobe Acrobat's Accessibility Full Check.
- Adobe Acrobat's Section 508 Check (for tables).
- Manual/visual check in Acrobat to verify the reading order.
- JAWS screen reader.
Resources on PDF Accessibility
Detailed information is available at:
- Adobe® Acrobat® 9 Accessibility Training Resources
- HHS Guidance on PDF Accessibility
There are two options for making a PowerPoint presentation accessible:
- 1. Create an accessible Web alternative in addition to the presentation such as: http://archive.ahrq.gov/news/events/conference/2012/track_a/06_brach_et-al/brach.html.
- 2. Make the PowerPoint file accessible.
Option 1. Accessible Web Alternative
Creating an accessible Web alternative to the presentation is strongly recommended. Web pages are far more user-friendly than PowerPoint files (because the user interface is familiar and slides generally do not have navigation links), and accessible HTML files are preferred. The techniques for making Web pages accessible are well established, and tools exist for testing accessibility, although the results of such testing must be interpreted.
HTML can be made accessible regardless of the platform (Windows or Mac) and version, and it does not require proprietary software. For PowerPoint files to be accessible, the user must have the full software program. The free PowerPoint Viewer is not accessible. A blind user relying on the free viewer and a screen reader cannot access the information.
Option 2. Accessible PowerPoint File
For developing accessible PowerPoint files, use the HHS Guidelines at:
Before making a PowerPoint file accessible, these factors must be considered:
- Testing PowerPoint files for accessibility is labor intensive: each slide must be manually reviewed against HHS guidelines.
- There are no tools available for testing the accessibility of PowerPoint files.
- It can be difficult to make PowerPoint files accessible after the presentation is created. For example, if a text box is used to enter text, that content is usually not accessible to screen readers. To make the text accessible, it will have to be re-entered with the Slide Layout feature.
PowerPoint files purported to comply with Section 508 must be tested comprehensively against the HHS guidelines 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 few developers who create Excel files do so.
Either Excel files must comply with Section 508 or the files must be granted accommodation waivers by HHS, which is highly unusual. The HHS 508 Standard for Excel files is at http://webstandards.hhs.gov/standards/3. The HHS checklist for Excel accessibility is at http://www.hhs.gov/web/508/accessiblefiles/checklistexcel.html.
If the purpose of the Excel worksheet is to present a data set, the Excel file should be presented on the Web as a Comma Separated Value (CSV) file and not as an xls file. The link must clearly state that the CSV is a raw data set. A separate data definition document must accompany all CSV files. An Excel data set that would be presented as a CSV has the following characteristics:
- A single row of headings in the first row.
- The data set contains no formulas.
Multimedia, Audio, and Live Web Events
Follow the HHS Web standard for Accessibility and Video/Multimedia Content at: http://www.hhs.gov/web/policies/webstandards/video508.html.
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: http://www.hhs.gov/web/508/accessiblefiles/videocaptionguidance.html.
Audio tracks of multimedia need to 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 their 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.
Even after all software and hardware requirements are met, the very nature of Flash can make full accessibility difficult. Because Flash content is dynamic and can change in response to user input, a wide range of issues must be addressed.
AHRQ follows the HHS Web standard on acceptable uses of Flash at: http://www.hhs.gov/web/policies/webstandards/useflash.html.
Note: All proposed use of Flash must be approved by HHS at the concept stage. Contact Biff LeVee (email@example.com) at AHRQ for assistance.
"Web page authors have a responsibility to provide script information in a fashion that can be read by assistive technology. When authors do not put functional text with a script, a screen reader will often read the content of the script itself in a meaningless jumble of numbers and letters. Although this jumble is text, it cannot be interpreted or used."
Page originally created April 2009