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.
The following tables list steps technical writers at CBIIT must take to create Section 508-compliant documents. These steps may overlap with but do not replace the HHS checklists for achieving Section 508 compliance.
The following table explains 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. |
|
2 |
Use our latest FrameMaker template that consolidates all paragraph styles into each file in the book. |
L:\Technical Writing\Templates\FrameMaker Templates\Current FM Templates |
3 |
Add alternate text to images.
|
|
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. |
|
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.
Note: Refer to the Word to PDF Reference Card|http://blogs.adobe.com/accessibility/assets/WordToPDFReferenceCard_v1.pdf|Word to PDF Reference Card] and the HHS checklist for accessible Word files||http://www.hhs.gov/web/policies/wordCheckList-HHS.pdf|HHS checklist for accessible Word files] for helpful tips.
Step |
Steps for creating accessible documents in Word |
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. |
||
2 |
Add alternate text to images.
|
|
|
4 |
Use meaningful link anchors rather than URLs when possible. |
|
|
5 |
Configure PDFMaker to tag the document properly. |
|
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.
Table 1.3 explains how to create an accessible PDF once your document is in Acrobat.Table 1.3 explains how to create an accessible PDF once your source file is in Acrobat.
Note: Refer to the HHS checklist for accessible PDFs for helpful tips.
Step |
Steps for creating accessible PDFs |
---|---|
1 |
In the document properties, enter NCI CBIIT as the Author. In the Keywords field, enter 508 Compliant as one of your keywords. |
2 |
Specify document language.
|
3 |
Use the document structure to prevent errors in the accessibility report.
|
4 |
Run an accessibility full check using the Adobe PDF option.
|
5 |
Fix any problems reported by the accessibility checker. Documents from Word tend to have more problems than documents from FrameMaker. Documents from Word may need post-processing in Acrobat. Use the accessibility checker report as a troubleshooting guide to narrow down problem areas.
|
6 |
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.
|
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. |
|
In ePublisher, run the accessibility report. Ignore errors about missing long descriptions and table summaries. If you use alternate text for graphics and include either a text introduction or caption for tables, you're covered on those. |
|
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. |
|
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. |
|
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:
See the following sections to learn how to prepare 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 descriptions to an image
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:
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.
Tagged PDF files contain a document's logical structure and metadata, and are the most reliable format for the following:
To set up a tagged PDF
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.
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.
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. To specify the document language, do the following.
|
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 creates the appropriate document structure tags. However, it appears that not all elements in our source files result in correctly structured tags. The Acrobat Accessibility Checker identifies these tags and it will be a learning process for all of us how many tags we need to fix. |
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.
Credit for the content of the following two sections goes to WebAIM.
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.
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.
Creating a tagged PDF with alt-text specified for each graphic from FrameMaker or Word is the first step in creating a truly accessible PDF file. We must also post process the PDF file to complete that process.
To prepare a PDF for an accessibility check
Some of these accessibility errors require post-processing of our PDFs. Files originating in Word tend to have more accessibility errors that result in post-processing than do those files originating in FrameMaker.
Our goal is to have no accessibility errors and to see the following message box:
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.
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.
Adobe(R) Accessibility Blog http://blogs.adobe.com/accessibility/2008/03/reference_card_for_accessible.html
WordToPDFReferenceCard_v1.pdf (presented by the blog page listed above) http://blogs.adobe.com/accessibility/assets/WordToPDFReferenceCard_v1.pdf
caBIG_PPT_508_Quick_Guide_FINAL_July_2009.ppt https://wiki.nci.nih.gov/download/attachments/7474647/caBIG_PPT_508_Quick_Guide_FINAL_July_2009.ppt
The quick guide is used with the PowerPoint templates posted on this page: https://wiki.nci.nih.gov/pages/viewpageattachments.action?pageId=10852174
caBIG_508_QuickGuide_Word_April_2009_Final.ppt https://wiki.nci.nih.gov/download/attachments/7474647/caBIG_508_QuickGuide_Word_April_2009_Final.ppt