When asked what the most important PDF accessibility requirements are, most people will tell you that in order to be considered accessible, PDF documents need to:
- Be tagged using semantic markup so they become easily navigable by assistive technologies such as screen readers and refreshable braille displays
- Have their logical reading order specified independently of their visual appearance so their accessibility is enhanced for people who use screen readers or must navigate through documents using a keyboard, a keyboard emulation device, or speech recognition software
- Provide content that can be reflowed efficiently to optimize both text magnification on the screen and changes to text and background color, which makes it easier for some users to consume content
While these are all important, the most efficient way to produce accessible PDF documents is not to use remediation techniques after the PDF document has been created, but rather to prevent the need for remediation altogether. If you integrate accessibility early enough in the process, it is directly handled at the document source level, and a much more practical approach to PDF accessibility can be established.
This is especially true for draft documents that are meant to be edited and converted back to PDF format multiple times as they evolve. In many such cases, dealing with accessibility after the PDF conversion process will mean repeating the same efforts over and over again every time the document is reconverted to PDF format.
What this boils down to is that the most important PDF accessibility requirement is not tagging the PDF or working on its logical reading order or even making sure it reflows naturally; by building accessibility directly at the source and following an efficient conversion process, one can ensure that accessibility features are built right in the document rather than bolted on every time the document is converted to PDF format.
Working from an accessible source
It has often been argued that testing and remediating PDF files that come from an accessible source is generally much simpler than testing and remediating PDF documents coming from a source that isn’t accessible. The same goes for PDF documents that are improperly converted to PDF format, as these always provide more challenges than documents that are converted following an accessible “recipe”.
No matter where they originate from or how these documents are created, remediation is generally required for a document to be considered accessible. This is especially true when the document includes rich layout, data tables, complex images, or interactive form controls. When accessibility is integrated directly at the authoring source level, most of the efforts required to making a document usable to people with disabilities can be built in automatically, by applying simple authoring best practices like using styles or other basic built-in software features.
Let’s take documents created in Microsoft Word or OpenOffice, for example. Documents created in either of these authoring tools can have tremendous accessibility potential if the proper authoring process is followed. On the flip side, if these tools are used poorly, the resulting PDF document may very well end up a complete accessibility failure.
One of the reasons why it is so important to integrate accessibility prior to the conversion process is to have a chance to integrate as much structure and semantics as possible inside the document. As with accessible webpages, accessible PDF documents use tags to indicate the structural elements of the document’s content (chapters, headings, text, multi-column text, graphics, paragraphs, tables, footnotes, etc.) and how these elements relate to each other.
Tagging the different elements of content in a PDF document is what makes it navigable by assistive technologies and what provides the required semantics for computers and software programs to understand how the document is organized and what it is about. This is one of the most important aspects to consider for PDF accessibility.
This post is intended as the first post in a series of four that will walk you through the general concepts of creating source documents with accessibility in mind so they can easily be converted to accessible PDF format.
In the upcoming posts, we will discuss some of the most common accessibility barriers encountered by people with disabilities when using PDF documents and how implementing best practices in the authoring software can help bring those barriers down. We will then conclude by going over the basics of an efficient conversion process to PDF, so all the accessibility features included in the authoring source are automatically and reliably transferred to PDF.
The blog posts in this series include the following and will be published over the next few weeks:
- Requirements for an Accessible PDF part one (this post)
- Requirements for an Accessible PDF part two: Common Accessibility Barriers
- Requirements for an Accessible PDF part three: Authoring Best Practices
- Requirements for an Accessible PDF part four: Proper Conversion Process
We hope you enjoyed this first part of our series on PDF Accessibility Requirements. Don’t hesitate to leave a comment so we can keep this conversation going.
