F2: When Visual Style Masquerades as Structure

A styled paragraph that looks like a heading is still just a paragraph. To sighted users, the distinction is invisible. To someone navigating with a screen reader, it's the difference between a usable page and a wall of undifferentiated text.

WCAG Failure F2 (opens in new window) documents this pattern precisely: using visual text presentation — font size, weight, color, spacing — to communicate meaning that only exists in the visual layer, without encoding that meaning in the underlying markup. It's one of the most common and most preventable failures in production HTML.

The Failure

F2 is a documented failure of WCAG 2.1 Success Criterion 1.3.1: Info and Relationships (opens in new window). That criterion requires that information conveyed through presentation — structure, relationships, emphasis — also be available through programmatic means. When it isn't, users who rely on assistive technology receive a degraded or meaningless experience.

The W3C document gives two canonical examples. The first:

<style>
  .heading1 {
    font-family: Times, serif;
    font-size: 200%;
    font-weight: bold;
  }
</style>
<p class="heading1">Introduction</p>
<p>This introduction provides detailed information about how to use this ...</p>

Visually, this renders as something that looks like a heading. In the accessibility tree, it's a paragraph. Screen readers won't announce it as a heading. Keyboard users navigating by heading (a standard pattern — the H key in NVDA and JAWS) will skip it entirely. The document structure, from an assistive technology perspective, is flat.

The second example involves images of text:

<img src="Chapter1.gif" alt="Chapter One">
<p>Once upon a time in the land of the Web...</p>

The alt text conveys the words, but not the role. There's no heading element wrapping the image. A screen reader user gets the text content but loses the structural information — they can't navigate to it as a chapter heading, can't understand its hierarchical relationship to what follows.

Why This Matters

SC 1.3.1 exists because structure is navigation. Screen reader users routinely use heading navigation to skim long pages — jumping between sections to find relevant content, exactly the way sighted users scan visually. When headings are faked with CSS, that navigation breaks silently. The page appears to work. The failure is invisible to anyone not using assistive technology.

This isn't an edge case. Heading navigation is one of the most documented usage patterns in screen reader user research. The WebAIM Screen Reader User Survey consistently shows that navigating by headings is among the most common techniques for understanding page structure. A page where visual hierarchy exists but semantic hierarchy doesn't is a page that communicates its structure to some users and hides it from others.

Users with cognitive disabilities are also affected. Programmatic structure supports browser features, extensions, and AT tools that reformat or simplify content. A <h2> can be restyled, extracted, summarized. A <p class="looks-like-a-heading"> cannot.

The image-of-text variant adds a second layer of failure. Beyond the missing heading role, images of text don't resize cleanly, don't respond to user font preferences, and fail under high-contrast or custom stylesheet conditions. F2 applies to both patterns.

The Fix

The correction is straightforward. For the CSS-styled paragraph, the fix is to use the appropriate semantic element and style it:

<style>
  h1 {
    font-family: Times, serif;
    font-size: 200%;
    font-weight: bold;
  }
</style>
<h1>Introduction</h1>
<p>This introduction provides detailed information about how to use this ...</p>

Same visual output. Correct semantic structure. The heading is now announced by screen readers, navigable by keyboard, and parseable by any tool that reads the DOM.

For the image-of-text pattern, the W3C document recommends two approaches: at minimum, wrap the <img> in a heading element; better still, eliminate the image entirely and use CSS-styled text:

<!-- Minimum fix -->
<h1><img src="Chapter1.gif" alt="Chapter One"></h1>
<!-- Better fix: eliminate the image -->
<h1>Chapter One</h1>

The second approach also resolves the text scaling and contrast issues that come with images of text — a two-for-one remediation.

Applying This

F2 failures are partially detectable by automated tools, but not reliably. An automated scanner can flag <img> elements outside heading tags, but it cannot know that a <p class="heading1"> was intended as a heading — that requires human judgment about design intent.

This is exactly the gap documented in our research on automated testing limitations: automated tools catch structural absences but miss presentational deceptions. F2 is a case where the DOM is technically valid — no broken tags, no missing attributes — but semantically wrong.

Practical catches for development teams:

• Design system review: If your component library includes heading-styled text components, audit whether they use heading elements or styled <div>/<p> elements. This is where F2 most commonly propagates at scale.
• CSS audit: Search your stylesheets for classes named heading, title, section-title, or similar. Cross-reference whether those classes are applied to non-heading elements.
• Axe or Lighthouse with manual follow-up: Run automated tools to flag obvious cases, then manually inspect any element that looks like a heading in the rendered view but doesn't appear in the heading outline. Browser extensions like HeadingsMap make this fast.
• Code review checklist: Add a line — "Does this element's visual role match its semantic role?" — to your PR review process. It takes seconds and catches F2 before it ships.

For teams managing design systems at scale, the deeper fix is upstream: ensure that heading components in your system only render heading elements, and that designers understand they can achieve any visual style on an <h1>–<h6> without abandoning semantic structure. The Compliance Framework Paradox we've documented shows that teams with fragmented standards often lose track of foundational requirements like 1.3.1 while chasing newer criteria — F2 is a reminder that the basics still matter most.

CORS Perspective

From an operational capacity lens, F2 is a high-leverage, low-cost fix — which makes its persistence in production code a capacity problem, not a knowledge problem. The pattern almost always originates in design handoff: a designer specifies a visual style, a developer implements it with whatever element is convenient, and no one in the pipeline asks whether the element's role matches its appearance. Building that question into design review and code review costs almost nothing. Fixing it after the fact — across a large content site where <p class="heading"> has been used for years — is expensive. The risk profile here aligns with SC 1.3.1 (opens in new window) being a Level A requirement: this isn't an edge case or an advanced criterion. It's baseline conformance, and failures here signal that an organization's accessibility process has gaps at the point where design meets implementation.