PDF Accessibility Checker

What this checks

Accessibility failures in PDFs are almost always structural rather than visual. A sighted reader can follow an untagged document perfectly well, so the problem stays invisible until someone opens it with a screen reader. The checks below read the parts of the PDF that a screen reader depends on.

• Tagging. Whether the document declares itself tagged and carries a structure tree. An untagged PDF fails the single most important requirement, and the vast majority of PDFs exported by Word, Google Docs, Canva and Google Slides are untagged.
• Alternative text. Every figure and image element must carry a non-empty alt entry. This maps to WCAG 2.1 success criterion 1.1.1 Non-text Content.
• Heading order. H1 to H6 must not skip levels, otherwise a screen reader user navigating by heading loses the document outline. Success criteria 1.3.1 and 2.4.6.
• Tables. Data tables need header cells, header cells ideally need a scope, and a layout table tagged as a data table sends assistive technology reading a grid that is not there. Success criterion 1.3.1.
• Lists. List items must sit inside a list and lists inside a list body, or the announced item count is wrong. Success criterion 1.3.1.
• Links. Link text and link annotations need to say where the link goes. Bare text like "click here" passes the letter of the rule and fails the purpose of it. Success criterion 2.4.4.
• Form fields. Fields named Text1 or Checkbox2 tell a screen reader user nothing. Fields need a real label. Success criteria 3.3.2 and 4.1.2.
• Contrast. Text fill colours are sampled from the page content streams and turned into WCAG contrast ratios. Success criterion 1.4.3.

Why in the browser

Every hosted PDF accessibility checker makes you upload the file. axesCheck sends it to their server, and their own guidance steers you to the Windows desktop build if you would rather not upload. PDFix, Venngage, freepdfchecker, Recite Me and the WebYes PAVE extension all behave the same way, and the PAVE extension is documented as able to keep uploaded documents for weeks.

That is workable for a brochure. It is a blocker for a patient record, a signed contract, a financial statement or anything a lawyer asked you not to put on a third party's server. Doing the parse locally removes the question entirely, and it also means no upload quota, no file size cap and no waiting on a queue.

What this cannot tell you

A machine-verifiable result is one part of a conformance assessment, and treating it as the whole answer is the most common way organisations get this wrong. These items need a person:

• Whether the alt text is any use. Passing a non-empty check on alt text that says "image1.png" is technically a pass and practically a fail.
• Whether the reading order matches the visual layout. A tag tree can be perfectly valid and still sequence a two-column page incorrectly.
• Whether a table is genuinely tabular or decoration that happens to be a grid.
• How a real screen reader, such as NVDA, JAWS, VoiceOver or TalkBack, actually announces the document.
• Two low-level catalogue keys, /Lang and /ViewerPreferences /DisplayDocTitle. These live in the PDF catalogue dictionary, which the browser parser does not expose. They are listed in the manual checklist below rather than guessed at.

Frequently asked questions

Is my PDF uploaded to check its accessibility?

No. The file is read with the browser File API and parsed by pdf.js inside a Web Worker on your own machine. No request containing the document is ever sent. Every online PDF accessibility checker, including axesCheck, PDFix, Venngage, freepdfchecker, Recite Me and the WebYes PAVE browser extension, uploads the file to a server. That is why confidential documents, medical records, contracts and government files are often blocked by policy from using them.

What is PDF/UA and why does it matter?

PDF/UA is ISO 14289-1, the international standard for accessible PDF. It was built on WCAG and is the machine-checkable technical baseline that Section 508, the European Accessibility Act and most state accessibility rules point to. A PDF that passes PDF/UA satisfies the great majority of the technical success criteria those rules reference.

Can an AI chatbot tell me if my PDF is accessible?

No. A language model has never seen your file and cannot open a PDF container, read the structure tree, or walk the tag hierarchy. It can recite the requirements, which is not the same as telling you which ones your document fails. This tool parses the actual document and reports the actual failures.

Is a passing result proof of legal compliance?

No. This tool runs the machine-verifiable subset of the checks. Whether alt text is meaningful, whether reading order matches the visual intent, and how a real screen reader announces the document all need a human. Professional checkers split their output the same way, and any conformance report you file has to state both parts.

What are the usual causes of a failing PDF?

Nine times out of ten it is an untagged export. Word, Google Docs, Canva, Google Slides and most design tools emit PDFs with no tag tree at all, which is the single most common cause of an inaccessible PDF. The next most common is figures that were pasted in without alt text.

How do I fix an untagged PDF?

Remediating a tag tree is real work, and no browser tool can invent correct tags for you. What you can do cheaply is fix the cheap items: add a document title, add alt text to figures in the authoring tool, give form fields real labels, and rebuild the bookmarks. If the document needs a genuine tag tree, budget for a desktop tagger such as PAC or a commercial remediation service.