It’s not obvious how Section 508 applies to PDF content, and that’s frustrating.
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.
Section 508 is very vague when it comes to specific methods for handling document content. Alt. text is required, and basic rules are provided 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, agencies are left to 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 older versions of JAWS?
Many government agencies use a specific version of JAWS or other screen-reader software as their benchmark for accessibility testing. However, older versions of JAWS cannot read the structure in PDFs required for complex tables, or read other structural tags 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 MSAA software. Some key work-arounds for complex tables ensures that other screen-readers that do not depend on MSAA are not shortchanged.
While Section 508 is specific about requiring alternate text for graphics and proper structure is required for tables, the regulations simply ignore common logical structure 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 real-world usability is the issue, not formal compliance, we believe it’s incumbent on those implementing Section 508 to “do it right”.
With that in mind, here are the key Section 508 policy questions that need to be answered with respect to tagging granularity in PDF.
What stays in the structure tree?
Section 508 demands a “text equivalent for every non-text element”, which sounds good, but makes no sense in practical terms. No-one in their right mind should 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, cost a lot to develop.
Rather, we recommend interpreting 1194.22(a) as applying to “content” graphics and not to “cosmetic” or “layout” graphics.
Section 508 does not mention headings, which is especially 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.
No heading tags forces users to wade through the whole document to get at or return to a given section, which is not acceptable.
Section 508 does not mention lists structure, usually seen as “unordered (bulleted)” or “ordered” (numbered) lists. Lists provide vital information allowing users to quickly access subjects of interest. They are especially critical when used in a document to organize or enumerate, or for 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.
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) 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?
Usability is the measure 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.
May be operated from the keyboard in Adobe Reader, and any screen reader 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.
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.
DISADVANTAGE: 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 cannot read the PDF-standard Table of Contents tags.
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.
DISADVANTAGE: Requires either exceptionally consistent documents or human validation to ensure quality headings are present