Section 508 Policies
for PDF content

It's not obvious how Section 508 applies to PDF content. What is for sure is that perceived accessibility and usability depend on making the document work well rather than work poorly, no matter how formally "compliant" it is. Here, we offer a few issues worthy of consideration when developing your Section 508 implementation policy.

Backwards Compatibility

Section 508 is very vague when it comes to specific methods for handling document content. Alt. text is required, and basic rules are given for tables, but almost nothing else about content handling is included in the regulation. In order to achieve any meaningful degree of compliance and usability, each agency must develop their own standards for content handling beyond the simple prescriptions offered in the regulation itself. Backwards compatibility is one such key policy point.

Should PDFs be "backwards compatible" to the current version of JAWS?

Many government agencies use the JAWS screen-reader software as their benchmark for accessibility testing. However, because JAWS uses MSAA to access the content in PDF files, it cannot actually read the structure in PDFs that Section 508 requires for complex tables! Moreover, JAWS cannot "see" other structural tags in PDF such as Headings and Lists. These elements are not required by the letter of Section 508... but they ARE highly desirable for usability purposes - the spirit of 508.

Regardless of these limitations, PDF files may be made BOTH Section 508 compliant AND highly usable even for those using JAWS or other MSAA software. Some key work-arounds for complex tables ensures that other screen-readers that do not depend on MSAA are not shortchanged.

In tagging PDF files to ensure compliance with Section 508, it is necessary, therefore, to ask and answer the following two questions:

1. Must our files work well with JAWS, and if so, are we prepared to commit the resources necessary to correct the table tagging?

2. Can we accept "strict" 508 compliance, or must we tag to allow a higher degree of usability for advanced screen-readers?

Tagging Granularity

While alternate text is required for graphics and proper structure is required for tables, Section 508 simply ignores some of the most common document elements such as headings and bulleted or numbered lists. This means that those responsible for Section 508 compliance could theoretically ignore them too.

However, in keeping with our philosophy - that usability is the stuff of real-world compliance - we prefer to ask the harder questions that lie between mere formal compliance and user's access to information in the real world. With that in mind, here are the key Section 508 policy questions that need to be answered with respect to Tagging Granularity:

What stays in the structure tree? Section 508 demands a "text equivalent for every non-text element", which sounds good, but is nonetheless absurd. No-one in their right mind will create alt. text for every rule-line, every instance of a repeated logo, or even for every background or "cosmetic" image. To do so would be wildly counter-productive, forcing blind and other disabled users to sit through mountains of utterly mundane text that would, moreover, also cost a lot to develop. Rather, we reccomend interpreting 1194.22(a) as applying to "content" graphics and not to "cosmetic" or "layout" graphics.

Headings Section 508 does not mention headings, which is singularly unfortunate. Headings make the difference between organized content in which the user may skip to their item of interest, and a giant blob of text, without cues for section breaks. For non-MSAA screen-reader users, a lack of heading tags essentially means they have to read through the whole document to get at or return to a given section. MSAA screen-readers (such as JAWS) can't use heading tags at all, and so JAWS users must rely on bookmarks for navigation - which makes a bookmarking policy necessary as well.

Lists Section 508 does not mention lists either, usually displayed as "bulleted lists" or "numbered lists" on the page. These are very useful for organization or enumeration of points - especially when it comes to indicating hierarchical relationships between items. While a PDF may be technically Section 508 compliant, without list tags, to screen-reader users, such a PDF will read simply as paragraph text.

Want Accessibility Tips for PDF? » SIGN UP NOW

PDF Navigation

When we bring up the question of navigation features in deliverable PDF files, we often get this reaction: "Huh? Section 508 doesn't talk about navigation."

While the word doesn't appear, it only makes sense to read 1194.22(d) (the Section 508 regulation) as requiring navigation features to be present. The text reads: "Documents shall be organized so they are readable without requiring an associated style sheet." That language should be interpreted to mean that documents should be readily navigable without reference to inaccessible methods. In other words - provide navigation features that disabled users can use.

This isn't much of a stretch. How "accessible" would a 200 page document be if you had to read it one line at a time, with no other clues to the content?

As we've said before, usability is the stuff of real- world compliance. Purely formal compliance - which might give a pass to long documents without navigation features - simply isn't good enough. Here are some of the ways you can implement accessible navigation in PDF.

BOOKMARKS may be operated from the keyboard in Adobe Reader, and any screen- reader (even JAWS 5.0) is capable of reading and using PDF Bookmarks. ADVANTAGE: Bookmarks are useful to ALL users, not merely the disabled. Bookmarks are especially useful because unlike a Table of Contents, they are always available from any point in the document. DISADVANTAGE: There are no disadvantages to Bookmarks. Pretty much every PDF file longer than a few pages and intended for deployment online should include them.

LINKS may be added to text or graphics, and can deliver navigation within the PDF file or outside of it (web links). ADVANTAGES: Links may be embedded in the content for context-sensitive navigation. DISADVANTAGES: Links are less useful for Table of Contents navigation within a PDF, because you have to visit that page to use them, and some screen-readers (including the latest JAWS 7.0) cannot read the PDF-standard Table of Contents tags.

HEADINGS are a vital navigation tool for screen-reader users, as headings are available to screen-reader users as a navigation element. ADVANTAGES: Headings allow navigation direct to the desired content, instead of only navigation to a page. In combination with Bookmarks, multilevel Heading tags are highly effective for accessible navigation of very long and/or very complex documents. DISADVANTAGES: Requires either exceptionally consistent documents or human validation to ensure quality Headings are present.