You can't fix what you haven't measured. Checking whether a PDF is accessible means running it against the machine-testable rules of PDF/UA-1 (ISO 14289-1) — the document-layer standard behind WCAG 2.1 AA compliance — and reading the failure list it produces. Here's how to do it, step by step, in under a minute.
What "accessible PDF" actually means
Two standards work together: PDF/UA-1 defines the PDF's internal structure (tags, metadata, reading order), and WCAG 2.1 AA governs the content layer (contrast, language, meaningful link text). For most compliance work — ADA Title II, Section 508, the EU EAA — the practical target is a PDF/UA-1-valid document. Learn more in our PDF/UA beginner's guide.
Step 1 — Run a PDF/UA-1 validator
Upload the PDF to a validator that checks against the full PDF/UA-1 profile. The industry-reference engine is veraPDF, maintained by the Open Preservation Foundation. You can run veraPDF online in your browser — no Java, no download — or use our free PDF accessibility checker, which runs the same engine and returns the report in about 30 seconds. You get three free checks, no account.
Step 2 — Read the validation report
The report lists every failure with its ISO clause. The same five categories come up over and over:
- Tag tree — is the document structured, or raw content with no headings, paragraphs, or lists?
- Metadata — document title, language, and the "tagged PDF" flag
- Figures — do images have alternative text?
- Reading order — does the content flow logically (especially in multi-column layouts)?
- Tables and forms — are headers marked, and do form fields have labels?
Step 3 — Check the document fundamentals
Before remediating, confirm the basics: the document has a title, the language is set, and the "Tagged PDF" flag is yes. An untagged PDF fails almost every downstream check — that's the first thing to fix. Scanned PDFs are a special case: they're just images, so they need OCR and re-tagging first.
Step 4 — Spot-check with a screen reader
Validation catches structural failures; it can't judge whether alt text is good. Open the document in NVDA, VoiceOver, or Read Aloud and listen to a few pages. If the reading order sounds wrong or an image is announced as "graphic" with no description, that's a judgment item the validator flagged for human review.
Fixing what you find
Once you have the failure list, the deterministic 90% — tag tree, metadata, reading order, figure tagging — can be fixed programmatically. Auto-remediation rebuilds the structure, re-validates with veraPDF, and ships the report as compliance evidence for a flat $2.99 per document. Judgment items (alt-text quality on high-stakes documents) deserve a human glance.
Public-sector teams working to the ADA Title II deadlines should keep every validation report — they're your good-faith compliance record. For a side-by-side of the tools, see our checker comparison.
Sources and references
A concrete walkthrough: validating a 20-page report
Here is what the four steps look like on a real document — a 20-page quarterly report with two tables, six charts, and a multi-column executive summary. The file is a standard PDF exported from a word processor, not tagged:
- Upload (Step 1). You drag the 20-page report into the free checker. The validator — the same veraPDF engine used by archives and accessibility auditors — starts running. In about 7 seconds, you have a report.
- Read the results (Step 2). The report shows: Metadata: FAIL — no document title, language not declared, Tagged PDF flag is false. Tag tree: FAIL — no tags present. Figures: 6 failures — all six charts lack alt text. Reading order: FAIL — the multi-column summary reads across instead of down each column. Tables: 2 failures — both tables lack header cell associations. That is your work queue: 15 total failures across 5 categories.
- Check the fundamentals (Step 3). You confirm: the source Word document had real heading styles, but the PDF export stripped them. The document language was English but not declared in the PDF metadata. This is common — the export process is where structure gets lost, even from well-built source files.
- Screen-reader check (Step 4). You open the document in NVDA. The executive summary is read as one continuous sentence because the two columns are merged into a single reading stream. Three of the charts are announced as "graphic" with no description. The two tables are read cell-by-cell, left to right, without any indication that you are in a table. This confirms what the validator flagged: the document structure is broken at every level.
After automated remediation rebuilds the tag tree, re-validates, and you add your own alt text to the six charts, the report passes PDF/UA-1. The same NVDA test now announces headings, navigates by section, and reads the tables with header context.
Understanding your validation report: the anatomy of a failure
Each failure in a veraPDF report contains four pieces of information:
- The rule. A statement of what PDF/UA-1 requires, such as "A document that contains any content shall have a Tagged PDF flag in its document catalog with a value of true."
- The ISO clause. The exact section of ISO 14289-1 that specifies this rule. This is what you cite in compliance documentation.
- The test result. Passed or Failed. A failure means the validator found a counterexample — a specific object or structure in the PDF that violates the rule.
- The location. When possible, the page number or object reference where the failure occurs. This is what a remediator uses to find and fix the issue.
For a full breakdown of the report structure and how to prioritize the five failure categories, see our report-explained guide. For the standard itself, see what is PDF/UA.