 |
Page History
...
- Preparing FrameMaker Files For Accessibility
- Preparing Word Files For Accessibility
- Characteristics of Creating Accessible PDFs
- Checking Documents for Using Accessibility Tools
| Anchor | ||||
|---|---|---|---|---|
|
...
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.
| Anchor |
|---|
...
|
...
|
...
Creating Accessible PDFs
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.
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. |
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.
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.
...
...
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.
...
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.
|
| Anchor | ||||
|---|---|---|---|---|
|
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. |
| Anchor | ||||
|---|---|---|---|---|
|
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. | |
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. |
|
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.
Using the Adobe Acrobat Accessibility Tool
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
- Specify the document language as explained in Table 2.1.
- Run the Adobe Acrobat Accessibility Full Check, as follows.
- Select Advanced > Accessibility > Full Check. The Accessibility Full Check dialog box appears.
- Accept the default options, which include the Adobe PDF checking option.
- Click Start Checking. In the resulting report, follow the instructions Acrobat provides for finding and correcting accessibility errors.
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:
insert graphic here
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.
Using the Adobe Acrobat Accessibility Tool
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
- Specify the document language as explained in Table 2.1.
- Run the Adobe Acrobat Accessibility Full Check, as follows.
- Select Advanced > Accessibility > Full Check. The Accessibility Full Check dialog box appears.
- Accept the default options, which include the Adobe PDF checking option.
- Click Start Checking. In the resulting report, follow the instructions Acrobat provides for finding and correcting accessibility errors.
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:
insert graphic here
Creating Accessible PDFs
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.
- Select File > Document Properties.
- Click the Advanced tab.
- In the Language list, select English.
...
3
...
Use the document structure to prevent errors in the accessibility report.
- Select all pages in the document.
- Right-click and then select Page Properties.
- Select Use Document Structure.
...
4
...
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.
...
5
...
- 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.
...
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.
...
| Anchor | ||||
|---|---|---|---|---|
|
...
