Matterhorn 14-006 · PDF/UA-1 UA1:7.4.4-1

Two headings under one node, in strong structure

In the strong-structure model, an unnumbered H derives its level from nesting depth, so a single structural node may contain at most one H.

What a screen reader actually does

Two headings at the same node cannot both be levelled; readers report inconsistent levels.

The model this belongs to

PDF has two ways to express heading level and a document has to pick one. Condition 14-007 is about mixing them; this one is about getting the less common of the two wrong.

Weak structure puts the level in the tag: H1 through H6. The tree is flat and the level is read straight off the element type.

Strong structure puts it in the shape. The tag is always H, and its level is how deeply the Sect elements around it are nested:

/Document
└── /Sect                    ← depth 1
    ├── /H   "Annual report"         = level 1
    └── /Sect                ← depth 2
        ├── /H  "Results"            = level 2
        └── /P  "Revenue rose…"

It is the more principled design — the level is a fact about the document’s shape rather than a number somebody typed — and it depends entirely on there being exactly one H per node. That is what this condition enforces.

What breaks with two

/Sect
├── /H   "Annual report"
├── /H   "Third quarter results"     ← both at depth 1
└── /P   "Revenue rose…"

Both headings are at the same nesting depth, so both are level 1, so this section has two level-one headings and no subsection. The document’s shape says the two titles are peers covering the same content, which is almost never what the author meant — they meant a heading and a subheading, and the subheading needed a nested Sect to live in.

A reader building a heading list gets two entries at the same level with the second one’s content belonging to neither. A reader computing outline depth has nothing to compute: the structure does not distinguish a section with a title and a subtitle from two sections where the second forgot to open.

What the user hears

A heading list that does not match the document. Both strings announced at the same level, with the material under them attached to whichever the reader decided was in force.

It is quieter than most heading failures — nothing disappears and nothing is announced with the wrong role — which is why it survives review. What it costs is the thing headings exist for: a user jumping heading to heading cannot tell the shape of the document from the shape of the list.

Where it comes from

Hand editing in Acrobat. The Tags panel’s New Tag dialog offers Heading alongside Heading Level 1 through 6. Choosing Heading inserts a bare H. Do it twice in one section and this is the result — and in a document that otherwise uses numbered headings it produces 14-007 at the same time, which is the louder of the two and usually what gets reported.

A generator with a strong-structure model and a flat emitter. It writes H for every heading correctly and never opens a nested Sect, so the whole document is one node with every heading in it.

Merged documents where two Sect subtrees were concatenated into one.

How to check it free

Acrobat Pro’s Tags panel. Expand the tree and read the element types. Two elements showing Heading — not Heading 1, just Heading — under the same parent is the condition, and it is visible without any tool.

veraPDF reports it against clause 7.4.4.

PAC groups it under Logical Structure → Headings.

How to fix it free, in Acrobat Pro

Decide what the second heading is, because the two repairs are different documents.

If it is a subheading of the first, give it a section to be in:

1. Tags panel → Options → New Tag → Section (Sect), placed after the first H.
2. Drag the second H into it, along with the content that belongs under it.

Its level is now 2 because its depth is 2, and nothing else changes.

If it begins a new section at the same level, close the first one:

1. Create a second Sect as a sibling of the first.
2. Move the second H and its content into it.

If the document is really a numbered-heading document with one stray H — check this first, it is the likeliest case — convert the bare H to the numbered level it should have and this condition and 14-007 both go away. Right-click → Properties → Tag tab → Type.

Where Taggart differs

Taggart reports which model the document is predominantly in before reporting the violation, because that is what decides the repair:

2 H elements under one node. This document uses the numbered model for 41 of its 43 headings; the 2 untyped H elements are at page 7 and page 12.

Forty-one numbered headings and two bare ones is not a strong-structure document with a nesting bug. It is a numbered-heading document with two elements somebody added by hand, and the repair is two type changes rather than a restructuring — which is also why this is reported alongside 14-007 rather than on its own.

heading-levels will make the type change, and the level it infers for each H comes from the outline around it — the nearest preceding numbered heading, plus one where the element is nested inside it — shown before it is applied. In a genuinely strong-structure document it proposes the Sect nesting instead and does not apply it, because moving content between sections is a change to what the document says its shape is, and that is not a decision a batch should make.

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 Repair heading levels. It is mechanical, so “Fix All Safe” applies it in bulk with a diff and a single undo.

Where this sits in the standards

Related conditions

• 14-007 Document uses both H and H# tags A document must commit to one heading model: strong structure (H, levelled by nesting) or weak structure (H1–H6). Mixing them makes the level of any given heading ambiguous.
• 14-002 First heading tag is not H1 The document uses numbered headings (H1–H6) but the first one encountered in the structure tree is not an H1.
• 14-003 Numbered heading levels in descending sequence are skipped The heading hierarchy jumps a level going down — H1 straight to H3. Going back up any number of levels is fine; going down must be one level at a time.
• 14-001 Headings are not tagged Text that is visually a heading — larger, bolder, isolated — is tagged as a paragraph. The document has no navigable outline.

Other conditions in checkpoint 14

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

• 14-001 Headings are not tagged Text that is visually a heading — larger, bolder, isolated — is tagged as a paragraph. The document has no navigable outline.
• 14-002 First heading tag is not H1 The document uses numbered headings (H1–H6) but the first one encountered in the structure tree is not an H1.
• 14-003 Numbered heading levels in descending sequence are skipped The heading hierarchy jumps a level going down — H1 straight to H3. Going back up any number of levels is fine; going down must be one level at a time.
• 14-004 Numbered heading tags do not use Arabic numerals Custom heading tags like "Heading-One" or "HI" must role-map to H1–H6 or to Hn using Arabic numerals.
• 14-005 Content representing a 7th level (or higher) heading does not use an H7 (or higher) tag Documents deeper than six levels must use Hn tags (H7, H8 …), role-mapped because ISO 32000-1 defines only H1–H6.
• 14-007 Document uses both H and H# tags A document must commit to one heading model: strong structure (H, levelled by nesting) or weak structure (H1–H6). Mixing them makes the level of any given heading ambiguous.

Verified against a real document on 2026-09-13 . Last updated 2026-09-13 .