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

Duplicate Note IDs: two footnotes, one identifier

Two or more Note elements share an /ID, usually because a template was copied per page.

What a screen reader actually does

Jumping to a note lands on the wrong one.

What is in the file

Every Note carries an /ID (condition 19-003), and the structure tree root indexes them in its IDTree, a name tree from each ID to its element. A name tree has one value per key. Two notes with the same ID are two elements claiming one key:

41 0 obj << /Type /StructElem /S /Note /ID (fn1) /K [ 22 ] … >>   % "1 Ministry of Finance, …"   page 3
88 0 obj << /Type /StructElem /S /Note /ID (fn1) /K [ 7 ]  … >>   % "1 See the 2024 audit, …"     page 11

/IDTree << /Names [ (fn1) 41 0 R  (fn1) 88 0 R ] >>               % one key, listed twice

ISO 32000-1 says an element’s ID must be unique among all the elements in the structure tree. PDF/UA-1 states the same requirement for notes in particular, and this condition is its failure.

What it costs

An identifier that does not identify. Anything that resolves fn1 — through the IDTree, or by walking the tree looking for it — gets one of the two notes, and which one depends on the software doing the looking. A tool listing the document’s notes by ID lists one. A converter that links markers to notes by ID can link two markers to the same note.

For a listener reading straight through, nothing changes: both notes are read where they sit. The risk usually given for this — a jump to a note landing on the wrong one — needs software that navigates notes by ID. The duplicate is machine-checkable, so whether or not anything in the reader’s path uses it today, the file fails validation on it.

Where it comes from

Joining documents. Each source was numbered fn1, fn2… on its own. After the join there are two of each, and nothing in the joining step had any reason to look at IDs.

Templates and copied pages. A tagged page with a note on it, used as the starting point for others, gives every copy the same note ID.

Repairs that assign a fixed ID. A script or a hurried hand edit that sets fn1 on each note it fixes, one at a time, produces one ID for all of them.

How to check it free

veraPDF has rule 7.9-2 for this in its PDF/UA-1 rule set: each Note must have a unique ID.

PAC reports it among its PDF/UA checks too.

Not Acrobat’s Accessibility Checker, which has no rule about notes in Adobe’s list of its checks.

Reading the objects. qpdf --qdf --object-streams=disable in.pdf plain.pdf, then search for /S /Note and collect the /ID values; any repeated value is this condition.

How to fix it free

As with 19-003, the free route runs into what Adobe documents. In Acrobat Pro, the Tags panel guide takes you to a note’s properties — select the <Note>, choose Properties from the Options menu — but the fields it documents on the Tag tab do not include an ID. Remediators report an ID box there in current versions; we could not confirm it from Adobe, so if you use it, do it on a copy and confirm the result with veraPDF.

Whatever you use, change the duplicates, not the first occurrence, unless you know which note anything else expects to find under the old ID. And give every note a new value that is unique across the whole tree, not only among notes.

Where Taggart differs

Taggart groups the document’s notes by ID and reports every repeat after the first, each at its own structure path, with the number of notes sharing it:

<Note> /ID ‘fn1’ is used by 3 note elements. Note IDs must be unique across the document.

It compares notes with notes. An ID shared between a Note and some other element is outside this check.

The repair is Assign unique Note IDs (note-ids), in “Fix All Safe”, the same one that fills missing IDs for 19-003. It walks the notes in tree order; each note whose ID is still shared when it is reached gets the next free name — taggart-note-1, taggart-note-2, skipping any already in use — and the walk moves on. By the time it reaches the last holder of a shared ID, that ID is no longer shared, so the last note keeps it and the earlier ones are renamed. A note whose ID was unique from the start is left alone. Then the IDTree is rebuilt from scratch, and the change log names every rename:

page 3 StructTreeRoot[0]/Document[0]/Note[1]: set <Note> /ID to ‘taggart-note-1’ (was ‘fn1’, which was not unique)

That is the reverse of the findings, which flag the second and later holders, and of the advice above. It makes no difference to a reader. It does to anything outside the file that already refers to fn1, and the old value in the change log is where to look if something does.

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-003 ID entry of the Note tag is not presentEvery Note element must carry an /ID so references can point at it.
• 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-003 ID entry of the Note tag is not presentEvery Note element must carry an /ID so references can point at it.

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.