Matterhorn 19-003 · PDF/UA-1 UA1:7.9-2

Note tag with no ID: why every footnote needs one

Every Note element must carry an /ID so references can point at it.

What a screen reader actually does

The reader cannot offer "jump to note" and back.

What is in the file

Any structure element may carry an ID, a string that names it. PDF/UA-1 makes it mandatory for one type: every Note must have one. The structure tree root keeps an index from IDs to elements, the IDTree, which ISO 32000-1 requires as soon as any element has an ID:

1 0 obj
<< /Type /StructTreeRoot
   /K [ 9 0 R ]
   /IDTree << /Names [ (fn1) 41 0 R  (fn2) 44 0 R ] >>
>>
endobj

41 0 obj
<< /Type /StructElem /S /Note /P 9 0 R /Pg 3 0 R
   /ID (fn1)
   /K [ 22 ] >>                    % "1 Ministry of Finance, Annual Budget Report 2025, p. 14."
endobj

The condition is a Note with no /ID entry. An /ID () — present, empty — fails it too.

What it costs

Nothing a listener hears directly, and it is better to say so than to dress it up. The ID is bookkeeping: it is what makes a note identifiable as this note rather than a note, for anything that wants to name it — a tool building a list of notes, a converter turning footnotes into linked endnotes, a remediator checking that every marker has a note to point at.

PDF 1.7 does not make references point at notes by ID; a footnote marker usually reaches its note through a link to a position on the page. PDF/UA-1 requires the ID anyway, so that the note can be identified, and because the requirement is machine-checkable it is a hard failure. A file with one ID-less note does not conform.

Where it comes from

Retagging to Note after the fact. Changing a paragraph’s type to Note — the fix for 19-001 — is a change of type. The ID is a separate entry, and unless whatever made the change also wrote one, the note arrives without it. This condition is often the immediate result of fixing the previous one.

Producers that tag notes but skip the ID. The tag is the visible part; the ID is a separate key that a producer has to know to write.

Notes written by hand into the tree, with New Tag, which asks for a type and a title.

How to check it free

veraPDF. Its PDF/UA-1 rule set has rule 7.9-1 for exactly this — a Note’s ID must be neither missing nor empty — and reports each failing note.

PAC reports it among its PDF/UA checks as well.

Not Acrobat’s Accessibility Checker. It has no rule about notes in Adobe’s list of its checks, so a file can pass Acrobat’s full check and fail this.

Reading the objects. qpdf --qdf --object-streams=disable in.pdf plain.pdf and search for /S /Note: each hit’s dictionary either has an /ID line or does not.

How to fix it free

This is where the free route is thinnest.

In Acrobat Pro, Adobe’s Tags panel guide takes you to the right place — select the <Note>, choose Properties from the Options menu, and the Object Properties dialog opens on its Tag tab — but the fields it documents there are the type, the title, alternate text and attribute objects. It does not document an ID field. Remediators report that the Tag tab in current versions has an ID box that writes this entry; we have not been able to confirm that from Adobe’s documentation, so treat it as something to try on a copy and verify with veraPDF afterwards, not as a documented step.

If the notes come from a source document, re-exporting fixes this only if the producer writes IDs — check one note in the output with veraPDF before relying on it.

Where Taggart differs

Taggart checks every element whose type resolves to Note, through the role map, and reports each one without an ID — or with an empty one — at its structure path:

<Note> has no /ID entry, so a <Reference> cannot point at it.

The repair is Assign unique Note IDs (note-ids), which is in “Fix All Safe”: there is one right answer, and it changes nothing a reader sees or hears. It gives each note that lacks an ID the next free name in the series taggart-note-1, taggart-note-2, skipping any name already in use, leaves every note that already has a unique ID alone, and rebuilds the IDTree from all the IDs in the structure tree. The change log names each one:

page 1 StructTreeRoot[0]/Document[0]/Note[1]: set <Note> /ID to ‘taggart-note-1’

The names are generic. Taggart does not read the marker on the page to choose one — it may say 3, or †, or be missing — and a serial number makes no claim about the note that could turn out to be wrong.

If notes are being retagged with Taggart’s own Tag notes and references repair, each new Note gets an ID as it is made, so this condition does not follow from that repair.

How Taggart handles it

Taggart checks for this condition automatically and reports it as a blocker, with where in the file it found it.

The fix is Assign unique Note IDs. It is mechanical, so “Fix All Safe” applies it along with the others in one pass and lists what it changed. Your original file is never modified.

Where this sits in the standards

Related conditions

• 19-004 ID entry of the Note tag is non-uniqueTwo or more Note elements share an /ID, usually because a template was copied per page.
• 19-001 Footnotes or endnotes are not tagged as NoteFootnote text at the bottom of the page is tagged as an ordinary paragraph.
• 19-002 References are not tagged as ReferenceThe in-text citation marker is not tagged as a Reference pointing at the note.

Other conditions in checkpoint 19

Checkpoint 19 covers notes and references. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

• 19-001 Footnotes or endnotes are not tagged as NoteFootnote text at the bottom of the page is tagged as an ordinary paragraph.
• 19-002 References are not tagged as ReferenceThe in-text citation marker is not tagged as a Reference pointing at the note.
• 19-004 ID entry of the Note tag is non-uniqueTwo or more Note elements share an /ID, usually because a template was copied per page.

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-02.