30 June 2018 | Ted Page
The limitations of standards compliance
If you are commissioning accessible PDFs it is important to understand that accessible PDF and PDF/UA compliance are not the same thing. One day they may be, but we are currently a long way from that point.
PDF/UA is an important part of the battle to achieve universally accessible PDFs. But it is by no means the whole story. In order to achieve fully accessible PDFs, typically, you will have to go further than PDF/UA compliance, sometimes considerably so. And, as will be seen, sometimes compliance can actually get in the way, in which case you may have to choose between the two.
Why the gap?
In some documents there may be little or no gap between accessible PDF and PDF/UA-compliant PDF. However, in some documents the gap can be substantial, for a number of reasons which we will address shortly.
Automated accessibility checkers
But first, it cannot be stressed enough that running a PDF through an automated accessibility checker does not give you a yes or no answer as to whether a document is accessible or not. We have covered this topic in detail elsewhere (see Over-reliance on automated PDF accessibility checkers), but essentially, if you run a PDF through an automated checker such as PAC and get the result shown below, it means there are many things right with your document. It does not necessarily mean that the document is accessible.
The converse is also true. There could be any number of technical failures against PDF/UA, even in a fully functionally accessible document. The following are just a few examples of how this can be so.
There are no PDF/UA-compliant ATs
Firstly, there are no fully PDF/UA-compliant assistive technologies (ATs). Some are closer than others, with NVDA probably being the closest. But even NVDA, for example, won’t read the contents of a PDF Formula tag, the use of which is required by PDF/UA for all mathematical expressions. Hence, any content tagged in this way will be inaccessible to NVDA users.
If all ATs and all reading systems were to comply with the requirements of the PDF/UA standard, and all document authors also followed it in the creation of their documents, this would go a long way towards narrowing the gap between accessible PDF and PDF/UA compliance. But it would not close the gap entirely.
Accessibility requirements that are not PDF/UA requirements
There are several important PDF accessibility requirements that are not PDF/UA requirements. For example, PDF/UA (7.2) requires only that the reading order of a PDF’s tags be correct (or “logical”). However, some ATs do not take their reading order from tags. In the UK, the popular literacy software Read&Write Gold is perhaps the most important example. In short, you will have to go significantly further than the requirements of PDF/UA in order to make PDFs that are fully accessible to all AT users. For a detailed account of this, including a video demo of Read&Write Gold in action, see PDF accessibility and reading order.
Or to take another example, with respect to footnotes and endnotes, PDF/UA requires only that such content be contained within a Note tag. However, making footnotes and endnotes accessible requires a great deal more work. See Accessible PDF footnotes and endnotes for much more on this.
Again, there are many other possible examples, some of which we will cover in future posts (on navigation, and when and when not to hack, and more…).
Mutual exclusivity
Also as mentioned above, there are times when you may face a straight choice between compliance and accessibility, such as in the case of the Formula tag. As things currently stand, authors of documents that contain mathematical expressions will have a direct choice between compliance (that is, using the Formula tag) and accessibility.
Another such case is the PDF/UA prohibition on skipped headings. I have written over 7,000 words elsewhere on why the skipped headings “rule” is bad for accessibility and will not labour the point here. But some documents absolutely require that you sometimes skip a heading level in order to accurately convey to the user the actual structure of the document. From time to time I see excruciating examples of attempts to comply with the no skipped headings rule, and in the process some considerable violence done to the semantics of a document.
To be fair, the Formula tag issue could quite easily be fixed in a future version of NVDA and, as I understand it, the no skipped headings rule will (thankfully) be removed from the next version of PDF/UA (version 2.0). But that is precisely the point—these problems are resolvable, but we’re not there yet.
Compliance requirements that have no impact on accessibility
Finally, it should also be noted that PDF/UA compliance requires additional work that has no impact on accessibility at all. For example, PDF/UA 1.0, 7.18.1 requires that:
Any annotation that does not have a Contents key in its dictionary shall have an alternative description as required in ISO 32000-1:2008, 14.9.3.
If you have tools such as the excellent axesPDF QuickFix you can fix this “problem” easily with one click for the whole document. However, if you don’t have such software (and most won’t) it could take an enormous amount of work to do this manually for a document containing many links.
A similar situation exists with respect to the requirement for IDs for Note tags (PDF/UA 1.0, 7.9), although the workload to provide these is considerably lower than for annotation Contents keys. Maybe one day these will have an impact on the accessibility of a document but right now, they have none.
Conclusion
At some point in the future, with improvements to all the relevant software as well as to the PDF/UA standard itself, it is possible that the gap between accessible PDF and PDF/UA compliance might be reduced to zero. But it could be many years before we get to that point.
In the meantime, PDF/UA should be seen as a useful benchmark for PDF accessibility. But if you make it your only benchmark, your documents may not be as accessible as they otherwise might be.