What a PDF accessibility checker is
A PDF accessibility checker is a tool that inspects a tagged PDF and reports whether the tags, structure, reading order, alt text, language, and metadata meet the requirements set out in PDF/UA and WCAG 2.2. It reads the file, walks the structure tree, and returns a list of issues with a location for each.
Well-known examples include Adobe Acrobat's built-in Accessibility Checker, the free PAC (PDF Accessibility Checker) from Access for All, CommonLook, axesPDF and the checker inside Foxit. Each reads the same underlying standards; they differ in depth, licensing, and reporting.
What checkers can tell you
- Whether the file is tagged at all, and whether every content element carries a tag.
- Whether headings, lists, tables and links are marked up with the correct structure types.
- Whether images carry alternative text, and whether decorative content is marked as artifact.
- Whether the document language, title and reading order are set.
- Whether colour contrast on rendered text passes WCAG thresholds.
What checkers cannot tell you
A checker verifies the file it was given. It cannot tell you whether the alternative text is meaningful, whether the reading order matches the author's intent, whether the tables actually describe rows and columns a screen reader user can follow, or whether the document is written in language a reader can act on. Those judgements need a human. The W3C's own guidance on evaluating accessibility is explicit that automated checks catch a portion of failures, not all of them.
A checker also cannot tell you what to do about the PDFs it flagged. It produces a list of findings against one file, at one point in time. The remediation, and the ongoing maintenance as the source document changes, sits with the organisation.
Why checking is only half the work
Most organisations do not have a hundred PDFs. Municipal government estates run to tens of thousands. Financial services and universities carry more. Every PDF discovered by the checker needs a decision, a tagging pass, a review, and re-checking. The cost of that pipeline grows linearly with the number of documents, and never ends, because new PDFs are published every week.
A checker is a diagnostic. It tells you the size of the gap. It does not close it.
Automated conversion as the fix
Automated conversion changes the question. Instead of remediating each PDF against the standard the checker measures, the source PDF is converted into a structured HTML page that people, screen readers, AI models and AI agents can all read directly. The HTML carries the structure that a tagged PDF would need to declare separately, and the browser handles reflow, zoom, translation and keyboard navigation as native behaviours of the format.
aicm operates this way. It discovers every PDF across the sites it is deployed on, catalogues them, and produces a web version alongside the original. Visitors, assistive technologies and AI systems reach the version they can use. The estate becomes accessible in the same weekly rhythm as the rest of the website, rather than as a separate remediation project.
How to think about the choice
For a one-off document, a checker plus a person is the right tool. For an estate of hundreds or thousands of PDFs, checking each one is a task that never finishes. Automated conversion moves the work upstream, so accessibility, AI readability and inclusion follow from the same act of publishing.
If you are choosing a PDF accessibility checker, start with what you want to know: coverage of PDF/UA and WCAG 2.2, the depth of the structural checks, the quality of the report, and whether it fits your review workflow. Then decide, honestly, how many PDFs you are proposing to run through it each month, and what happens to the ones it flags.