Matterhorn 06-002 · PDF/UA-1 UA1:5
PDF/UA identifier missing from the XMP metadata
The PDF/UA identification schema (pdfuaid:part) is absent, so the file does not actually claim PDF/UA-1 conformance even if it meets every other requirement. Taggart does not write the identifier as a batch fix: it is a claim of conformance, and it is written only through the conformance-claim step, which refuses unless re-validation of the output finds no blockers.
The condition, as the protocol states it. “The XMP metadata stream in the Catalog dictionary does not include the PDF/UA identifier.”
Matterhorn Protocol 1.1, checkpoint 06, index 06-002, section UA1:5. Software can decide this one on its own.
What a screen reader actually does
No direct effect. This is the machine-readable conformance claim that validators and procurement checks look for.
What is in the file
The Catalog dictionary has a /Metadata entry pointing at an XMP packet — an XML document embedded in the PDF as an uncompressed stream. ISO 14289-1 clause 5 requires that packet to carry the PDF/UA identification schema:
<rdf:Description rdf:about=""
xmlns:pdfuaid="http://www.aiim.org/pdfua/ns/id/">
<pdfuaid:part>1</pdfuaid:part>
</rdf:Description>Three things can be wrong, and Taggart distinguishes them:
No /Metadata at all. Common in files produced by older libraries and by anything that assembles pages programmatically. There is nowhere to put the identifier.
A metadata stream with no pdfuaid namespace. The overwhelmingly common case. Word, InDesign and LaTeX all write a perfectly good XMP packet with dc:, xmp: and pdf: schemas in it, and none of them write pdfuaid unless explicitly asked.
A pdfuaid:part with the wrong value or the wrong namespace URI. Rarer, and usually the result of hand-editing. The namespace is http://www.aiim.org/pdfua/ns/id/ — with the trailing slash, and AIIM rather than ISO, because AIIM held the registry when the schema was defined.
Why a validator cares about a claim
PDF/UA-1 is a conformance standard, and conformance standards work by declaration. The file states what it claims to be; the validator holds it to that claim. Without the declaration there is nothing to validate against — a PDF with no identifier is simply a PDF, and every structural requirement in ISO 14289-1 is inapplicable to it.
This is why the identifier is a blocker rather than a warning, despite having no effect on any screen reader. It is the difference between a document that is accessible and a document that says it is accessible. Procurement asks for the second.
The practical consequence is narrow and sharp: a file with no identifier cannot pass veraPDF’s PDF/UA-1 profile, regardless of how good its tagging is. It fails at the first clause and stops. If a buyer’s acceptance criterion is “passes veraPDF”, this one missing element fails the whole submission.
What the user hears
Nothing. No assistive technology reads the XMP packet, and no reading behaviour changes when the identifier is added or removed.
That fact is worth stating plainly, because it is the strongest argument against treating PDF/UA conformance as the goal rather than the evidence. A file can carry the identifier, pass veraPDF cleanly, and still be unusable — reading order scrambled, alt text that says image, tables with no headers. The identifier is the last step of a process, and on its own it certifies nothing.
How to check it free
veraPDF (open source, all platforms) is the reference implementation and reports this directly:
Specification: ISO 14289-1:2014
Clause 5, Test number 1
The document catalog shall include an XMP metadata stream
containing the PDF/UA identification schemaCommand line, no tools installed. The XMP packet is stored uncompressed by convention, so grep finds it:
grep -a pdfuaid document.pdfA match means the schema is present — it does not confirm the part number or the namespace. No match means it is definitely absent.
Acrobat Pro will not tell you. Its Accessibility Check has no test for clause 5. File → Properties → Additional Metadata → Advanced shows the packet’s schemas, and the PDF/UA one appears there if present, but you have to go and look.
How to fix it free, in Acrobat Pro
Acrobat Pro’s preflight is the free route that exists:
Print Production → Preflight(or Ctrl+Shift+X).- Switch to the PDF standards profiles and find the PDF/UA-1 fixups.
- Run Set PDF/UA-1 entry. It writes the identification schema and nothing else.
Save afterwards, then re-run your validator — the fixup writes the claim, and the claim is what makes every other failure visible.
Upstream: Word and InDesign do not write the identifier on export at any setting. Ghostscript does not. pikepdf and veraPDF’s own tooling will, if you ask. In practice almost every file needs this applied after production.
Where Taggart differs
Taggart will not write the identifier as part of a batch at all, and this is the one condition it deliberately leaves in the findings list.
The reason is the answer to the first question above. The identifier is a claim, and a tool that writes claims unattended is making them on your behalf. So it sits behind a separate step — write the PDF/UA identifier if re-validation is clean — which runs after the fixes, re-checks the output Taggart itself just produced, and refuses if any blocker survived:
conformance was requested but re-validation found 3 blocker(s); the PDF/UA identifier was not written
That refusal is in the remediation report, which means the file’s history records that a claim was requested and declined, not merely that it is absent.
Where Taggart does write metadata unattended is the packet itself. xmp-metadata creates a missing XMP stream and repairs a damaged one, and it repairs rather than replaces. An existing XMP stream usually carries dc:title, dc:language and production history that other tools depend on; a fix that overwrites the packet to add six lines destroys all of it. Taggart parses the RDF, adds the pdfuaid description if it is missing, corrects the part number if it is wrong, and leaves every other schema untouched.
Where there is no packet at all, it writes a minimal one carrying the identifier plus dc:title and dc:language taken from the document’s own dictionary — so 06-002 and 06-003 are resolved together rather than one at a time.
How Taggart handles it
Taggart detects this condition automatically. It is reported as a blocker, with the page, the structure path and the object id of every occurrence.
Whatever Taggart changes, the page still looks identical. Fixes edit the PDF object model, not the content streams, and every remediation is re-rendered and compared against the original at structural similarity ≥ 0.999 before you get the file back. A tool that quietly reflows your document is worse than no tool.
Frequently asked questions
Does adding the identifier make my file conformant?
No, and this is the one thing to understand about it. The identifier is a claim, not a certificate. Adding it to a file with untagged content produces a file that claims PDF/UA-1 and fails PDF/UA-1 — which is worse than one that claims nothing, because a validator will now hold it to the standard and report every failure. Add it last, after the structural work.
Which part number do I use?
pdfuaid:part is 1 for PDF/UA-1 (ISO 14289-1). PDF/UA-2 (ISO 14289-2, published 2024) uses 2 and is a different standard built on PDF 2.0. If your target is PDF/UA-1, the value is 1.
Acrobat's Accessibility Check passes but veraPDF fails. Why?
Acrobat's checker does not test for the identifier at all — it tests the structure. veraPDF validates against the ISO standard, and clause 5 of ISO 14289-1 requires the identification schema. This is the single most common disagreement between the two tools, and veraPDF is right.
Can I add it in Acrobat?
Not through the interface. Acrobat's File → Properties writes document information and dc: metadata, not the pdfuaid schema. The usual free route is Acrobat's preflight (Print Production → Preflight → PDF/UA fixups) in Acrobat Pro, or editing the XMP packet directly with a script.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint 06 (Metadata), index 06-002 |
| PDF/UA-1 (ISO 14289-1) | Clause 5 |
Related conditions
- 06-001 Document does not contain an XMP metadata stream The catalog has no /Metadata entry pointing at an XMP packet. PDF/UA-1 requires one — it is where the conformance claim and the document title live.
- 06-003 XMP metadata stream does not contain dc:title The Dublin Core title property is missing from the XMP packet.
- 07-001 ViewerPreferences does not contain DisplayDocTitle Without /DisplayDocTitle the viewer is free to show the filename in the window title instead of the document title.
- 02-001 Non-standard tag mapping does not terminate with a standard type A custom tag name is present in the role map but the chain of mappings never arrives at a structure type defined in ISO 32000-1, 14.8.4. Mapping may be indirect — a custom type may map to another custom type — but it must eventually terminate.
Other conditions in checkpoint 06
Checkpoint 06 covers metadata. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.
- 06-001 Document does not contain an XMP metadata stream The catalog has no /Metadata entry pointing at an XMP packet. PDF/UA-1 requires one — it is where the conformance claim and the document title live.
- 06-003 XMP metadata stream does not contain dc:title The Dublin Core title property is missing from the XMP packet.
- 06-004 dc:title does not clearly identify the document A title is present but useless: the filename, "Microsoft Word - Document1", "untitled", or the template name.
Check your own file. Taggart’s validator is free and unlimited — every machine-checkable Matterhorn condition, no page cap, no watermark, no account needed.
Verified against a real document on . Last updated .