Matterhorn 06-003 · PDF/UA-1 UA1:7.1-8
No dc:title, so the reader announces the filename
The Dublin Core title property is missing from the XMP packet.
The condition, as the protocol states it. “XMP metadata stream does not contain dc:title.”
Matterhorn Protocol 1.1, checkpoint 06, index 06-003, section UA1:7.1-8. Software can decide this one on its own.
What a screen reader actually does
The reader announces the filename instead of the document's name — "Untitled", or "final-v3-REALLY-FINAL.pdf".
What is in the file
Two entries, in two different places, and a document needs all of both.
The title, as dc:title in the XMP metadata packet:
<dc:title><rdf:Alt><rdf:li xml:lang="x-default">Annual report 2025</rdf:li></rdf:Alt></dc:title>The instruction to show it, as /DisplayDocTitle true in the Catalog’s /ViewerPreferences — which is condition 07-001 when it is missing and 07-002 when it is explicitly false.
This condition is the first of the two. The packet exists — that is 06-002’s territory — and the Dublin Core title property is not in it.
What the user hears
The filename, on open, as the window or tab title:
final-v3-REALLY-FINAL.pdf
Microsoft Word - Q3 board pack (2) copy.docx
That is the first thing announced about the document and the label the person has for it for as long as it stays open. It is also what appears when they alt-tab, what a reading list shows, and what gets read back when they are asked which document they are in.
A filename is not a neutral substitute for a title. It frequently carries drafting history the author never meant to publish — a version number, an initial, the word draft, the name of the person it was prepared for. Somebody reading with their eyes sees that in a window chrome they can ignore. Somebody listening is told it, first, every time.
Where it comes from
Word takes the title from File → Info → Title, which is blank by default and which almost nobody fills in. It does not use the first heading and it does not use the filename.
InDesign takes it from File → File Info → Document Title.
LaTeX needs \hypersetup{pdftitle={...}}; \title{} alone sets the typeset title on the page and nothing in the metadata.
Anything that assembles pages programmatically — merge tools, report generators, scan pipelines — writes no title unless told to, and there is usually nowhere in the interface to tell it.
A document that had one and lost it. Any tool that rewrites the XMP packet rather than editing it will drop every property it does not understand. This is the quiet one, because the title was right when somebody checked.
How to check it free
Open it and listen, or just look at the window title. If it says the filename, one of the two entries is missing. This takes one second and needs nothing.
Acrobat Pro: File → Properties → Description shows the title from the info dictionary; Additional Metadata → Advanced shows the XMP packet where dc:title actually lives. They can disagree, and when they do the XMP one is what the standard cares about.
Command line, since the packet is stored uncompressed by convention:
grep -a 'dc:title' document.pdfveraPDF reports it against clause 7.1 and distinguishes it from the viewer-preference conditions, which is the distinction that tells you which half is missing.
How to fix it free, in Acrobat Pro
File → Properties→ Description tab → type a Title.File → Properties→ Initial View tab → Window Options → Show: Document Title.- Save.
Step 1 without step 2 changes nothing that anyone hears. Acrobat’s Accessibility Check reports the pair together as Title — Failed and its right-click Fix does both and prompts for the string, which is the fastest route.
Upstream is better, because a title set in the source survives every re-export: Word’s File → Info → Title, InDesign’s File → File Info, LaTeX’s \hypersetup{pdftitle={...}}.
Where Taggart differs
document-title is not a safe fix and never runs from a batch. Everything else in the mechanical set changes structure that already exists; this one writes a sentence into the document that a person will hear read aloud, and only the author knows what the document is called.
So Taggart proposes and shows its working:
No dc:title. Candidates: the info dictionary holds “Q3 board pack” · the first H1 reads “Third quarter results” · the filename is “AR-2025-final-v3.pdf”.
Three candidates with their provenance, and none of them written until somebody picks one. The remediation report records which was chosen and who chose it, because a document title is a claim about what the document is and the audit trail is the reason this product exists.
It also reports this alongside 07-001 rather than separately when both are missing, since fixing one without the other achieves nothing audible and a report that lists them as two unrelated items invites exactly that.
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.
The fix is Set the document title. It changes what the document means, so Taggart proposes it and waits for your approval rather than applying it unattended.
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
Is this the same as the title in File → Properties?
They are supposed to be the same string in two places. Acrobat's Description tab writes the document information dictionary, and a well-behaved producer mirrors it into the XMP packet as dc:title. PDF/UA-1 requires the XMP one, because XMP is the metadata model PDF 2.0 keeps and the info dictionary is the one it deprecates.
I set a title and the reader still says the filename.
Then DisplayDocTitle is missing or false. The title and the instruction to show it are two separate entries and each is useless without the other — a document with a perfect dc:title and no DisplayDocTitle announces the filename exactly as if it had no title at all.
What makes a good title?
What the document is, as a person would say it aloud: "Annual report 2025", not "AR-2025-final-v3" and not "Microsoft Word - AR2025.docx". It is announced on open and it is what appears in a list of open windows, so it has to distinguish this document from the others someone has in front of them.
Can a tool write it for me?
It can copy one from somewhere — the info dictionary, the first heading, the filename. It cannot know what the document is called. Taggart proposes a candidate and shows where it came from; it will not write a guess unattended, because a wrong title is announced with exactly as much confidence as a right one.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint 06 (Metadata), index 06-003 |
| PDF/UA-1 (ISO 14289-1) | Clause 7.1-8 |
| WCAG 2.1 | 2.4.2 Page Titled — Level A |
| EN 301 549 / Section 508 / ADA Title II | All three point at WCAG 2.1 Level AA for non-web documents, so a Level A or AA criterion here is in scope for each of them. |
Related conditions
- 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.
- 07-002 DisplayDocTitle is false The entry is present and explicitly instructs the viewer to show the filename rather than the title.
- 06-002 XMP metadata does not include the PDF/UA identifier 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.
- 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.
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-002 XMP metadata does not include the PDF/UA identifier 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.
- 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 watermark, no expiry, and no account needed up to 60 pages.
Verified against a real document on . Last updated .