Matterhorn 19-001 · PDF/UA-1 UA1:7.9-1

Footnotes tagged as paragraphs instead of Note

Footnote text at the bottom of the page is tagged as an ordinary paragraph.

What a screen reader actually does

The footnote interrupts the body text at the page break with no indication that it is a note.

What a footnote is in the tree

PDF has two standard structure types for this: Note, for the footnote or endnote itself, and Reference, for the marker in the text that points at it. Adobe’s list of standard PDF tags describes Note as explanatory text such as a footnote or endnote that the main text refers to. A footnote done properly looks like this:

/P   "…which the committee reviewed in March."
 └── /Reference
      └── /Link  "1"                ← the marker, condition 19-002
/Note  /ID (fn1)
      "1 Ministry of Finance, Annual Budget Report 2025, p. 14."

The failure this page covers is the last element written as a /P. It is still in the tree and still read; it is simply indistinguishable from the body text.

What the user hears

The note, read as the next paragraph, wherever the structure tree happens to put it. In a tree built from the page’s layout that is at the end of the page’s content, so the listener hears:

…which the committee reviewed in March. 1 Ministry of Finance, Annual Budget Report 2025, p. 14. The second meeting considered…

with nothing to say that the middle sentence is a citation, and nothing to let them skip it. On a page with six footnotes, that is six asides delivered as if they were the argument. If a sentence runs across the page break, the notes land in the middle of it.

A Note tag does not by itself make every reader handle notes well — support varies between readers — but it is the only thing in the file that lets any of them try.

Where it comes from

Footnotes typed rather than inserted. Text set small at the bottom of a page by hand, with the number typed in front, is a paragraph to every tool that reads the source. The word processor never knew it was a footnote.

Tagging from layout. A tagger working from the page, or a person working with the Reading Order tool, sees a block of small text at the foot of the page. Nothing about its appearance requires calling it anything but a paragraph.

Merged and re-tagged documents, where the structure was rebuilt from the page after the source’s tags were lost.

How to check it free

Acrobat Pro’s Tags panel. Open it from the hamburger menu (Windows) or the View menu (macOS): Show/Hide → Side Panels → Tags, labelled Accessibility tags in the current interface. Turn on Highlight Content from the Options menu, select a footnote on the page, and choose Find Tag From Selection. The element that comes up is the footnote’s tag: <Note> is right, <P> is this condition.

Not the checkers. Acrobat’s Accessibility Checker has no rule about notes in Adobe’s list of its checks. veraPDF’s two rules under clause 7.9 test the ID of notes that are already tagged (conditions 19-003 and 19-004); a footnote tagged P is not a note to either of them.

PAC’s screen reader preview shows the reading order as a reader meets it, which is the fastest way to hear where the notes land.

How to fix it free, in Acrobat Pro

Changing an element’s type is documented in Adobe’s Tags panel guide:

1. In the Tags panel, select the footnote’s <P> (use Find Tag From Selection as above).
2. Choose Properties from the Options menu.
3. Choose Note from the Type menu, and click Close.
4. If it should sit next to the paragraph that cites it, drag it there. The panel shows a line at the positions where it can be dropped.

Two things follow. The new Note needs a unique ID, condition 19-003, and Adobe’s documentation does not describe setting one. And the marker in the text needs its own tag, condition 19-002.

If the source document is to hand and the footnotes were typed by hand, convert them to real footnotes there first — then check one in the Tags panel after export, because whether a producer tags footnotes as Note is something to confirm rather than assume.

Where Taggart differs

Taggart looks at the foot of each page that has no Note element at all. A line counts as a footnote candidate if it starts in the bottom 28% of the page, is set more than 8% smaller than the page’s body text, runs to more than ten characters, and begins with a number of up to three digits — or *, †, ‡, §, ¶ — followed by a space, with an optional . or ). One or more on a page gives one finding for that page:

Page 1 has 1 small-type line(s) at the foot of the page that begin with a note marker, but the page has no <Note> element.

The finding quotes the first candidate, so you can see at once whether it found a footnote or a figure credit. A page with any Note on it is skipped entirely, and endnotes in body-size type are not looked for.

The repair is Tag notes and references. It retags elements a reviewer names: each one named as a note becomes a Note with a fresh ID of the form taggart-note-1, and each one named as a marker becomes a Reference. Given no names it changes nothing, and its error says the notes and references have to be passed in once a reviewer has confirmed them.

In the application the finding is a warning and goes to the review queue, where your decision about it is recorded with who made it and when. The queue does not yet hand the confirmed paragraphs to the repair, so for now the retagging itself is done in Acrobat, as above.

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 Tag notes and references. 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

• 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.
• 09-001 Tags are not in logical reading orderThe order of elements in the structure tree does not match the order a human would read the page. This is the single most common substantive defect in tagged PDFs and the one Acrobat's own tooling handles worst.
• 18-001 Headers and footers are not marked as pagination artifactsRunning heads, footers and page numbers are tagged as real content, so they repeat in the reading order on every page.

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