PDF/A and PDF/UA sound similar and are often confused, but they solve different problems. PDF/A is about preservation — making a file that will still open and look the same decades from now. PDF/UA is about accessibility — making a file that assistive technology can read and navigate. A document can conform to one, the other, both, or neither, and for many organizations the right answer is both at once.
This guide explains what each standard is, where they overlap, why some documents need to satisfy both, and how to produce a file that does. It complements our WCAG 2.2 and PDF/UA accessible PDF guide.
What PDF/A is: archiving and long-term preservation
PDF/A is ISO 19005, the standard for the long-term archiving of electronic documents. Its goal is reliable preservation: a PDF/A file should render identically in the future without depending on anything outside the file itself.
To achieve that, PDF/A requires a document to be self-contained and forbids anything whose meaning could drift over time. In practice that means:
- All fonts are embedded, so text renders correctly even if the original fonts no longer exist on the viewer's system.
- No external dependencies — no links to external content, no reliance on fonts, color profiles, or media stored outside the file.
- No features that aren't preservation-safe — encryption, JavaScript, audio/video, and other dynamic content are disallowed because they can't be guaranteed to behave consistently in the long run.
- Device-independent color through embedded color profiles, so colors are reproduced faithfully anywhere.
PDF/A is not an accessibility standard. A perfectly valid PDF/A file can be completely inaccessible — a scanned image with embedded fonts and a color profile is still just a picture to a screen reader. Archiving and accessibility are orthogonal concerns.
What PDF/UA is: accessibility
PDF/UA is ISO 14289, the standard for universally accessible PDFs. Where WCAG defines what accessibility means at the content level, PDF/UA defines how it's implemented inside a PDF file: a complete and correct tag tree, a logical reading order, alternative text for meaningful images, properly structured tables and forms, document metadata including a title and language, and the absence of traps that confuse assistive technology.
There are two editions. PDF/UA-1 (ISO 14289-1) was published in 2014 and is based on PDF 1.7. PDF/UA-2 (ISO 14289-2) was published in March 2024 and is based on PDF 2.0 (ISO 32000-2); we cover the differences in PDF/UA-1 vs PDF/UA-2. Conformance is commonly tested against the PDF Association's Matterhorn Protocol, a set of checkpoints and failure conditions.
Where they overlap: the "accessible" conformance levels of PDF/A
The two standards aren't entirely separate, and that's the source of much of the confusion. PDF/A defines conformance levels, and the level suffixed "a" — for accessible — requires the document to be tagged with structure information:
| PDF/A version | "a" conformance level | Tagging required? |
|---|---|---|
| PDF/A-1 (based on PDF 1.4) | PDF/A-1a | Yes — tagged, structured |
| PDF/A-2 (based on PDF 1.7) | PDF/A-2a | Yes — tagged, structured |
| PDF/A-3 (allows embedded files) | PDF/A-3a | Yes — tagged, structured |
The other PDF/A levels — the "b" (basic) levels like PDF/A-1b, and the "u" (Unicode text) levels — preserve visual fidelity but do not require tagging. So a PDF/A-1b file is archivable but not necessarily accessible, while a PDF/A-1a file carries the structural tagging that accessibility depends on.
It's important not to overstate this overlap. The "a" levels require tagging, which is necessary for accessibility, but they don't enforce the full set of accessibility requirements that PDF/UA does (correct reading order verified, alt text quality, form labeling, and so on). Tagged-PDF/A is a strong foundation for accessibility, not a guarantee of it — which is exactly why a document may need to meet PDF/UA explicitly in addition.
Why a document may need to satisfy both
Plenty of documents have to be preserved and be accessible. The clearest example is government records: an agency may be legally required to archive a document for the long term (pointing to PDF/A) while also being required to make it accessible to people with disabilities under laws like Section 508 (pointing to PDF/UA).
Neither standard alone satisfies both obligations:
- A PDF/A-1b file meets the archiving requirement but isn't accessible.
- A PDF/UA file is accessible but, on its own, makes no archiving guarantees about embedded fonts and external dependencies.
When both obligations apply, you need a file that's archivable and accessible. That's where the two standards are designed to be combined.
How to produce a file that conforms to both
The good news is that PDF/A and PDF/UA are largely compatible, and the constraints of one don't conflict with the other — a tagged, self-contained file can satisfy both. The practical recipe:
- Start from a structured source. Author the document with real headings, lists, tables, and alt text — accessibility is far cheaper to build in than to retrofit. A scan-and-OCR workflow makes both standards harder to hit.
- Tag the document fully and correctly. This serves the PDF/UA requirements and the "a"-level PDF/A requirement at the same time: a complete tag tree, logical reading order, alt text, structured tables and forms.
- Export to a tagged PDF/A level — the "a" conformance level (for example PDF/A-2a), so the file is both archivable and tagged. Choosing a "b" level here would forfeit the tagging that accessibility needs.
- Embed everything and remove disallowed features. Embed all fonts and color profiles, and strip out anything PDF/A forbids (encryption, JavaScript, external references).
- Set the metadata. A document title, a declared language, and the conformance claims belong in the metadata; both standards rely on it.
- Validate against both. Run a PDF/A validator and a PDF/UA checker built on the Matterhorn Protocol. Passing one does not imply passing the other, so check both and remediate anything either flags.
Because the requirements interlock — tagging satisfies part of both, embedding satisfies PDF/A without harming PDF/UA — producing a single file that conforms to both is realistic, not a compromise. The order that matters most is doing the structural work early.
Key takeaways
- PDF/A (ISO 19005) is for long-term archiving: self-contained files, embedded fonts, no external dependencies, no preservation-unsafe features. It is not an accessibility standard.
- PDF/UA (ISO 14289) is for accessibility: it defines how tagging, reading order, alt text, tables, forms, and metadata are implemented inside the file.
- They overlap at PDF/A's "a" conformance levels (PDF/A-1a, 2a, 3a), which require tagging — necessary for accessibility, but not the same as full PDF/UA conformance.
- Documents such as government records often must be both archived and accessible, and neither standard alone covers both obligations.
- A single tagged, self-contained file can conform to both — export to a tagged PDF/A "a" level, embed everything, set the metadata, and validate against both a PDF/A and a Matterhorn-based PDF/UA checker.
