Requirements for Accessible PDF part 3 – Authoring Best Practices

While this post is not meant as tutorial on creating accessible content with Microsoft Word or OpenOffice, keeping the following pointers in mind will help build accessibility right in the source documents – this list covers a few of the most important things to keep in mind. And as we saw in the previous posts, building accessibility in our source document is usually better than bolting it on top of the document once it has been converted to PDF.

Images

An accessible PDF document should contain text alternatives for informative images, charts, formulas, or other items that do not translate naturally into text for users of assistive technologies. In most cases, this should be handled before the PDF document even exists. The alternate text needs to convey the same meaning as the information contained in the image, or describe its purpose if the image is used to represent a function. A classic example of this would be a magnifying glass image used to submit a search in an interactive PDF document: the alt text for that image should naturally be “Search”. Providing a search button with a text equivalent that says “magnifying glass” would not make much sense in context. Surprisingly enough, we see errors like this all the time.

It is advisable to provide text equivalents to images and other graphical elements directly in the authoring tool prior to conversion rather then waiting to do so in Acrobat Pro. However, as it is the case with regular HTML web pages, images that are purely decorative or that do not convey relevant information to users should be tagged with a null attribute so assistive technologies can ignore them. Such images cannot be handled in the authoring tool and will need to be tagged as artifacts, directly in Acrobat Pro (much like integrating them as CSS background images).

Hyperlinks

Hyperlinks should be recognizable by assistive technologies and contain adequate information as to their destination and purpose. In other words, their purpose needs to be clear so users understand what to expect from them. Links should be created in the authoring tool prior to conversion, but they can also be bolted on a string of text in Acrobat Pro after conversion. Both will work equally well from as assistive technology perspective, but links added in the PDF document with not be visually indicated; this might create discoverability issues for sighted users. Therefore, adding links in the document source rather than waiting until after the conversion process is completed is always preferable.

Poor link text such as “click here” or “read more” is often an issue for users who can’t see the context of the page. Sometimes, in order to make sure the links’ purpose remains clear out of its context, it is necessary to compensate with complementary information beyond the visible link text. While this would normally be achieved using aria-label or off-screen CSS positioning in a regular HTML file, doing this in a PDF document requires hiding the supplemental information behind the links. This can only be achieved using the alt text property in Acrobat Pro – one of the rare cases where part of the mark up needs to be handled after the conversion process.

Language

Identifying the default language of a PDF document is another crucial aspect of PDF accessibility. Often overlooked, this can create insurmountable barriers for screen reader users who come from a different cultural background and/or who only have English as a second or third language. Defining the default language of a document allows assistive technologies and conventional user agents such as web browsers to render text more accurately.

The default document language should always be specified in the authoring tool before conversion to PDF; it will ensure both the source and PDF versions will be reliably set. In cases where it has not been addressed and the original source is no longer available, the default language can also be specified in Acrobat Pro after conversion – but this will often prove to be more time consuming.

Words, phrases, paragraphs, quotes, or passages within a document that are in a different language than the document’s default language should also be identified as such for screen readers and user agent technologies. While it’s also good practice to set this indication in the authoring tool, the information does not always reliably transfer from the authoring tool to PDF; hence, it is sometimes required to specify language changes in Acrobat Pro after document conversion.

Headings

Headings act as an outline or interactive table of content for a document in the sense that they enable assistive technology users to jump from one part of the content to another, as long as these headings are tagged properly. It is therefore crucial to make sure headings are semantically defined in the authoring tool using styles rather than simply changing their visual presentation with varying font sizes, font faces, and colors to make them look like headings.

Accessible documents use headings to convey the logical structure of their content. Using headings hierarchically and avoiding skip levels helps users of assistive technologies make sense of the content structure. Such users can then rely on a logically organized outline to jump directly to the content they want to read.

It is most efficient to identify headings in the authoring software rather than in Acrobat Pro, because styles applied in this way will then systematically be applied to all other text strings marked as headings, increasing general consistency in presentation and layout. Headings can always be added or fixed in Acrobat Pro after conversion but, again, will prove much more time consuming if only handled once the conversion process is completed.

Lists

Lists of items should be properly formatted in the authoring tool with list tags, so assistive technologies can express the relationship between list items and allow users to navigate from one list to another, or from list item to list item. Simply using line breaks to separate list items is not adequate, as structure (or lack thereof) does not programmatically translate to assistive technologies.

The easiest way to create lists is to format them properly using list markup and styles in the authoring tool before conversion (ordered or unordered). Acrobat Pro can be used to tag lists after conversion as well, but only regular unordered lists are available in PDF (it is impossible to semantically tag ordered lists in PDF). Once converted to PDF, ordered lists will simply be considered as unordered lists. To turn an unordered list back into an ordered list, authors will need to manually add a number in front of each list item, as part of the list item.

In Conclusion

These are just some of the most significant improvements that can be brought into a source document to help assistive technologies make the best of it. Other aspects could also be covered, but if even these few requirements were followed, users would experience incredible improvements. The next post will conclude this series by going over the basics of an efficient conversion process to PDF so accessibility features included in the authoring source are automatically and reliably transferred to PDF.

The blog posts in this series include the following. The last one will be published over the next few weeks:

• Requirements for an Accessible PDF: Part 1
• Requirements for an Accessible PDF: Part 2 – Common Accessibility Barriers
• Requirements for an Accessible PDF: Part 3 – Authoring Best Practices (this post)
• Requirements for an Accessible PDF: Part 4 – Proper Conversion Process

We hope you enjoyed this third part of our series on PDF Accessibility Requirements. Do you feel these best practices were the most important ones? Do you feel other best practices should have been included? Don’t hesitate to leave a comment so we can keep this conversation going.