Matterhorn 06-004 · PDF/UA-1 UA1:7.1-8

A PDF title that names nothing: Document1, the filename

A title is present but useless: the filename, "Microsoft Word - Document1", "untitled", or the template name.

What a screen reader actually does

The reader announces a title that tells the user nothing about which document they have opened.

What the condition is

PDF/UA-1 wants the document’s title in the XMP packet as dc:title, and an instruction to the viewer to show it. A missing title is 06-003; a missing or false instruction is 07-001 or 07-002. Software can decide all three. This one it cannot: the title is there, well-formed, displayed, and says nothing about which document this is.

<dc:title>
  <rdf:Alt><rdf:li xml:lang="x-default">Microsoft Word - Document1</rdf:li></rdf:Alt>
</dc:title>

A file can carry the title twice, the second copy in the document information dictionary, and that copy matters more than it looks: the PDF specification describes DisplayDocTitle as showing the /Title entry of that dictionary, so it is the one a viewer’s title bar is expected to use.

<< /Title (Microsoft Word - Document1)
   /Producer (...)
>>

The protocol marks this as human judgement because “does this identify the document” is a question about what the document is for, and the file cannot answer it about itself.

What the user hears

When the file opens, a screen reader reads the window title. With DisplayDocTitle set that is the document title, so the first thing anyone is told about this document is:

Microsoft Word - Document1

or Untitled-1, or final_report, or q3-board-pack. Then the same string again whenever they switch windows, ask which document has focus, or choose from a list of open files. Ten reports made from one template, each still carrying the template’s title, are ten identical lines in that list.

A sighted reader ignores the title bar and reads the cover. A screen-reader user gets the title first and has to go into the document to find out what it is. On every document, every time it is opened.

Where these titles come from

Printing to PDF. A PDF printer driver typically takes the title from the print job, and the print job is named after the application and the file: Microsoft Word - Q3 board pack.docx.

A property nobody updated. Word and InDesign keep the title as a document property, separate from anything on the page. Start this year’s report from a copy of last year’s and the title still names last year. Start from a template and the document can carry the template’s title forward.

Conversion and scanning tools that fill the title with the filename, because the filename is the only name they have.

A placeholder typed to get past a checker. Title, Document, PDF. Any string satisfies a presence check, so some people type any string.

How to check it free

Read it out of context. Look at the window or tab title with the file open, or run pdfinfo report.pdf (Poppler, free), which prints the information-dictionary title on its Title: line. pdfinfo -meta report.pdf prints the XMP packet with dc:title in it. The two can disagree, and something reads each of them.

Then ask the one question this condition has: if this were one line in a list of twenty open windows, would you know which document it is? Would next year’s edition get a different title, or the same one?

In Acrobat Pro the title is under Document properties → Description. Two things to know first. Adobe describes the Accessibility Checker’s Title rule as reporting whether there is a title in the title bar, so a placeholder passes it. And Acrobat has a preference, Preferences → Documents → Always use filename as document title, off by default; if it is on in your copy, the window shows the filename whatever the file says, so read the property rather than the window (Adobe: viewing preferences).

veraPDF tests that dc:title exists. It does not read it, and no validator could.

How to fix it free, in Acrobat Pro

From Adobe’s guide to checking accessibility:

1. The hamburger menu (Windows) or the File menu (macOS) → Document properties.
2. Description → type the title in the Title box.
3. Initial View → Show → Document Title.
4. OK, and save.

Or from the Accessibility Checker: select Title, choose Fix from the options menu, and enter the title in the Description dialog, deselecting Leave As Is if it is ticked.

A title set in the source survives the next export, which one set in Acrobat does not: File → Info → Title in Word, File → File Info → Document Title in InDesign, \hypersetup{pdftitle={...}} in LaTeX.

What Taggart does

Taggart applies a heuristic, and it is worth knowing exactly what it is, because a heuristic you cannot see is a verdict you cannot argue with. It reads dc:title, falling back to the information-dictionary title when the packet has none, and reports the title when it:

• begins Microsoft Word - or Microsoft PowerPoint -;
• begins Untitled;
• is Document or Presentation, alone or with a number straight after, as in Document1;
• ends in .pdf, .doc, .docx, .ppt, .pptx, .indd or .qxd;
• begins with final, draft or copy of followed by a space, hyphen or underscore;
• is the filename, with or without its extension;
• is shorter than four characters.

The finding quotes the title, and its evidence records which test matched:

The document title ‘Microsoft Word - Document1’ does not clearly identify the document.

It is a warning rather than a blocker, and it goes to the review queue, where you can accept the title as it is (with a justification, which is printed in the report), mark it as needing work, or leave it for later.

What the heuristic does not catch is everything else. Microsoft Excel - Book1 passes, because only Word and PowerPoint are on the list. AR-2025-final-v3 passes, because final is not at the start. A real title naming the wrong year passes, and so does a template’s name. Those are the cases this condition exists for, and they need a person.

The repair is document-title, which never runs in Fix All Safe. In the app you tick Set the document title and type; the field starts with the title the document already has, which here is the one being flagged, so the job is to replace it. Taggart writes what you type to both dc:title and the information dictionary’s /Title, so the two cannot drift apart. Given no title, it changes nothing and says why:

a title must be supplied; Taggart does not invent document titles

Taggart does compute a candidate from the document itself, from its first top-level heading or, failing that, the largest short line on page one when it is set larger than the body text, and the app puts it in the field when a document has no title at all (06-003). Where a title exists, as here, the field holds that title rather than Taggart’s guess.

How Taggart handles it

The protocol marks this condition as needing human judgement, so no validator can decide it outright. Taggart applies a heuristic to find the likely cases and reports each one as warning for you to settle in the review queue. A heuristic finds what it was built to find and can miss the rest; what this one looks for is described above.

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.

Where this sits in the standards

Related conditions

• 06-003 XMP metadata stream does not contain dc:titleThe Dublin Core title property is missing from the XMP packet.
• 07-001 ViewerPreferences does not contain DisplayDocTitleWithout /DisplayDocTitle the viewer is free to show the filename in the window title instead of the document title.
• 07-002 DisplayDocTitle is falseThe entry is present and explicitly instructs the viewer to show the filename rather than the title.
• 11-006 Natural language for document metadata cannot be determinedThe XMP dc:title (and other metadata) has no xml:lang and the catalog has no /Lang.

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 streamThe 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 identifierThe 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-003 XMP metadata stream does not contain dc:titleThe Dublin Core title property is missing from the XMP packet.

Checked with Taggart on a generated file that fails this condition on 2026-10-02. The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated 2026-10-10.