Most PDF/UA guides describe the standard. This one also reports what happens when you point a validator at a real city's document library, because the gap between the two is where remediation budgets actually go.
Deadline status, August 2026. On 17 April 2026 the Department of Justice extended the ADA Title II web and mobile accessibility deadlines by one year: 26 April 2027 for public entities serving 50,000 or more people, and 26 April 2028 for smaller entities and special districts. HHS followed on 7 May 2026, moving the Section 504 deadlines to 11 May 2027 and 10 May 2028. The technical standard did not change: WCAG 2.1 Level AA. Among the reasons DOJ gave for the extension were slower-than-expected technological solutions, including the limits of generative AI for remediation.
What PDF/UA is
PDF/UA is ISO 14289-1. It is a file format standard: it describes how a PDF must be constructed so that assistive technology can interpret it reliably. It says nothing about visual design and nothing about whether the writing is any good.
In practice it requires that a document carry a real structure tree — a semantic skeleton naming which marks on the page are headings, paragraphs, list items, table cells, figures and artifacts — and that the structure be complete, correctly ordered, and correctly typed. Everything else follows from that.
What PDF/UA is not
It is not a legal safe harbour. No regulation says "conform to ISO 14289-1 and you are compliant." Title II names WCAG 2.1 Level AA.
It is also not a synonym for accessible. A document can conform fully and still be useless to the person it exists for, and the standard is explicit enough about its own scope that this should not be a surprise. Clause 7.3 requires alternative text to be present and non-empty. It cannot require the text to be correct, because no machine can judge that.
How PDF/UA relates to WCAG, Section 508, and ADA Title II
These are layered, not alternatives. One is a technical construction standard, the others are regulatory conformance targets.
| Standard or rule | What it covers | Why it matters to a public agency |
|---|---|---|
| PDF/UA ISO 14289-1 | How an accessible PDF must be built | The only part of the stack a validator can measure objectively |
| WCAG 2.1 AA | Content accessibility across web and documents | The conformance target named in the rules; what a complaint will cite |
| Section 508 | Federal ICT procurement | Flows into state and local contracts; drives the VPAT request |
| ADA Title II | State and local government services | The enforcement mechanism, with the 2027 and 2028 deadlines |
| EN 301 549 / EAA | European public sector and, since June 2025, private sector | Relevant if you publish to an EU audience |
The practical consequence: a regulator asks about WCAG, a validator answers about PDF/UA, and somebody has to bridge the two honestly. Conformance with ISO 14289-1 is strong evidence toward WCAG 2.1 AA for a document, not a substitute for it.
The Matterhorn Protocol
Most guides skip this, which is a shame, because it is the part that explains why automated checking can only take you so far.
The PDF Association's Matterhorn Protocol restates PDF/UA as 31 checkpoints containing 136 failure conditions. Each condition is classified by how it can be detected. Roughly two-thirds are machine-checkable; the rest require human judgement, and no amount of engineering moves them across that line.
This is the honest basis for the split every serious programme ends up making:
- Machine-checkable — is there a structure tree, is every content item tagged, does a figure carry alternative text at all, is a document title set, is the language declared, do heading levels descend without skipping.
- Human-checkable only — does the alternative text describe the image accurately, is the reading order the order a person would read in, do the table headers actually describe their columns, is a decorative image genuinely decorative.
veraPDF implements the machine-checkable subset. That is precisely why an automated pass is meaningful and also why it is not a certificate of accessibility.
Core technical requirements
Tagged structure
Every piece of real content is inside the structure tree with a correct role, and everything that is not content — page furniture, rules, background images — is marked as an artifact. Untagged content is the single most common validator failure and usually indicates the document was never tagged at all.
Logical reading order
The structure tree order, not the visual layout, is what a screen reader follows. Multi-column layouts, sidebars, and pull quotes are where this breaks, and it breaks silently: the document looks correct and reads wrong.
Language and metadata
A document title in the metadata, a declared default language, and declared language for any passage in a different one. These are small, cheap, and account for a disproportionate share of failures because export tools rarely set them.
Alternative text
Every figure carries a description; genuinely decorative images are marked as artifacts instead. The standard checks presence. Quality is on you.
Accessible tables
Real header cells with scope, correct row and cell structure, and no layout tables masquerading as data. Tables built for appearance rather than meaning are among the most expensive things to remediate after the fact.
Accessible forms
Every field has an accessible name that matches the visible label, and a sensible tab order. A confidently wrong label is worse than none, because it sends someone to the wrong field with no clue they have gone wrong.
Searchable text
A scanned page with no text layer cannot be made conformant by tagging. It needs OCR first, and the OCR needs checking — a bad text layer produces a document that passes automated checks while reading as nonsense.
What actually fails: measured
The following comes from documents we processed for public agency customers. Sample sizes are given so you can weigh them.
| Measure | Result | Sample |
|---|---|---|
| Documents audited across a municipal corpus | 5,391 documents / 74,163 pages | full corpus |
| Scanned images with no text layer at all | 9.7% (525) | 5,391 |
| Failed PDF/UA on arrival, before any remediation | 88.4% (727) | 822 measured |
| Needed a full structural rebuild rather than a targeted fix | 75.0% (629) | 839 remediated |
| Fixable with a targeted, structure-preserving repair | 14.3% (120) | 839 |
| Blocked entirely (encrypted, corrupt glyph mapping, damaged source) | 7.3% (61) | 839 |
| Conformant after remediation, verified by veraPDF | 87.7% (663) | 756 judged |
Two of those numbers are worth dwelling on.
Three-quarters needed a full rebuild. A targeted fix is possible when a document was built properly and lost something small. A full rebuild means the source had no accessibility structure to preserve. That is the signature of a document produced by someone who was never asked to care — and in a government corpus, a great deal of what gets published was authored by outside consultants, applicants and contractors rather than by the agency.
Roughly one in ten has no text layer. Those cannot be tagged into conformance. They need OCR first, which means they are a scanning problem wearing an accessibility problem's clothes, and budgeting for them as remediation will produce a nasty surprise.
Common validator failures, by clause
These are the veraPDF clause numbers you will actually see, in rough order of frequency.
| Clause | What it means | Typical fix |
|---|---|---|
| 7.1 | Content is not tagged, or the structure tree is missing entirely | Tag the document; artifact genuine page furniture |
| 7.2 | Document title missing, or language not declared | Set metadata title and /Lang — cheap, and worth doing at source |
| 7.3 | A figure has no alternative text | Describe it, or mark it as an artifact if truly decorative |
| 7.4 | Heading levels skip or nest incorrectly | Rebuild the heading hierarchy so levels descend by one |
| 7.5 | Table structure is invalid, or headers lack scope | Rebuild as a real data table; convert layout tables to structure |
| 7.18 | Form field or annotation has no accessible name | Label the field; add Contents to link annotations |
| 7.21 | Font program missing or not embedded | Embed the font, or re-export from a source that does |
How to test
Automated
veraPDF is the PDF Association's open-source reference implementation and the sensible default for a programme that needs a defensible verdict — anyone can install it and reproduce your result. PAC (PDF Accessibility Checker) is free and widely used by auditors, though Windows-only with no CLI. Adobe Acrobat Pro's checker is what many reviewers will reach for first.
Expect occasional disagreement between them at the margins. Decide in advance which one is authoritative for your programme, and record which build produced each verdict — a rule set changes between releases, and "we checked it with veraPDF" is a weaker claim than naming the version.
Manual
Read the document with a screen reader. Check that the reading order matches how a person would read it, that image descriptions say something useful, that table headers describe their columns, and that form labels match their fields. This is the Matterhorn remainder, and it does not automate.
Delivery
A conformant file served badly is still inaccessible. Check that the link is keyboard reachable and describes its destination, and that the file is not trapped behind a viewer that strips the structure you just paid to add.
A workflow that holds up
- Inventory first. You cannot budget what you have not counted. Page count matters more than document count, because remediation is priced per page.
- Separate the scans. Documents with no text layer are an OCR project, not a tagging project.
- Fix at source where a source exists. A title and a language declaration set in the authoring tool are free; the same fix applied downstream is billable and has to be re-applied on every revision.
- Remediate the rest, with targeted repairs where structure survives and a rebuild where it does not.
- Validate the output file itself — not the process that produced it.
- Route the human checkpoints to a human. Alternative text and reading order need review, and the review needs recording.
- Keep the evidence, bound to the file's digest, so the claim survives the document being edited or re-exported.
Verify the output, not the run. The most common failure in an automated remediation pipeline is not a bad fix — it is recording success because the code completed. A document is conformant because a validator says so about the bytes that were produced, or it is not conformant. Anything else is an assumption with a progress bar.
Frequently misunderstood
"We ran a checker and it passed, so we're compliant."
A pass means the machine-checkable subset is satisfied. Roughly a third of the Matterhorn failure conditions are not machine-checkable, and alternative text quality is the biggest of them. A corpus can be 100% conformant and substantially unusable.
"We remediated it last year."
Tag structure does not survive re-export, page insertion, or flattening reliably. Conformance describes one exact set of bytes on one date. If the file has been touched since, the claim needs re-checking — which is why a conformance record should be bound to a SHA-256 digest rather than a filename.
"Our platform makes documents accessible."
Ask what validates that, and ask to see the result for a specific file. A vendor's product-level VPAT is a self-attestation about the tool, not evidence about your document.
"The consultant's report is the consultant's problem."
Under Title II, a public entity is responsible for content it provides or makes available, including through contractual arrangements. Liability does not transfer with the file. This is why so much of a remediation budget is spent repairing documents somebody else authored.
Checklist
Source and authoring: heading styles used properly, real tables not layout tables, alternative text written by the author who knows the content, title and language set before export.
Conversion and scanning: text layer present and spot-checked, resolution adequate for the source, tagging applied rather than assumed.
Remediation and QA: validated with a named validator and version, human review completed for alternative text and reading order, failures recorded by clause rather than as a single pass/fail.
Delivery and evidence: link text describes the destination, evidence bound to the file digest, and a record you can hand an evaluator without asking them to trust you.