Most inaccessible PDFs fail for a handful of boring, mechanical reasons. No tags. No language. No title. A chart with no description. A form whose fields have no names. This page reads the document structure in your browser and tells you which of those apply, in seconds, without the file leaving your machine.
Why the browser, and why no upload
The tool everyone recommends, PAC from the PDF Association, is excellent and Windows-only. The web alternatives generally want you to upload the file. The documents that most need an accessibility check tend to be exactly the ones you cannot hand to a third party: student records, HR paperwork, medical forms, court filings. So this runs client-side. The bytes are read by JavaScript in your own tab and nothing is transmitted.
What gets checked
Two layers. Structure: whether the file is tagged, whether the structure tree actually exists rather than merely being claimed, how many elements it holds, whether headings are present and whether their levels skip. Metadata and content: the document language, the title and whether readers will display it, the PDF/UA claim if one is present, alternative text on tagged figures, accessible names on form fields, and whether the document has a text layer at all.
That last one decides everything else. A scanned document declares no fonts and draws images, and no amount of tagging makes it readable — it needs OCR first. The checker says so plainly instead of listing twelve downstream failures that all have the same cause.
What a passing result actually means
It means the prerequisites are in place. It does not mean the document is accessible, and the page says so next to the results rather than in the small print. A machine can see that a figure carries an /Altstring; it cannot see whether that string reads “Revenue fell 12% in Q3” or “image1.png”. It can see that a heading is tagged H2; it cannot see whether it actually labels the section beneath it. Automated checking gets you to the floor. Getting from the floor to a document someone can actually use takes a person.
Where this fits with preflight
Accessibility and print-readiness are different questions about the same file, and they fail in different ways. If you are sending a document to a press rather than publishing it, the PDF preflight checker covers bleed, TrimBox, colour space, embedded fonts, spot inks and overprint. Same approach, same no-upload guarantee, different rulebook.
Doing this on PDFs your own product generates
If you are producing PDFs programmatically rather than checking one by hand, the constraint moves upstream: an accessible document has to be authored with structure, not repaired afterwards. Polotno's PDF generation writes vector PDFs whose text is real, selectable text rather than shapes, which is a prerequisite for an accessible document — a page of outlines or a rasterised image can never be made readable. It is not sufficient on its own: the SDK does not currently emit a tagged structure tree, so a PDF it produces will fail the first check on this page. Worth knowing before you plan around it.
