Quick Guide: Accessible PDF Documents

Posted on: Last updated on: Written by:
Whether writing a new document or revisiting an existing one, there are a few techniques you can adopt to ensure your documents are accessible for a variety of users.

How do you ensure your PDF documents are accessible?

To date, most accessibility laws around the world are largely based, or directly refer to W3C WAI’s web content accessibility guidelines (WCAG). The European Union has issued harmonized standards (EN 301 549) along with directives requiring developers to make mobile apps and services accessible for all by 2021 for the public sector and 2025 for the private sector. The EU standard is based on WCAG 2.1 and requires a minimum compliance level equivalent to WCAG 2.1 AA (while recommending AAA compliance for around 28 criteria). Furthermore, EN 301 549 offers accessibility success criteria for web pages (rendered on any device), along with criteria for non-web documents (e.g. PDF) and non-web software (e.g. mobile apps, platform software, smartwatch apps, ATMs, e-readers, home appliances, car dashboards, airplane seatbacks and so forth) – all largely based on the latest W3C WAI guidelines (WCAG). However, this standard goes a step further and includes aspects such as the use of biometrics and operable parts (e.g. physical toggle switches) in applications.

Chapter 10 of EN 301 549 is specifically authored for non-web documents, and a good introductory video can be viewed by clicking on this link. WCAG 2.1 incorporates recommendations (and success criteria) that directly address accessible PDF authoring. Of course, WCAG criteria for web-related technology become redundant (e.g. such as “consistent navigation”, “bypass blocks” and so forth). You can filter these out using WCAG’s Quick Reference guide.

But what do we mean by “accessible PDFs”? An accessible PDF is a document that can be accessed, understood and interacted with efficiently by the vast majority of people, with or without assistive technology. The term “understood” refers to both the language used but also the underlying format and metadata embedded with the document.

Let’s get started!

What is a PDF? The “Portable Document Format” is the de-facto document format standard used all over the world. Its main advantage is that it is portable, as the name implies, and can be viewed on a wide array of devices and platforms, irrespective of where the document was created. The file format was developed in the early 1990’s, by Adobe through The Camelot Project.

It is also important to point out that apart from presenting images and text in a portable format, PDFs can also be interactive, for instance, by allowing users to fill in data directly. Therefore, as per WCAG recommendations, a PDF document needs to be Perceivable, Operable, Understandable and Robust. In fact, WCAG provides techniques for various success criteria specifically aimed at PDFs to comply with these WCAG guidelines. You can easily see these techniques in the WCAG Quick Reference, filtering techniques applicable to PDF documents.

Consider the following steps for your next project:

  1. Go for simplicity and structure in your writing
  2. Ensure your PDFs are tagged – ideally at source
  3. Test your documents
  4. Involve target users and get audited

So, let’s dig slightly deeper.

Step 1: Go for simplicity and structure in your writing

Simplicity and clarity should be your guiding principles. Here are some pointers:

  • Don’t assume your audience understands what you have in mind.
  • Use plain, simple, non-technical language.
  • Ensure that you use the proper semantics that reflect the meaning and structure of your content. For instance:
    • Ensure that your document has proper heading structures. This could also help readers understand the purpose of the document.
    • The use of lists is highly recommended. Use ordered or unordered lists, depending on what you’re trying to explain. Also, lists ensure that grouped content is presented as such.
    • Organise your text in clear and concise paragraphs.
    • Use figure captions to describe images, rather than letting the reader make sense of it through its surrounding text (the context).

Step 2: Ensure your PDFs are tagged – ideally at source

Rather than retrofitting accessibility into a document, you should think about accessibility while authoring the document. Most authoring tools, such as Microsoft Word, offer sufficient facilities to help you achieve this, which would in turn help producing more accessible PDF documents. Whenever you export a document to PDF, the authoring tool will also embed tags that explain the structure of the document. This is very important, since some people may interact with PDFs using assistive technologies, such as screen readers, which in turn rely on this information. Consider the following points when authoring a document:

  • Use accessible fonts. Sans-serif fonts such as Verdana, Arial, Calibri or Tahoma are highly recommended. Other serif fonts can be used, such as Georgia or Palatino.
  • Ensure your text is readable. This means that you should use font sizes of at least 12pt and ensure that there is enough contrast with the text background. This contrast should be at least 4.5:1 for regular text, and 3:1 for larger text (at least 18pt). If you have image backgrounds, ensure that there is sufficient contrast for each superimposed word (and letter).
  • If you want to write a list, use the in-built lists. Microsoft Word allows you to create numbered lists, bulleted lists as well as multilevel lists. This doesn’t just format text as lists, but also encodes important information within the text that is also communicated to assistive technologies.
  • Use a logical heading structure. Don’t just format the text to look like a heading. Word processors have in-built headings that can be applied to your text (e.g. heading 1, heading 2, heading 3). Also, make sure that your heading order is logical. This means that you should avoid skipping heading levels or starting with a sub-heading instead of a level 1 heading. Once again, this will encode specific information into the document that would also be communicated to assistive technology users.
  • Apart from heading structures and lists, word processors offer built-in styles for a number of things, such as the document title, subtitle, paragraphs and quotations. Using these styles will encode important information in your document that will be translated into appropriate tags when exporting to PDF. Also, these built-in styles typically come with sufficient spacing between words, sentences and paragraphs – making reading easier for everyone.
  • If you have images or graphics, ensure these contain meaningful alternative text. This text will be communicated to assistive technology users.
  • If you need to include tabular data, then ensure you use accessible tables. Accessible tables allow users to traverse the table using a keyboard, but more importantly, the table should have a designated header role. This will ensure that assistive technologies communicate the content of the table more clearly. This also applies to nested tables. Finally, tables should also have alternative text.
  • Do not use colour coding to explain and distinguish important information, as this may not be understood by people who have low vision or are colour blind. Colour should not be used as the only means to convey information. Use additional visual indicators to make distinctions clearer, such as additional text, text decoration (e.g. underline) or through the use of patterns and symbols (e.g. dotted lines).
  • If you need to use hyperlinks, then ensure that you use meaningful text for the link itself such that the link on its own still provides sufficient information about its destination (e.g. “more details about this course” is preferred over “learn more”). Once again, this information is useful for assistive technology users who sometimes go over links available in a document in a sequential manner. Also, ensure that links are created using the word processor’s “insert hyperlink” option, since this will also encode link information when generating a tagged PDF.

By following the above points, you will more likely generate accessible PDFs. This is because most modern word processors will also embed this structural information while exporting the document into a PDF. Also, there are tools that would allow you to confirm whether your document is accessible at source. For instance, Microsoft Word has a built-in accessibility checker, that also provides recommendations on how to fix potential accessibility issues.

The following are some word processor specific guidelines:

Saving a source document as an accessible PDF

IMPORTANT: When saving a document as a PDF, ensure that you also include the document structure tags.

Ensuring PDFs are tagged appropriately

Even if you can’t modify the source of the PDF, you can manually tag the PDF with the necessary accessibility information. There are ways by which this process could be automated, however this is not always recommended, depending on the complexity of the document itself.

Ensure that your PDF has the following:

  1. Document title: The PDF document should have an accurate and descriptive title specified in its meta-data. This can be achieved by modifying the document properties and setting the Title field with an appropriate name. This will preview the title of the document on the reader’s title bar, and will also be used by assistive technologies, such as screen readers, to announce the title of the document selected. This is particularly useful if assistive technology users switch between applications or documents. Click here for more details about the document title.
  2. Document default language: The PDF document should have a default language set in its meta-data. Having the document language set will improve the way applications, such as readers and assistive technologies, handle document content. For example, a screen reader will use the appropriate voice (pronunciation) if the respective language packs are installed. Click here for more details about the default language.
  3. Is the document tagged entirely and correctly? If the source document is accessible, then the PDF will most likely contain the appropriate tag structure. This means that different content will be tagged according to its underlying semantics (e.g. lists tagged as lists, headings tagged as headings, paragraphs tagged as paragraphs and so on). This is an important consideration, since assistive technologies rely on this tag structure to communicate the content of the document. Similar to the Accessibility Tree generated by browsers for web pages, PDFs come with a Tag Tree, that contains document tags in a hierarchical order.
  4. Appropriate reading order: Keyboard and assistive technology users should be able to navigate through the content in a logical manner, consistent with the visual order. If your content is organised using multiple columns, then the content must be presented accordingly, from top to bottom starting from the first column, then to the next column and so on. This means that the document needs to be properly tagged with the logical order of all elements. This is also important if interactive elements are present in the PDF document, such as hyperlinks. This means that if a user navigates the document using the “Tab” key, the focus order should be consistent with how the elements are ordered visually. Click here for more details about correct tab and reading order.

Other aspects that one might want to consider include consistent page numbering throughout and that decorative images are marked accordingly so that assistive technologies would not communicate unnecessary information, which could cause more confusion. Visit this link for more details about WCAG PDF techniques.

In case you need more information or assistance on this matter, feel free to reach out by clicking on this link.

Interactive PDFs

PDFs support interactive elements, such as input fields, checkboxes and radio buttons. As with web and mobile applications, these form fields need to be accessible, following a series of recommendations:

  1. Interactive form controls need to be labelled. Form controls need to have a clear label that is both visually and programmatically associated with the control.
  2. Required form controls need to be clearly indicated using a label. Furthermore, if the user does not supply the required data, an alert should be provided clearly indicating what form fields are missing.
  3. Ensure that links are tagged appropriately and that the link text also makes sense in isolation without the surrounding text.
  4. Ensure that all form control have the appropriate role, name and state: doing so will allow assistive technology users to understand what the controls are (e.g. checkbox), how to operate them (e.g. click spacebar to select) and their current state (e.g. not checked).
  5. In case PDF forms can be submitted, ensure that a “Submit” button is available, it is operable and that it submits the data accordingly.
  6. Help users submit data in the expected format. If form controls expect data in a specific format, it is important that users are informed in case any input data is not in the expected format.
Is this all?

The above is only a brief treatment of WCAG guidelines for PDF documents. You should also consider other resources such as:

Step 3: Test your documents

After finishing writing a document, test your work. It is recommended that you test incrementally, rather than everything at one go. Consider adopting at least one of the following approaches:

Manual testing
  1. Try to access the document using a screen-reader (e.g. NVDA, Narrator or VoiceOver). Try to navigate the entire document, and complete actions where applicable (if form controls are present). Can you access all the content in a logical manner? Is the screen reader communicating all the information present in the document accurately?
  2. List down areas where difficulties were noted.
  3. Discuss all difficulties encountered during a team meeting – and plan for possible updates/fixes.
Automated testing
  1. Along with manual testing, you can also review your PDFs using purpose-built tools, such as the accessibility checker that ships with Adobe Acrobat Pro. In case you have the source document, you can use the built-in accessibility checkers that ship with most modern word processors, such as Microsoft Word’s Accessibility Checker.
  2. List down areas where difficulties were noted.
  3. Discuss all difficulties encountered during a team meeting – and plan for possible updates/fixes.

The tests discussed here are definitely not comprehensive and are only meant to put your development efforts on the right path. Complete accessibility audits by specialists will give you a true picture of how accessible your technology and digital content is. If you need more assistance, feel free to reach out by clicking on this link.

Step 4: Involve target users and get audited

This image has an empty alt attribute; its file name is image-from-rawpixel-id-572955.png

Expert accessibility audits will give you a true picture of the state of your documents. These audits, which are generally carried out incrementally, are done by domain experts during which rigorous testing (both manual and automated) is carried out, following any applicable legal framework and guidelines at national and international levels. Auditors will generally produce detailed accessibility reports, based on WCAG success criteria across the four guiding principles and at an agreed level of conformance. Audits also generally include technical recommendations to improve your document’s accessibility.

It is also recommended to test your documents with target users. This is not always an easy task, and it might feel slow until you get the logistics sorted out. However, organisations such as FITA are there to support you and your team and will happily review your work.

Do you need more assistance on this matter? Feel free to reach out by clicking on this link.

Published by Chris Porter