F43: When Headings Lie to Screen Readers
Marcus · AI Research Engine
Analytical lens: Operational Capacity
Digital accessibility, WCAG, web development
AI-assisted · Source-linked · Editorially reviewed · Methodology
Trust note
This article was drafted with AI assistance, reviewed against accessibility.chat editorial standards, and should be treated as research and education rather than legal advice. We prioritize primary sources and correct material errors.

A heading element used to display an address. Not a section break. Not navigation. Just big, bold text — styled to look important. That single misuse is exactly what WCAG Failure F43 (opens in new window) documents, and it's more damaging than it looks.
F43 sits in W3C's official failure catalog as a named violation of WCAG 2.1 Success Criterion 1.3.1: Info and Relationships (opens in new window). The criterion requires that information, structure, and relationships conveyed through visual presentation be programmatically determinable. F43 is what happens when developers flip that on its head — using structural elements to create visual effects, not to represent actual content structure.
The Failure
F43 describes a specific, repeatable anti-pattern: structural HTML elements used for their visual rendering, not their semantic meaning. The W3C document gives three concrete examples. The first one is worth quoting directly.
<p>Interested in learning more? Write to us at</p><h4>3333 Third Avenue, Suite 300 · New York City</h4><p>And well send you the complete informational packet absolutely Free!</p>That address is not a heading. It introduces no new section. It contains no navigational anchor. The <h4> is there because someone wanted large, bold text — and <h4> delivered it. The result is a heading that lies.
The second example is more structurally complex:
<h1>Study on the Use of Heading Elements in Web Pages</h1><h3>Joe Jones and Mary Smith</h3><h4>March 14, 2006</h4><h2>Abstract</h2><p>A study was conducted in early 2006 ...</p>Here, <h1> and <h2> are used correctly. But <h3> and <h4> are pressed into service to style author names and a date. The heading outline now reads: Document Title → Author Names → Date → Abstract. That's not a document structure. It's a visual layout that happens to use heading tags.
The third example extends the pattern to <blockquote> — used not to mark quoted content, but to achieve indentation. Same failure mode, different element.
Violated criterion: 1.3.1 Info and Relationships (opens in new window)
Why This Matters
Screen reader users navigate by heading structure. This is not a niche behavior — it's one of the primary ways blind users orient themselves in long documents. When a screen reader announces "heading level 4: 3333 Third Avenue, Suite 300," the user reasonably expects that to be a section they can navigate to, a landmark in the document's architecture. Instead, it's a mailing address.
The disorientation compounds across a page. A heading outline that mixes real structure with decorative headings forces users to slow down, backtrack, and second-guess every heading announcement. The cognitive load is real. For users with cognitive disabilities who rely on clear structural signals to parse content, false headings actively undermine comprehension.
Keyboard users navigating by heading (common in screen readers via the H key shortcut) will land on content that has no structural significance. Switch users face the same problem. The heading list — a tool meant to provide an efficient overview of the page — becomes noise.
The <blockquote> misuse carries its own specific harm. Screen readers announce blockquotes as quoted content. A user encountering a <blockquote> used for indentation will expect attribution, a source, a citation. None exists. The semantic contract is broken.
The Fix
The corrected pattern is straightforward. Use headings only when content genuinely introduces a new section. Use CSS for visual styling.
Fixed Example 1 — Address:
<p>Interested in learning more? Write to us at</p><p class="address-display">3333 Third Avenue, Suite 300 · New York City</p><p>And well send you the complete informational packet absolutely Free!</p>.address-display { font-size: 1.; font-weight: bold;}Fixed Example 2 — Document with authors and date:
<h1>Study on the Use of Heading Elements in Web Pages</h1><p class="byline">Joe Jones and Mary Smith</p><p class="pub-date">March 14, 2006</p><h2>Abstract</h2><p>A study was conducted in early 2006 ...</p>The heading outline now reads: Document Title → Abstract. That matches the actual document structure.
Fixed Example 3 — Indentation:
<p class="indented-note">This text needs visual indentation.</p>.indented-note { margin-left: ;}Reserve <blockquote> for actual quoted content with a <cite> element.
The W3C document also notes a valid mitigation path: role="presentation" can suppress native semantics when a structural element is genuinely needed for layout reasons. But that's a narrow escape hatch, not a design strategy. Better to reach for CSS first.
Applying This
F43 is a failure that automated tools often miss — or only partially catch. A linter can flag a heading hierarchy that skips levels (<h1> directly to <h4>), but it cannot determine whether an <h4> used in sequence is semantically appropriate. That judgment requires human review. Our research on automated testing limitations puts the ceiling on automated detection at 37% of real accessibility barriers — F43-type failures are exactly the kind that fall into the remaining 63%.
For development teams, the practical catches are:
- Code review checklist item: Any heading element should introduce a navigable section. If the heading could be replaced with a
<p>and CSS without losing meaning, it probably should be. - Design system enforcement: If your design system ships a "large bold text" component that renders as a heading element, fix the component. The fix propagates everywhere.
- Linting with context: Tools like axe-core (opens in new window) can flag heading order violations. Pair automated checks with manual heading-outline review using a browser extension that exposes the heading tree.
- Content author training: F43 failures often originate not in developer code but in CMS-authored content. A content author who reaches for Heading 3 because it "looks right" will produce F43 violations at scale. Training and CMS configuration (restricting heading choices in rich text editors) are both worth the investment.
The fix cost is low. A CSS class is cheaper than a heading element misused. The organizational challenge is catching the pattern before it spreads — which is a capacity question as much as a technical one.
| Element | Correct Use | F43 Misuse | Fix |
|---|---|---|---|
<h1>–<h6> | Introduces a new document section | Visual styling (bold, large text) | <p> or <span> + CSS |
<blockquote> | Marks quoted content from another source | Indentation effect | CSS margin-left |
<table> | Represents tabular data relationships | Page layout grid | CSS Grid or Flexbox |
<th> | Header cell in a data table | Bold cell in a layout table | <td> + CSS |
CORS Perspective
From an operational capacity lens, F43 is a high-leverage, low-cost fix that teams consistently underestimate — not because the code change is hard, but because the failure pattern is invisible to sighted developers doing visual QA. The gap between what the page looks like and what it communicates to assistive technology is exactly where automated testing falls short and where human review pays dividends. Strategically, this is also a design system problem: if the component library treats heading elements as styling tools, every page built from it inherits the failure. Fix the system, not just the symptom — and you've addressed the 80% of F43 instances that come from shared components, not one-off authoring decisions.
About the Marcus lens
An operational lens on digital accessibility. Frames findings around what implementation and maintenance actually require — WCAG conformance, engineering effort, and day-to-day web development practice.
Marcus is an AI analyst lens, not a human staff member. It helps frame this article through a consistent accessibility perspective.
Specialization: Digital accessibility, WCAG, web development
View all articles using this lens →Primary source reviewed: https://www.w3.org/WAI/WCAG22/Techniques/failures/F43 (opens in new window)
Transparency Disclosure
This article was drafted with AI assistance and reviewed against our editorial methodology. We disclose that process so readers can judge the work clearly.