18 April 2017 | Ted Page
Abstract
It is widely believed that compliance with PDF/A (the PDF archiving format) has no negative impact on PDF accessibility. This is broadly correct, but there are a few notable exceptions with respect to colour customisation, JavaScript, and forms.
What is PDF/A?
PDF/A is the ISO archiving standard (ISO 19005). Essentially, PDFs that conform to the standard should be readable on compliant reading devices long into the future. PDF/A will therefore be of interest to government, the medical and legal professions, libraries, newspapers and anyone else needing to keep documents for long periods.
There are several versions of PDF/A. Three of them, versions 1a, 2a and 3a, are specifically intended to support PDF accessibility. For the most part, they do. However, there are several potential PDF/A accessibility issues.
Problem 1: text/background colour customisation
Arguably the most important problem with PDF/A from an accessibility point of view is that it disables readers’ ability to customise text and background colours.
To customise colours in Adobe Acrobat or Reader, select Edit (Windows) or Acrobat (Mac), Preferences, Accessibility, Document Colors Options, and then set text and background colours as required.
Why is disabling customisation a problem?
The W3C’s Text Customization Wiki (accessed November 2016) sums up the importance of enabling reader choice:
Without customisation, one user’s needs can conflict with another user’s needs. For example, many people with declining eyesight due to ageing need high contrast between text and background colour; whereas many people with dyslexia and other reading impairments need low contrast.
Hence, disabling this functionality will, for most people, compromise the accessibility of a PDF.
Disabling PDF/A
One exception will be those who have access to (often expensive) assistive technologies that enable independent colour customisation (such as ZoomText or SuperNova). Alternatively, if you know how, you can disable PDF/A in Acrobat or Adobe Reader. To do so, go to Preferences, Documents, and set View documents in PDF/A mode to Never.
Something for your website accessibility statement?
However, it is probably not safe to assume that your readers will know how to do this. Hence, if you publish PDF/A documents, the above might perhaps be worth a mention in your website accessibility statement.
Problem 2: footnotes and endnotes
A second problem concerns footnotes and endnotes. Making notes accessible is one of the hardest things to get right in a PDF. In short, the most accessible solution by far requires some quite complex tagging techniques together with a little JavaScript. [Please see our more recent post Accessible PDF footnotes and endnotes for details.]
However, JavaScript is not permitted under PDF/A, and is stripped out in the conversion process. Hence you face a choice between PDF/A compliance or compromising the accessibility of footnotes or endnotes.
Problem 3: forms
Finally, it should be noted that form fields will also be stripped out on conversion to PDF/A. It might be thought that archived forms are unlikely to need active form fields. However, past exam papers used by today’s students for exam practice are one example in which this is clearly not the case.
Conclusion
PDF/A supports most, but certainly not all, PDF accessibility functionality. Depending on the targeted readership and/or the nature of the document in question, conversion to PDF/A may or may not compromise the accessibility of your documents.