Why we built a basic PDF accessibility checker

Most PDFs fail a screen reader in some way, and almost nobody finds out until someone who actually relies on one tries to open the file. A document can look perfect, correct spelling, clean layout, right logo in the corner, and still be functionally unreadable to anyone using assistive technology. The Accessibility Checker exists to catch the handful of structural issues that cause most of that, in the thirty seconds it takes to drop a file in.

What "accessible" actually means for a PDF

A PDF is really two documents in one: the version you see, and a separate structural map, the tag tree, that tells a screen reader what each piece of content actually is: a heading, a paragraph, a table cell, a figure with a caption. Word and most modern editors can generate that map automatically when you export to PDF, but plenty of PDFs never had one, especially scans, old exports, and anything assembled by merging several source files together. Without it, a screen reader has nothing reliable to read, it might announce nothing, announce everything in the wrong order, or skip whole sections.

Five things worth checking before anything else

Full accessibility conformance, PDF/UA and WCAG, covers dozens of criteria: contrast ratios, reading order, table headers, link purpose, and more. Most of that needs a human (or a proper screen reader) to verify. But five things can be checked structurally, in a browser, in under a second, and they happen to be the ones that break the experience hardest when they're missing:

• Is the document tagged at all? If not, nothing else matters yet.
• Is a document language set? Without it, a screen reader may guess wrong and mispronounce the entire thing.
• Is there a document title? Otherwise a screen reader announces the filename, Scan_2024_final_v3.pdf is not a great first impression.
• Do tagged images have alt text? A screen reader either skips an untagged image entirely or reads out a meaningless file reference.
• Do form fields have a description? A form field with no label reads as "edit text, blank" to a screen reader, useless to anyone who can't see the visual label beside it.

What it deliberately doesn't claim

Passing all five doesn't mean a document is accessible, it means five structural basics are in place. Colour contrast needs the page actually rendered and pixels sampled. Reading order needs confirming that content makes sense in the sequence it's presented, not just that a sequence exists. Table headers need checking that data cells are properly associated with them. None of that is safe to fake with a quick heuristic, getting it wrong confidently would be worse than not claiming it. For that level of review, a dedicated tool like PAC, free, and built specifically for PDF/UA and WCAG auditing, including a screen-reader structure preview, is the right next step.

Why this runs in the browser at all

The documents most worth checking, enrolment forms, government submissions, HR paperwork, often contain exactly the kind of personal information this site avoids sending anywhere. Where processing actually happens for something like this matters more than it sounds, see our guide to AU/NZ privacy law and document uploads for why. The checker reads the file's internal structure using the same client-side libraries every other tool here already uses, nothing is uploaded to run it.

Frequently asked questions

Related guides

• How VET providers and universities across Australia and NZ use PDF tools
• What Australian and NZ privacy law says about uploading your documents online