PDF Accessibility Pre-Checks in the Browser: What Automation Can (and Cannot) Tell You

A PDF can look perfectly readable on screen and still be difficult to navigate with a screen reader. The reverse is also true: a file can pass several automated checks while still containing confusing reading order, weak alternative text, or an inaccessible complex table.

That is why I treat automated PDF checking as a pre-check, not as certification.

What a browser-based pre-check can inspect

A local checker can examine machine-verifiable signals exposed by the PDF structure, including:

• whether the document contains tags and a usable structure tree;
• whether basic metadata such as a title and document language is present;
• whether form fields and links expose detectable structure;
• whether pages appear to be image-only and may need OCR;
• whether the file can be parsed successfully before deeper review.

These checks are useful because they turn a vague question — “is this PDF accessible?” — into a concrete list of issues to investigate.

What automation cannot prove

Passing structural checks does not prove conformance with WCAG, PDF/UA, Section 508, or any legal requirement.

Several important questions still require human judgment:

1. Does the reading order match the intended meaning?
2. Is alternative text accurate and useful in context?
3. Are headings, lists, and tables tagged semantically rather than merely present?
4. Is color contrast sufficient?
5. Can a keyboard and real assistive technology complete the document's tasks?
6. Are complex tables understandable when read linearly?

For formal review, the automated result should be followed by manual inspection in Adobe Acrobat or another professional PDF accessibility tool, plus assistive-technology testing.

Why local processing matters

PDFs often contain private material: contracts, student records, internal reports, or unpublished research. A useful first-pass checker does not need to upload that content.

I maintain PDF Accessibility Checker, a free browser-based pre-check that uses PDF.js locally. The PDF file, filename, document content, hash, and local path are not uploaded by the scanning workflow.

You can try the browser-local pre-check here:

PDF Accessibility Checker

Disclosure: I am the product maintainer/operator. The tool checks a limited set of machine-verifiable signals. It is not a compliance certificate and it does not replace a manual audit.

A practical review sequence

A defensible workflow is:

1. Run a structural pre-check.
2. Fix obvious metadata, tagging, and OCR problems.
3. Inspect reading order, headings, lists, links, and tables manually.
4. Review alternative text for meaning, not just presence.
5. Test keyboard interaction and at least one screen reader.
6. Record which checks were automated and which were reviewed by a person.

This keeps automation in the role where it is strongest: finding repeatable structural signals quickly, while leaving semantic and experiential decisions to human reviewers.

For the standards background, refer to the W3C WCAG overview and the PDF Association's accessibility resources.

The most useful result from an automated checker is not a green badge. It is a clear, explainable list of what to verify next.