{"id":993303,"date":"2026-11-05T08:00:00","date_gmt":"2026-11-05T08:00:00","guid":{"rendered":"https:\/\/ifdb.io\/?p=993303"},"modified":"2026-11-05T08:00:12","modified_gmt":"2026-11-05T08:00:12","slug":"checking-pdfs-for-accessibility-tools-common-errors-and-the-correct-procedure","status":"publish","type":"post","link":"https:\/\/ifdb.io\/en\/checking-pdfs-for-accessibility-tools-common-errors-and-the-correct-procedure\/","title":{"rendered":"Checking PDFs for accessibility: tools, common errors and the correct procedure"},"content":{"rendered":"\n

When companies come to us with their PDFs, many have already checked them themselves. That\u2019s good, because if you check them, you know where you stand. The real surprise usually comes elsewhere: in the number of documents and in an error that hardly anyone expects.<\/p>\n\n

In this guide, I\u2019ll show you how to check a PDF for accessibility, which tools are best suited for the task, which errors crop up most frequently in practice, and how to integrate this checking process into your workflows so that it doesn\u2019t turn into a major project. I explain how to create an accessible PDF from the outset in the guide \u2018Creating an accessible PDF<\/a>\u2019. This guide focuses solely on checking.<\/p>\n\n

In a nutshell: checking a PDF for accessibility in six steps<\/p>\n\n

    \n
  1. Compile an inventory: all PDFs on the website and the number of pages per document.<\/li>\n\n\n\n
  2. Check automatically, for example using Access Read, PAC or Adobe Acrobat Pro.<\/li>\n\n\n\n
  3. Sort the results: technical errors on the one hand, and issues requiring human assessment on the other.<\/li>\n\n\n\n
  4. Check tables, reading order and alternative text specifically, ideally using a screen reader.<\/li>\n\n\n\n
  5. Make documents with errors accessible or correct them in the source file.<\/li>\n\n\n\n
  6. Make the check a fixed part of the process before a new PDF goes live.<\/li>\n<\/ol>\n\n

    What makes a PDF accessible<\/h2>\n\n

    An accessible PDF contains a structure behind the visible page, known as tags. These tell a screen reader what constitutes a heading, a list or a table, and in what order the content should be read. In addition, there are alternative texts for images, a specified document language and a meaningful title. The relevant standard is PDF\/UA, the international standard ISO 14289.<\/p>\n\n

    If this structure is missing, the PDF looks completely normal to sighted people. However, a screen reader will then, at best, read out unordered text and, at worst, nothing at all \u2013 for example, in the case of a scanned document consisting solely of images.<\/p>\n\n

    It is also important to note the difference between \u2018low-barrier\u2019 and \u2018accessible\u2019 here. Automated processing removes barriers and produces a \u2018low-barrier\u2019 PDF. A document is only considered \u2018accessible\u2019 once it has been additionally checked by a person. You can read more about this in the guide \u2018Creating Accessible Documents\u2019<\/a>.<\/p>\n\n

    What companies use to check PDFs<\/h2>\n\n

    Most clients who come to us with PDFs that have already been checked have used PAC, the PDF Accessibility Checker. PAC is free, is now provided by axes4, and checks against PDF\/UA and the WCAG. To be honest, it\u2019s a good tool, and in practice it doesn\u2019t overlook anything that can be checked automatically. Some clients also use Adobe Acrobat, the Pro version of which includes its own accessibility checker.<\/p>\n\n

    With Access Read<\/a>, we have created a third option: the check is carried out entirely online in your browser. You don\u2019t need to install anything; simply upload your PDF and get the result in seconds, from any computer.<\/p>\n\n

    Tool<\/th>Where it works<\/th>Strengths<\/th>Limitations<\/th><\/tr><\/thead>
    PAC (axes4)<\/td>Downloadable programme<\/td>Free, checks PDF\/UA and WCAG, with preview for screen readers<\/td>Must be installed<\/td><\/tr>
    Adobe Acrobat Pro<\/td>Paid desktop software<\/td>Validation right where many PDFs are edited<\/td>Licence required; the free Reader version is not sufficient<\/td><\/tr>
    Access Read<\/td>In the browser<\/td>No installation required, fast, accessible from anywhere<\/td>Like any automated check, it is no substitute for human judgement<\/td><\/tr><\/tbody><\/table><\/figure>\n\n

    What an automated check detects and what it does not<\/h2>\n\n

    Automated tools can reliably detect whether tags are present, whether images have alternative text, whether language and titles have been set, and whether the structure is formally correct. What they cannot assess is the meaning: whether an alternative text actually explains the diagram, whether the reading order is logical, or whether a heading is, in terms of content, actually a heading.<\/p>\n\n

    Practical tip: After the automated check, open a random selection of your most important documents using a screen reader, such as NVDA on Windows or VoiceOver on a Mac. Just five minutes will show whether a document is truly accessible.<\/p>\n\n

    The most common error: tables<\/h2>\n\n

    If I had to say which error crops up most frequently in Access Read, I\u2019d have to say, quite honestly, tables. They\u2019re tricky and never fail to catch people out \u2013 even teams that usually do a thorough job.<\/p>\n\n

    The reason: sighted people can take in a table at a glance. A screen reader reads it cell by cell. For a number to make sense, the screen reader needs to know, for every cell, which column and which row it belongs to. It\u2019s precisely this mapping that\u2019s often missing. Typical causes include:<\/p>\n\n