Checking for Compliant Files in Acrobat Using the Accessibility Checker Options (Section 508, WCAG, and Adobe PDF)

11 07 2009

In Adobe Acrobat, when you run an accessibility check you are given the option to select the criteria you would like to check your file against. I would like to explain what some of the various options can do, as well as when you should use each while working to create accessible PDF files.

Adobe PDF
Adobe PDF is the most lenient of the bunch, but it can be a nice jumping off point when you are working your initial drafts. For example, I will often run an Adobe PDF check to verify that it is ready to go to the next steps in compliance.  As a rule, if your PDF fails to pass an Adobe PDF check, it will not pass Section 508 or WCAG. So when you run your check and your tab order is off or your language is not specified, go back and check your work.

Section 508

In the U.S., when we create accessible files we are working to meet a set of criteria established by the Federal government as part of the Americans with Disabilities Act. The Section 508 web site is chock full of great information about the requirements, but the accessibility checker in Acrobat can leave quite a bit to be desired. Most often, the checker will find no problems in the document but require quite a bit of manual verification. If you are not familiar with the requirements of 508, you can easily mistake a non-compliant file for a compliant one.

WCAG 1.0 & 2.0
WCAG, or Web Content Accessibility Guidelines, is series of Web accessibility guidelines published by the W3C’s Web Accessibility Initiative. When it comes to running an Adobe accessibility check, the WCAG reports that are generated have always been more detailed than the 508 reports. For example, a 508 check will not reveal problems associated with not have a language defined for the file while the WCAG will prompt you to change it. I have found WCAG to be far more useful when working with tables, which is interesting when considering that Section 508 also requires clearly defined headers and read order for tables. Also, although 1.0 appears in the accessibility checker as current, with the release of WCAG 2.0 in December 2008, you should not rely on passing 1.0 alone. The new WCAG standard is 2.0.

Putting it all together
As a general rule, you should not rely on the accessibility checker in Acrobat to verify that your document is accessible or complying with Federal regulations. A better course of action is to be proactive about familiarizing yourself with the different standards and using the checker as a tool rather than a certification of compliance. It is important to remember that just because the checker doesn’t detect any problems, the content still may not be fully accessible to someone using a screen reader. Checking your document on a screen reader (such as JAWS) will always be the best way to verify that your document is fully accessible. If you do not have access to a screen reader, you can use the “Read Out Loud” feature in Acrobat to verify that the document is being read in the proper order. You can also using the “Touch Up Reading Order” tools to check your document hierarchy, tags, and order. The reading order tool is especially useful when checking for artifacts, which will not be played when read out loud or detected when running the compliance checker. Can you imagine what would happen if you accidentally flagged an important graph as an artifact? (After a long day, it can happen!)

8 Steps to Checking Accessibility in Acrobat

When I am checking a file for 508 compliance, I practice the following steps:

  1. I make sure to export a tagged, bookmarked document from the source file.
  2. In Acrobat, I open the Document Properties and verify that the PDF is tagged. While in the dialog box, I make sure that the  filename is correct (not too long, no spaces or special characters), add the title and keywords, and specify the document’s language.
  3. Use the “Touch Up Reading Order” tool and Tags pane to verify that things are tagged correctly and in their proper order. Use the Table Inspector to verify that tables are structured properly, and add any table descriptions.
  4. Using my own checklist based on the different requirements, I review the file for errors (especially useful for things like color requirements, etc).
  5. Run the accessibility checker for Adobe PDF and correct any errors until it passes.
  6. Run the accessibility checker for 508 and correct any errors until it passes.
  7. Run the accessibility checker for WCAG (1.0 and 2.0), correcting errors until it passes.
  8. Finally, if the document has been especially tricky, play the document using the “Read Out Loud” feature.

Actions

Information

Leave a comment