PDF accessibility checker: how to use a risk report

A PDF accessibility checker is useful when it gives you more than a pass/fail badge. The helpful output is a risk report: a list of structural, text-layer, tagging, and semantic issues that explain where a PDF is likely to fail assistive technology, PDF/UA, WCAG, Section 508, or an ADA Title II review.

It is not a certificate. That distinction matters. A good report should help you decide what to fix first, what can be repaired automatically, and what needs a person to review before anyone says the PDF is compliant.

PDF accessibility checker: how to use a risk report

Use the report in this order:

1. Read the document-level score.
2. Fix structural blockers first.
3. Check whether the PDF is tagged.
4. Check whether text can be extracted.
5. Review semantic findings: reading order, tables, headings, lists, and alt text.
6. Send subjective findings to human review.
7. Re-run validation after remediation.

The goal is not to make the report green in one pass. The goal is to separate “this file is broken” from “this file opens, but still reads badly to a screen reader.”

Step 1 — upload one real PDF

Do not start with a perfect sample. Use a PDF that came from the actual backlog: a syllabus, benefits guide, county agenda, board packet, utility notice, bank statement, or public report.

A useful risk report should accept one PDF and return:

Output	What it is for
Summary score	Quick triage: low, medium, high, critical
Findings JSON	Machine-readable issues for automation and review queues
HTML report	A human-readable leave-behind for accessibility, legal, or web teams
Validation summary	PAC, veraPDF, CommonLook, or equivalent validator output
Human-review flags	Items software cannot honestly decide alone

If the tool only says “pass” or “fail,” it is not enough for remediation. You need findings you can act on.

Step 2 — read the PDF accessibility report summary

The summary should answer five questions:

1. Does the PDF open and pass basic structural checks?
2. Is it tagged?
3. Does it have a usable text layer?
4. Are language, title, fonts, and permissions sane?
5. Which findings require human or semantic review?

For example, the first okraPDF PDF accessibility checker prototype ran over 46 real-world PDFs and found:

Metric	Result
PDFs audited	46
Known pages	616
qpdf warnings	26
Critical/high-risk docs	24
Deterministic findings	206
Broken GovDocs samples normalized by qpdf + Ghostscript probes	6/6

That risk report was useful even before the semantic layer existed. It told us which files were structurally risky, which were untagged, which had weak text extraction, and which needed human review.

Step 3 — fix structural blockers first

Structural problems come before accessibility remediation. If a PDF has a damaged cross-reference table, malformed encryption dictionary, broken object graph, or bad permissions, validators and tagging tools may disagree before you even reach WCAG criteria.

Look for findings like:

Finding	Why it matters	First action
qpdf --check warnings	Parser and validator behavior may diverge	Normalize the container and re-check
Extraction for accessibility not allowed	Assistive technology can be blocked	Remove or correct the permission flag
PyPDF/parser failure	Automation may be brittle	Preserve the error and try tolerant recovery
Render succeeds but parser fails	The PDF is readable by eye, not reliably machine-readable	Keep both render and parse evidence

This is the difference between repairing a corrupt PDF and remediating an inaccessible PDF. Corrupt-file repair makes the file open. Accessibility remediation makes the content meaningful.

Step 4 — check tags and the text layer

The fastest high-signal accessibility checks are boring:

Check	Bad signal
Tagged PDF	Tagged: no or no StructTreeRoot
Text layer	pdftotext returns little or no text
Document language	missing /Lang
Title metadata	missing or generic title
Fonts	non-embedded or damaged fonts

An untagged PDF can still look fine visually. That is the trap. It may have beautiful typography and still give a screen reader a flat stream of text with no headings, lists, table headers, or logical reading order.

If the text layer is missing or unreliable, run OCR before semantic remediation. If the PDF is tagged but the reading order is wrong, do not trust the tag tree just because it exists.

Step 5 — separate machine checks from judgment checks

Some accessibility failures are machine-checkable:

• The document has no language.
• The file is untagged.
• The title metadata is missing.
• Text extraction is blocked.
• A validator reports a PDF/UA failure.

Other failures require judgment:

• Is the reading order logical?
• Is the alt text meaningful?
• Are table headers associated with the right cells?
• Is a visual heading actually tagged as a heading?
• Is an image decorative or informative?

That is why a serious report should include a human_review severity. It is not a weakness. It is the honest boundary between automated audit and attestation.

Step 6 — use page evidence, not just WCAG criterion IDs

A generic finding like this is hard to act on:

{
  "standard": "WCAG 1.3.1",
  "finding": "Table headers are missing"
}

A useful finding points to the page and region:

{
  "category": "semantic",
  "severity": "error",
  "page": 4,
  "bbox": [72, 164, 540, 318],
  "finding": "The table visually has column headers, but the structure tree has no TH cells.",
  "impact": "Screen readers read cells without context.",
  "repair": "Tag the first row as table headers and associate headers with body cells.",
  "standard": ["PDF/UA", "WCAG 1.3.1"],
  "confidence": 0.92,
  "auto_repairable": true
}

That page evidence is what lets a reviewer approve, reject, or fix the finding without rereading the whole document.

Step 7 — decide what can be remediated automatically

Most documents have a mix of repair types:

Finding	Usually automatic?	Needs review?
Missing title	Yes	Sometimes
Missing language	Yes	Sometimes
Untagged body text	Often	Yes for complex layouts
OCR text layer missing	Often	Yes for low-quality scans
Reading order	Sometimes	Yes
Table header scope	Sometimes	Yes
Meaningful alt text	No	Yes

Use automation for the obvious parts. Use human review for the claims that carry risk. That gives you three clean tiers:

1. Audited: automated checks and evidence report.
2. Remediated: repaired output with validation summary.
3. Attested: human-reviewed output with procurement-ready evidence.

Avoid words like “certified” or “guaranteed compliant” unless you actually have the liability model and review process to support them.

Step 8 — re-run the report after remediation

The first report is a before snapshot. After remediation, run the same report again and compare:

Before	After
Structural warnings	Cleared or documented
Untagged PDF	Tagged structure tree present
Missing text layer	OCR or text extraction available
Missing language/title	Metadata set
Human-review findings	Reviewed, accepted, or fixed
Validator failures	Reduced or cleared

Keep both reports. Procurement teams, accessibility coordinators, and legal reviewers care about the history, not only the final file.

What not to claim from a PDF accessibility checker

Do not say:

• “This PDF is certified compliant.”
• “This passes WCAG.”
• “This is PDF/UA compliant.”
• “No human review is needed.”

Say:

• “This report identifies accessibility risk.”
• “These findings were machine-checked.”
• “These findings need human review.”
• “This remediated output passed the listed validators.”
• “This attested output was reviewed under the stated process.”

That language is less flashy and much safer.

TL;DR

Use a PDF accessibility checker to triage, not to certify. Fix structural blockers first, then tags and text extraction, then semantic issues like reading order, tables, headings, lists, and alt text. The best risk reports include page evidence and a clear human-review boundary.

okraPDF is building this around bbox-cited findings: every issue should point to the page region that made the report say what it said.

Further reading: Adobe’s PDF Accessibility Auto-Tag API docs · PDF Association Matterhorn Protocol · Section508.gov FY2025 findings