DocoMatic

Compliance hub

PDF/UA: the ISO standard for accessible PDF files

PDF/UA — ISO 14289, 'UA' for universal accessibility — is the international standard defining what an accessible PDF must look like internally: complete tagging in logical reading order, artifacts for decoration, alternative text, Unicode-mapped text and set metadata. It is the file-format counterpart to WCAG's content requirements, and much of it is machine-verifiable.

The standard

What is PDF/UA (ISO 14289-1)?

PDF/UA is the ISO standard for accessible PDF, published as ISO 14289-1. It specifies the technical requirements a PDF file — and the software that reads it — must meet so assistive technology can interpret the document reliably. It is to accessibility what PDF/A is to archiving: a testable profile of the PDF format.

PDF/UA-1 targets the PDF 1.7 format that virtually all tools produce today; PDF/UA-2 (ISO 14289-2, published in 2024) extends the standard to PDF 2.0. When a contract or policy says 'PDF/UA' without qualification, it almost always means PDF/UA-1.

Inside the file

What does PDF/UA standardize inside a file?

PDF/UA requires that all meaningful content be tagged in a structure tree reflecting the logical reading order, that purely decorative content be marked as an artifact, and that the file carry the metadata assistive technology depends on: a displayed document title, a declared language, and a Unicode mapping for every character.

Complete, semantically correct tags

Every piece of real content sits in the structure tree with the right role — heading levels, paragraphs, lists, tables with header associations, links and figures.

Artifacts for everything decorative

Page furniture — running headers, footers, page numbers, background graphics — is marked as artifact content so it never interrupts the reading order.

Metadata and document settings

A document title set and configured to display instead of the file name, a declared document language, and XMP metadata identifying the file as PDF/UA.

Reliable text

Every character maps to Unicode, and no information is conveyed by visual appearance alone — assistive technology gets the same content a sighted reader sees.

Alternative text on figures

Meaningful images and figures carry alternative descriptions; graphics that carry no meaning are artifacts, not untagged noise.

Labeled, usable form fields

Interactive form fields have programmatic labels and tooltips, and security settings must never block assistive technology from reading the document.

Comparison

How does PDF/UA relate to WCAG?

They are complementary layers. WCAG defines outcome-level requirements for any web content — perceivable, operable, understandable, robust — while PDF/UA defines how the supporting structures must be implemented technically in the PDF format. A file can satisfy PDF/UA and still fail WCAG, for example on color contrast, so mature workflows verify both.

US and EU rules cite WCAG, not PDF/UA — but PDF/UA is how you engineer a PDF that meets WCAG's structural criteria dependably, and it is what serious procurement specifications name. DocoMatic remediates to both and scores every file against both.

WCAG 2.1 AA and PDF/UA-1 compared
AxisWCAG 2.1 AAPDF/UA-1
DefinesWCAG 2.1 AAOutcomes for any contentPDF/UA-1How the structures are built inside the PDF
Named by US and EU rulesWCAG 2.1 AAYesPDF/UA-1No — but routinely named in procurement
Machine-verifiableWCAG 2.1 AAPartlyPDF/UA-1Much of it — see the Matterhorn Protocol
Catches color contrastWCAG 2.1 AAYesPDF/UA-1No
Catches an incomplete tag treeWCAG 2.1 AAIndirectly, through 1.3.1PDF/UA-1Yes

Machine or human

What is the Matterhorn Protocol?

The Matterhorn Protocol is the PDF Association's testing model for PDF/UA-1. It decomposes the standard into 31 checkpoints comprising 136 discrete failure conditions, and classifies each condition as machine-verifiable or as requiring human judgment. Checkers implement the machine-verifiable set; human reviewers work through the rest.

That split is the honest map of what automation can and cannot prove: a tool can verify that a table has header cells, but only a person can confirm the headers are the right ones. Any vendor claiming a fully automated 'compliance guarantee' is ignoring the protocol's own taxonomy.

The protocol's split by area, with failure-condition IDs
AreaWhat a machine settlesWhat only a person settles
Tag treeWhat a machine settlesEverything tagged or artifacted; nesting valid; no heading level skipped (01-005, 09-004, 14-003)What only a person settlesWhether the tags fit the content and the headings are the real headings (01-006, 09-003, 14-001)
Reading orderWhat a machine settlesPages with annotations declare a tab order (28-008, 28-009)What only a person settlesWhether the tag order is the logical reading order (09-001)
TablesWhat a machine settlesStructure well formed; every header cell has a scope (09-004, 15-003)What only a person settlesWhether row and column header cells are tagged as headers — the right ones (15-001, 15-002, 15-005)
FiguresWhat a machine settlesEvery Figure has alternative text (13-004)What only a person settlesWhether a graphic is content or decoration, and its description the right kind (01-001, 13-001, 13-007)
FormsWhat a machine settlesEvery field has a tooltip; widgets sit in Form tags (28-005, 28-010)What only a person settlesWhether fields sit in reading order; whether a print-only form is tagged as one (28-001, 24-001)
MetadataWhat a machine settlesXMP with PDF/UA identifier and title; title displays; language declared (06-001–003, 07-001, 11-001)What only a person settlesWhether the title identifies the document and the language is right (06-004, 11-007)
TextWhat a machine settlesEvery character maps to Unicode; every font embedded (10-001, 31-009)What only a person settlesWhether OCR text is actually correct (08-001)

Classification: the protocol's. Grouping by area: ours.

What we do with it: every remediated file is checked with veraPDF(opens in new tab) against PDF/UA-1 — from Level 2 up it must pass with zero failures, or the document is not charged — and the verification report lists what machines could not verify, for human review.

Validators

How do you check a PDF against PDF/UA?

Two free tools dominate. PAC (PDF Accessibility Checker) validates the machine-checkable Matterhorn conditions and previews the document the way assistive technology encounters it. veraPDF is an open-source validator, built originally for PDF/A, that also validates PDF/UA. A clean machine report is necessary but not sufficient — human checks complete the assessment.

DocoMatic runs machine verification on every remediated file and attaches the report, so a PAC or veraPDF re-check by your auditor reproduces the same result — verification you can forward, not a promise.

veraPDF is also the validator our own billing is measured against: from Level 2 up, a remediated file must pass its PDF/UA-1 validation with zero failures or you are not charged for it. We did not write it and we cannot tune it — which is the point.

Legal status

Is PDF/UA legally required?

No US or EU rule requires PDF/UA by name. ADA Title II, the HHS Section 504 rule and Section 508 cite WCAG; so do EN 301 549 under the European Accessibility Act and Ontario's AODA.

It is named in procurement specifications constantly, because it is the testable, PDF-specific way to deliver what those rules require of a document.

The plan

How do you get a document library to PDF/UA?

Inventory your documents, then remediate to PDF/UA and WCAG 2.1 AA in the same pass — the tagging work is shared, and together they satisfy US regulatory standards and procurement specs at once. Verify each file by machine, review flagged files by hand, and keep the per-file reports as your evidence trail.

  1. Inventory: enumerate the PDFs on your public domains and rank them by use.

  2. Remediate: build complete tag structures, mark artifacts, set metadata, map text to Unicode.

  3. Verify: run PAC-equivalent machine checks on every file and keep the report.

  4. Review: route files with human-judgment conditions — complex tables, forms, figures — to human review.

FAQ

PDF/UA questions, answered

Buying for a larger organization?

Book a 20-minute demo(opens in new tab)

Is PDF/UA legally required in the US?

The US rules — ADA Title II, HHS Section 504, Section 508 — cite WCAG, not PDF/UA. But PDF/UA is routinely named in procurement specifications and policies because it is the testable, PDF-specific way to deliver what WCAG requires of a document. Remediating to both is standard practice.

Is a tagged PDF automatically PDF/UA conformant?

No. Tagging is necessary but nowhere near sufficient: the tags must be complete and semantically correct, decorative content must be artifacted, the title must display, the language must be set, every character needs a Unicode mapping, and form fields need labels. Many 'tagged' PDFs fail dozens of Matterhorn conditions.

If PAC reports zero errors, is the document accessible?

It has passed the machine-verifiable conditions — the floor. The Matterhorn Protocol explicitly reserves conditions for human judgment: whether the reading order makes sense, whether alt text is accurate, whether table headers are the right ones. A clean PAC report plus targeted human review is the defensible combination.

What is PDF/UA-2 and do I need it?

PDF/UA-2 (ISO 14289-2, 2024) applies the standard to the newer PDF 2.0 format and modernizes the tagging model. Adoption in tools and procurement is still early; for today's compliance and procurement needs, PDF/UA-1 remains the profile to target and verify against.

Can a scanned PDF become PDF/UA conformant?

Yes, after real work: OCR must produce an accurate, Unicode-mapped text layer, and the file then needs full tagging, artifacts, metadata and — where figures carry meaning — alternative text. An image-only scan conforms to nothing; recognition plus structured remediation is what turns it into a conforming document.

Sources

Every regulatory claim on this page is cited to one of these primary sources.

Changelog

  1. Matterhorn and WCAG tables; veraPDF relationship; legal-requirement section; hub, guide, scanner and product links; ISO 14289 sources.
  2. Initial publication.

Reviewed quarterly, and whenever a cited source changes. Next review: December 18, 2026.