Skip to content
dialegein

Check a PDF for accessibility

An accessible PDF is not a PDF that looks right. It is one whose structure a screen reader can follow: headings marked as headings, images carrying alternative text, tables tagged as tables, and a reading order that matches the order a person would read. That structure lives inside the file, which is why an inaccessible document can look perfect on screen.

The standards, without the acronym soup

Checking is not fixing

This is the thing worth understanding before you buy anything. A checker reports failure conditions. It does not repair them, and a clean report is not the same as a usable document.

The clearest statement of that limit comes from axes4, who make both of the free checkers below. Their documentation says the checks do not distinguish between essential and non-essential content, so a document can pass and still be awkward to use. Their AI checks, which are the newest part of PAC, deliberately do not assess whether alternative text is correct or whether the reading order makes sense - and those are the two failures that actually stop somebody using a document.

So the honest shape of the work is: automate the mechanical checks, then spend human time on alternative text, reading order and tables. Everything below is the first half.

Free tools for checking (5)

Everything here is free, and none of it repairs. Four of the five validate a document: two of those four are made by the same company - axes4 publishes both a browser checker and a Windows one, and they are not the same tool - and one of those four is an Acrobat plug-in rather than a standalone application. The fifth, pdfGoHTML, does not validate at all, and it is an Acrobat plug-in too, so two of the five need a copy of Acrobat installed. It converts a tagged PDF into structured HTML so that a person can see whether the structure, language and reading order are meaningful. That is the half of the work no checker can do, and it earns its place here precisely because a document can pass every automated test and still be unusable.

Remediation software you run (4)

These do the fixing on your own machine or your own server: tagging structure, building a reading order, repairing tables, correcting the conformance failures a PDF/UA profile reports. The document does not leave your infrastructure to be repaired, which for a confidential file is the whole difference between this group and the next one. That is a statement about how the software is built rather than a result we measured, and it is the same locality finding shown on each profile.

Remediation services you send the document to (8)

These fix the document too, but the document goes to them. That is not a criticism - for a backlog, an upload-and-review workflow with several people on one file is often the only thing that scales, and some of these are the strongest products in the index. It is the fact a reader needs before choosing between them, so it is the axis this group is built on rather than a footnote. Several produce the accessible document in a different format altogether, whether that is Braille, audio or a reading view. At the far end of the scale sit platforms that run an accessibility programme across everything an organisation publishes rather than fixing one document at a time, and they are priced and sold as programmes.

Most are paid and sold to institutions; RoboBraille is the exception, free to individual non-commercial users and subscription-based for organisations. CommonLook PDF is the odd one in this group - it is here because its browser edition uploads, and it is also sold as a desktop download whose data handling the vendor does not state, which is why its profile declines to call it either local or hosted rather than picking one. Everything else here is documented as a hosted service, so ask where the file goes before sending anything confidential.

Editors that include accessibility tools (2)

If you already own one of these, check what you have before buying a separate tool - the accessibility features are usually in the paid edition, and sometimes in a specific tier of it.

Libraries and authoring tools that tag as they write (8)

The better answer to accessibility is usually to generate a tagged document in the first place rather than remediate one afterwards, and both kinds of tool here do that. The libraries tag programmatically, for teams who control how the PDF is produced in code. CommonLook Office is the other approach to the same idea: an add-in that asks for the accessibility information while somebody is writing in Word or PowerPoint and produces the tagged PDF from that, catching structure problems before they reach a finished document rather than repairing them afterwards. It needs the source documents, which is exactly what a remediation tool does not, and it does not make the accessibility question disappear: the author still has to answer it, and the output still needs checking.

Where our evidence stops

Platforms, prices and licences on this page are read from each vendor's own pages and are the same facts as on their profiles. We have not tested how well any of these tools actually repairs a document - we have not run a broken PDF through each one and compared the output. The grouping above is a description of what each tool is for, not a ranking, and nothing here is a recommendation.

The 27 tools tagged with an accessibility job are also listed together on the accessibility job page , and the compliance claims vendors make about their own products are recorded - and marked as checked or unchecked - on each profile.

Related guides