Turn Heading Structure Findings into Accessibility Tickets

Heading and landmark findings become fixable when the ticket names the page region, the broken structure, and the navigation task that becomes slower for screen reader and keyboard users.

Use this guide for audit notes about missing page headings, skipped heading levels, visual headings built from plain text, repeated h1 elements, unlabeled landmarks, or pages where the screen reader outline does not match the visual layout.

Draft the structure ticket first

Open a product listing example in the generator with the affected outline, screen reader path, expected structure, and retest criteria already filled in.

Open this heading structure finding in the generator

What to capture from the finding

Page or template: product listing, checkout step, article page, dashboard, account area, search results, modal, or CMS content type.
Broken structure: missing h1, skipped level, repeated h1, fake visual heading, empty heading, unlabeled region, or duplicate navigation landmark.
Current outline: the heading list or landmark list exposed by the browser, screen reader, or accessibility tree.
Visual expectation: the section titles, page title, sidebar, results area, or repeated component that users can see but cannot navigate programmatically.
Navigation impact: slower page scanning, missed sections, repeated linear reading, or confusion when similar landmarks are not named.

Ticket structure

Title:
[Severity] Page or template: heading and landmark structure does not match the visible layout

User impact:
Explain what screen reader users cannot find or skip to when the programmatic page structure does not expose the same sections as the visual layout.

Evidence:
- Page or template:
- Affected region or component:
- Current heading or landmark outline:
- Visual structure expected:
- Assistive technology path:
- Actual result:
- Expected result:

Likely WCAG references to verify:
- 1.3.1 Info and Relationships, when visual headings or regions are not exposed programmatically.
- 2.4.1 Bypass Blocks, when users cannot skip repeated navigation or page chrome efficiently.
- 2.4.6 Headings and Labels, when headings or labels do not describe topic or purpose.
- 4.1.2 Name, Role, Value, when custom regions, disclosure widgets, or landmark labels are missing or misleading.

Acceptance criteria:
- The page exposes one descriptive h1 for the main page purpose.
- Visual section titles that structure the page are real headings at logical levels.
- Landmark regions are used intentionally and named when multiple regions of the same type exist.
- Screen reader heading and landmark navigation matches the main visual structure without empty or misleading entries.

Paste your heading or landmark note into the generator when you want this structure drafted from raw audit text.

Example conversion: fake section headings

Raw note:
Dashboard cards use large bold text for Account summary, Recent invoices, Support requests, and Product usage. They are div elements, not headings. NVDA heading navigation only exposes the page h1.

Developer ticket:
[Medium] Account dashboard: visual card titles are not exposed as headings

User impact:
Screen reader users cannot jump between the main dashboard sections with heading navigation. They must move through every control and card in sequence to find invoices, support requests, or product usage.

Evidence:
- Page: account dashboard
- Affected components: dashboard card titles
- Current result: NVDA heading list only exposes the page h1
- Expected result: each major dashboard card title is exposed as a logical heading

Likely WCAG references to verify:
- 1.3.1 Info and Relationships
- 2.4.6 Headings and Labels

Acceptance criteria:
- Each major dashboard section title is a real heading at the correct level below the page h1.
- The heading text matches the visible section title.
- Styling is preserved without relying on div or span elements for structural headings.
- NVDA heading navigation exposes Account summary, Recent invoices, Support requests, and Product usage in the expected order.

Example conversion: duplicate navigation landmarks

Raw note:
Page has three nav landmarks: header menu, product category menu, and footer links. None have accessible names. VoiceOver rotor lists Navigation three times.

Developer ticket:
[Medium] Product page: multiple navigation landmarks are not named

User impact:
Screen reader users who use landmark navigation cannot tell whether a navigation landmark opens the main menu, product category navigation, or footer links.

Evidence:
- Page: product detail page
- Affected regions: header navigation, category navigation, footer navigation
- Screen reader path: VoiceOver rotor landmarks
- Actual result: three entries are announced as Navigation
- Expected result: each navigation landmark has a distinct accessible name

Likely WCAG references to verify:
- 1.3.1 Info and Relationships
- 2.4.1 Bypass Blocks
- 4.1.2 Name, Role, Value

Acceptance criteria:
- Header, category, and footer navigation landmarks have distinct names.
- Names describe the purpose of each navigation area without duplicating visible headings awkwardly.
- VoiceOver rotor exposes distinguishable landmark entries.
- The fix is applied consistently in shared layout templates.

Better fix directions

Start with the page purpose: one clear h1 should identify the page or flow step, not the brand chrome around it.
Use semantics before ARIA: prefer native h1-h6, main, nav, aside, header, footer, and section patterns before adding custom roles.
Do not choose heading levels by font size: visual scale and structural nesting are separate decisions.
Name repeated landmarks: multiple nav or region landmarks need names that help users choose the right one.
Retest templates: heading mistakes often live in CMS components, product cards, dashboard cards, modal headers, and reusable layout wrappers.

Paste-ready input for the generator

Heading or landmark finding:
Page or template:
Affected region/component:
Current heading outline:
Current landmark list:
Visual structure expected:
Screen reader or browser inspection path:
Actual navigation result:
Expected navigation result:
Reusable template/component affected:
Acceptance criteria needed:

Open the accessibility ticket generator and paste this structure with the audit note.