Page History

Versions Compared

Key

This line was added.
This line was removed.
Formatting was changed.

Comment: Moved child pages up one level.

This page gathers documents that the Documentation Team has found or developed regarding Section 508 compliance. These documents will be posted in the appropriate place after consultation with other members of the Training and Development Team.

Creating Accessible Technical Documents at CBIIT

To make our documents compliant with Section 508 of the Rehabilitation Act, we must prepare our source files and then test our output files. The tools we currently use to create our source files, Adobe FrameMaker and Microsoft Word, both allow us to prepare for accessibility.

Our output files are currently in PDF and ePublisher WebHelp 5.0 formats. The tools we currently use to create those files, Adobe Acrobat 9 and WebWorks ePublisher Pro 9.2, contain tools of their own that check for how well files conform to the Section 508 accessibility standards. We can run those checks to see if we need to make any additional tweaks to our source files. We should avoid as much post-processing to output files as we can.

Most of our preparations for accessibility should be done in the source files. This document explains how to prepare a FrameMaker document for accessibility and links to procedures where you can accomplish the same goals in Word.

This section includes the following topics:

...

The following table summarizes how to prepare a FrameMaker document for accessibility.

Step	Steps for creating accessible documents in FrameMaker	For more information, see
1	Design with accessibility in mind. Only use our template styles, including character styles for common formatting such as bold and italic. Resist overriding template styles.	http://www.webaim.org/
2	Use our latest FrameMaker template that consolidates all paragraph styles into each file in the book. Important note! If you prefer to import styles from the new template rather than starting with an empty file, do not import styles into the TOC. Use the new TOC template file.	L:\Technical Writing\Templates\FrameMaker Templates\Current FM Templates
3	Add alternate text to images. FrameMaker 7.0 Place all graphics in anchored frames. Click an anchored frame one time to select it. Right-click the anchored frame and select Object Properties. Click the Object Attributes button. The Object Attributes dialog box appears. In the Alternate box, type an alternate text description for the content of the anchored frame Click Set and then Set again. A screen reader can now read the alternate text.
4	Use row and column headings and captions for all tables. Do not merge table rows or columns. Do not allow rows to break across pages.
5	Use meaningful link anchors rather than URLs when possible. Use the Go to URL hypertext marker for all URLs in FrameMaker.
6	In the PDF Setup dialog box, select Generate PDF Bookmarks, Generate Tagged PDF (click Default to tag all styles), and Create Named Destinations for All Paragraphs. Use the latest book file in the template to inherit appropriate bookmark and tag options.

See the following sections for more detail on preparing your FrameMaker files for accessibility.

...

Alternate (alt) text is typically used for describing an image so that screen readers can read it aloud.

FrameMaker limits alternate text to 255 characters.

To add an alternate text description to an image

Place all graphics in anchored frames.
Click an anchored frame one time to select it.
Right-click the anchored frame and select Object Properties.
Click the Object Attributes button. The Object Attributes dialog box appears.
In the Alternate box, type an alternate text description for the content of the anchored frame.
Actual text is for reading aloud the actual text, as in the case of a drop cap. For example, if the author is using a drop cap for the letter A in the word "Adobe" but still wants the screen readers to read the word as "Adobe" and not as "dobe," this can be done by filling in actual text.
Click Set and then Set again. A screen reader can now read the alternate text.

...

Section 508 differentiates between data tables and tables used purely for layout purposes, which it calls layout tables. A layout table would not have a table header. Most of our tables at CBIIT are data tables.

Section 508 specifies that we must do the following to create accessible data tables:

Designate row and column headers using the <th> tag.
Associate the data cells with appropriate headers.
Use proportional sizing, rather than absolute sizing.
Provide names or titles for data tables using the <caption> tag.
Provide summaries using the summary attribute.
Avoid spanned rows or columns.
Avoid tables with more than two levels of row and/or column headers.

See http://www.webaim.org/techniques/tables/data.php for more information about each of these characteristics of accessible data tables.

Since we are not working in raw HTML we do not have the opportunity to control all of these characteristics. Our current ePublisher stationery uses proportional sizing for all of our table styles.

FrameMaker supports a marker called TableSummary, which you can insert anywhere in a table, with the content of that marker being a summary of the table's content. However, it doesn't appear that these summaries are converted correctly into PDF or web-based help, since both the Acrobat and ePublisher accessibility checkers continue to note the absence of table summaries in documents I have tested.

The best approach is to use row and column headers where appropriate and include table captions for every table. We can write our table captions to accurately describe the content of the table. When that is not practical, we can introduce a table with a summary of it.

We do not currently produce output for table or figure captions in the help we create with ePublisher. We can either change that practice or make sure to summarize a table when we introduce it, even in help output.

...

Most tips regarding the accessibility of links concern proper coding of them so that all users can tab between them using a keyboard. Links also need to have a unique appearance so that they can always be identified as links. Our tools take care of both of these things.

Since we do not code our own links but rather use FrameMaker or ePublisher to create them, we should focus on the following.

Links should make sense out of context. When using human readable link anchors (as opposed to URLs), we should avoid non-informative link phrases such as "click here," "more," "click for details," as these are almost completely meaningless when read out of context.

URLs used as links are fine when they are short. The key is to be considerate of screen reader users who must listen to the longer, less intelligible URLs. Human readable link anchors are better than long URLs.

It is also a good general practice to introduce any link by describing the advantage that will be gained by following it.

...

Tagged PDF files contain a document's logical structure and metadata, and are the most reliable format for the following:

Use with a screen reader
Correct reflow of content into various size devices such as PDAs
Recognition of alternative text descriptions for graphics
PDF tags exist for accessibility purposes only and have no visible effect on the PDF file.

To set up a tagged PDF

Click File > Print or File > Print Book. Select Adobe PDF as your printer.
Select the Generate Acrobat Data option and then click the PDF Setup button. The PDF Setup dialog box appears.
Click the Tags tab. Select the Generate Tagged PDF option and then do the following:
Move paragraph tag names to the Include Paragraphs list to indicate paragraphs you want included in the PDF logical structure.
Select a paragraph tag name and then use the arrows located directly under that list to indicate the structure level of the selected paragraph.
Click Set.

...

Microsoft Word also contains the tools necessary to create accessible documents. Perhaps the most important contributing factor to an accessible Word document is the use of Word styles. Properly structured documents that do not use override styles but rather styles defined by a template are the easiest for a screen reader to follow.

The following table explains how you can prepare your Word documents for accessibility. Note that Word documents lose some of the accessibility options you introduce once they reach Acrobat. It is likely that you will need to post-process the file in Acrobat.

...

Step

...

Steps for creating accessible documents in Word

...

For more information, see

...

http://www.webaim.org/

...

Right-click the image, then select Format Picture. The Format Picture dialog box appears. Note: If the Format Picture menu option is not available, show the Picture toolbar and click the Format Picture button.
Select the Web tab and then add the appropriate alternative text.

...

Word 2007

Right-click the picture and select Size. The Size dialog box appears.
Select the Alt Text tab. The image file name is entered into the field by default.
Delete the image file name and enter appropriate alternate text.

...

Use meaningful link anchors rather than URLs when possible.

...

Configure PDFMaker to tag the document properly.
In Word 2003, select Adobe PDF > Change Conversion Settings.

On the Settings tab, select Bookmarks, Links, and Enable Accessibility and reflow.
On the Word tab, select Convert cross references, Convert footnote and endnote links, and Enable advanced tagging.
On the Bookmarks tab, select Convert Word Headings to Bookmarks and set the proper indent levels.

...

See Creating Accessible Word Documents for procedures for adding alternate text and creating a tagged PDF.

For detailed information about creating accessible Word files, see
http://www.webaim.org/techniques/word/. You can also find detailed information in the online help for Adobe Acrobat.

...

Although the HHS says that PDFs do not need to be 508 compliant if a compliant HTML version of the document exists, it is a good idea to get in the practice of taking as many steps as you can to improve your PDF document's accessibility.

The following table explains how to create an accessible PDF once your document is in Acrobat.

Note: Refer to the HHS checklist for accessible PDFs for helpful tips.

...

Step

...

Steps for creating accessible PDFs

...

In the document properties, enter NCI CBIIT as the Author. In the Keywords field, enter 508 Compliant as one of your keywords.

...

Select File > Document Properties.
Click the Advanced tab.
In the Language list, select English.

...

Select all pages in the document.
Right-click and then select Page Properties.
Select Use Document Structure.

...

Run an accessibility full check using the Adobe PDF option.

Select Advanced > Accessibility > Full Check. The Accessibility Full Check dialog box appears.
Keep the defaults, which includes the checking option of Adobe PDF.
Click Start Checking.

...

Confirm that each numbered box in the document is properly tagged.
Add alternate text as needed to figures as needed.
Remove nonessential content, such as ornamental page borders, from the logical structure tree as needed (files from Word tend to create a lot of nonessential tags that can be deleted in the PDF).
Note that when you remove the tags (such as by using the Delete Item Structure or Clear Page Structure commands), you cannot undo that action. Save your file often.

...

Once the steps above result in a PDF with no accessibility errors according to Adobe, set the scope of your tables. Adobe does not require you to set the scope but it is one more thing that you can do quickly to prepare your PDFs better for assistive technology.

Select Accessibility > TouchUp Reading Order.
Scroll to your first table and click the number in its upper-left corner.
On the TouchUp Reading Order panel, click Table Editor to select the table.
Select the cells that serve as column headers. You can also repeat these steps for cells that serve as row headers, if your table has that type of structure.
Right-click and select Table Cell Properties.
Keep the Type as Header Cell and from the Scope list, select Column. This tells a screen reader that it is to associate column headers with the cells in that column.
Click OK.

...

Adobe defines accessible PDFs as having the characteristics in the table below. The table also presents an interpretation of how each characteristic applies to the technical documentation team at CBIIT.

Characteristic of Accessible PDFs	How This Applies To CBIIT
Searchable text	Do not scan documents to create a PDF. This converts all text to an image that a screen reader cannot scan.
Fonts that allow characters to be extracted to text	Make sure we only use fonts that can be extracted to Unicode characters. Use Adobe Acrobat 9 rather than 7, which does not support Unicode.
Interactive form fields	We do not use form fields.
Other interactive features: buttons, hyperlinks, and navigational aids	We already use links, bookmarks, headings, and a TOC, so we are covered here.
Document language	We cannot specify the document language from FrameMaker or Word so we must do so in the final PDF.
Security that will not interfere with assistive technology	We should not set any security restrictions on our PDF files. We do not currently do so. The text of an accessible PDF must be available to a screen reader.
Document structure tags and proper read order	When we create a tagged PDF, the structure of our source document should create the appropriate document structure tags. However, while this may create the proper reading order, it does not create the proper order for tabbing through the items on a page. Before running the Acrobat Accessibility Checker, instruct Acrobat to use the document structure for the tab order. Despite our efforts, the Acrobat Accessibility Checker may still report problems with structure; we will have to correct those problems manually or even ignore them, if we cannot determine their cause.
Alternative text descriptions	We must do this in our source files.

...

Both ePublisher and Acrobat contain accessibility tools that help spot glaring accessibility errors and remind us of accessibility issues that require manual checks. Using accessibility tools like these is really just one of the first steps toward Web accessibility.

Other accessibility tools are available for free on the web, though this document does not review them. See http://www.webaim.org/articles/freetools/compare.php for a full review of free, online accessibility tools.

The following table suggests ways you can test your ePublisher, Flare, and PDF output for accessibility.

...

Ways to Test Your Output

...

For more information, see

...

Refer to the HHS accessibility checklists.

...

HHS Checklists

The following pages explain how to prepare documents for accessibility.

A few key actions can make content significantly more accessible.

Include Page

	shared info - requirements
	shared info - requirements

Refer also to Accessibility and 508 Compliance (overview).

...

Download the WAVE Firefox toolbar and view the help in Text-only view.

...

Download an evaluation copy of JAWS and read the document out loud.

...

Freedom Scientific

...

Use the Adobe Read Out Loud feature to simulate what it would be like for other assistive technology (such as JAWS) to read your PDFs out loud.

...

Turn off your monitor when you use either JAWS or Adobe Read Out Loud (this takes some practice with each tool) to simulate what it is like not to see what you are doing.

...

Tab through the output to make sure that the reading order is logical.

...

Credit for the content of the following two sections goes to WebAIM.

The Problem with Automated Tools

In the same ways in which we don't always accept the results of a spell and grammar check (or they don't catch the real errors we have because words are spelled correctly), web accessibility requires more than just accessibility tools; it requires human judgment. All accessibility tools vary slightly in their interpretation of WCAG 1.0 and Section 508, and depending on the interpretation, accessibility tools can give users some automated results that require human judgment.

Here is an example. WCAG 1.0 Priority 3 checkpoint 5.5 states, "Provide summaries for tables." Interpreted strictly, this checkpoint could mean, every table in a web page should have a summary attribute. In practice, putting summary attributes into both data tables (which should have summaries) and layout tables (which do not need them) just gives individuals using screen readers more distracting information to read through.

Accessibility Tools Need Human Judgment

It is important to remember that accessibility tools can only partially check accessibility through automation. Of the sixteen standards in Section 508, only seven standards can be partially evaluated automatically. Similarly, of the combined 65 checkpoints in WCAG 1.0 Priority 1 through Priority 3, only nineteen can be partially evaluated automatically. The real key is to learn and understand the web accessibility standards rather than relying on a tool to determine if a page is accessible or not.

...

You can use the WebWorks ePublisher Accessibility report to identify accessibility warnings or errors in your online help files.
To view the accessibility report, do the following.

Generate your ePublisher project.
In the Document Manager panel in the upper left, click the project name such as caBIO Portlet Online Help. Items appear in the Output Explorer below.
In the Reports folder, which should already be open, double-click Accessibility Report.The content of the report appears to the right.

The accessibility errors and warnings that appear in this report are determined by the settings specified in the Format Settings dialog box (Format > Format Settings). The format settings in our current stationery are as follows, though a future version of our stationery may not generate warnings for images without long descriptions and tables without summaries, since those features do not seem to carry over from FrameMaker, and have alternatives.

If you are missing any alternate text for your images, add it to your source files, generate your ePublisher project, and view the accessibility report to confirm that you have made your project as accessible as possible.