(One more time…) a PDF that passes an automated check against standards and an accessible PDF are not the same thing—and the distinction matters

16th January 2020 | by Ted Page

I wish I didn’t have to keep making this argument, but…

I recently read yet another PDF accessibility article (this one from a well-known source) that implied strongly that a PDF that passes an automated check against one or more relevant standards and an accessible PDF are the same thing. This can be true, but all too often, it isn’t.

The shortcomings of a compliance-only approach

Whilst a standards-compliant PDF can be an accessible PDF, and vice versa, neither is a precondition for the other. And if you just aim for an automated compliance check you could leave potentially serious accessibility problems undetected in your documents.

Ironically, and as a case in point, the PDF in which the article in question appeared will pass an automated check against the PDF/UA standard (see screenshot below), but at the same time it contains at least 6 serious accessibility problems.

Automated accessibility checker results page showing a column of green ticks against a range of test criteria
Figure 1: PAC 3 results page

These problems are:

  • Reading order for people who want to read the document in reflow view or who use certain types of literacy software
  • Some tiny fonts (less than 5pt)
  • Screen reader inaccessible links
  • Words broken across line breaks with hard hyphens
  • Bookmarks that shrink the page’s zoom setting when clicked
  • Bookmarks which go only to the top of the page and not to the required destination

Beyond automated checkers

As I advise those taking my PDF accessibility training courses, once a PDF has passed an automated ‘accessibility checker’ (which really shouldn’t be called that at all), and assuming they have sufficient knowledge to ignore various Type 1 errors that checkers are liable to return (such as telling you that a skipped heading is a problem when it isn’t) then, and only then, will they be ready to actually start testing a document for accessibility, including identifying any Type 2 errors—things that no automated checker can pick up, but which really matter.

Testing with assistive technologies

Doing so requires testing with multiple assistive technologies, not just screen readers. This is not hard to do: a standard test routine can be learnt in half an hour.

The idea that an automated check can verify whether a PDF is accessible or not, is simply wrong, however attractive a prospect it might be. If you care about accessibility, you absolutely must dispense with this notion in its entirety. Use automated checkers by all means—properly understood they are useful tools. But once you have ironed out any bugs a checker has found is when the real testing begins, not ends.