F1: When CSS Positioning Breaks Reading Order

37%. That's roughly the share of accessibility failures that automated tools can reliably catch — which means failures like WCAG's F1, where CSS silently rewrites meaning, often slip through undetected until a screen reader user encounters content that makes no sense. F1 is one of those failures that looks fine on screen while being actively disorienting in the DOM.

WCAG Failure F1 (opens in new window) documents a specific, named failure condition against Success Criterion 1.3.2: Meaningful Sequence (opens in new window). The W3C's official techniques catalog exists precisely to name these patterns — not as abstract principles, but as concrete code-level anti-patterns that teams can recognize and eliminate.

The Failure

F1 describes what happens when CSS positioning is used to rearrange content visually in a way that changes the content's meaning — without any corresponding change to the source order in the HTML. Assistive technologies don't read what the screen looks like. They read the DOM. When those two things diverge in a meaningful way, users of screen readers, refreshable braille displays, and other assistive technologies encounter a different document than sighted users do.

The W3C's own example makes this concrete. A developer builds a two-column layout using CSS absolute positioning and span elements with class-based coordinates:

<div class="box">
  <span class="menu1">Products</span>
  <span class="menu2">Locations</span>
  <span class="item1">Telephones</span>
  <span class="item2">Computers</span>
  <span class="item3">Portable MP3 Players</span>
  <span class="item5">Wisconsin</span>
  <span class="item4">Idaho</span>
</div>

Visually, this renders as two organized columns: Products on the left (Telephones, Computers, Portable MP3 Players) and Locations on the right (Idaho, Wisconsin). But the source order tells a different story: Products → Locations → Telephones → Computers → Portable MP3 Players → Wisconsin → Idaho. Wisconsin appears before Idaho in the DOM even though Idaho renders first on screen. Strip the CSS — or parse this with a screen reader — and you get a single, disjointed stream that groups the column headers together and scrambles the location list.

There's no semantic structure here. No ul, no table, no landmark that communicates the relationship between headings and their items. Just spans positioned into the appearance of organization.

Why This Matters

For a screen reader user, this failure doesn't announce itself. The content doesn't error out. It just... arrives in the wrong order, with no structural cues to explain why "Locations" immediately follows "Products" before any location is listed. The user has to work to reconstruct meaning that sighted users receive passively through visual layout.

This is the crux of SC 1.3.2. The criterion doesn't require that reading order match visual order in all cases — it requires that when sequence affects meaning, that sequence be programmatically determinable. CSS positioning that changes meaning without changing source order fails this test directly.

Braille display users face a compounding problem: they read linearly, one refreshable line at a time, with no peripheral vision to establish spatial context. A two-column layout that makes intuitive sense visually becomes genuinely confusing when encountered sequentially with no structural scaffolding.

Users who disable stylesheets — a legitimate accessibility strategy for people with certain cognitive or visual processing needs — encounter the raw source order. If that order doesn't make sense, the content becomes inaccessible to them entirely.

The Fix

The correction isn't primarily about CSS — it's about using semantic HTML that communicates structure regardless of how it's styled. The visual layout can remain identical. What changes is the underlying structure:

<div class="columns">
  <ul class="products-column">
    <li class="column-heading">Products</li>
    <li>Telephones</li>
    <li>Computers</li>
    <li>Portable MP3 Players</li>
  </ul>
  <ul class="locations-column">
    <li class="column-heading">Locations</li>
    <li>Idaho</li>
    <li>Wisconsin</li>
  </ul>
</div>

Now the source order matches the visual grouping. Each column is a list. The heading precedes its items in the DOM. Idaho appears before Wisconsin both visually and in source. Strip the CSS and the content remains coherent — two lists, each with a header item, in a logical sequence.

For more complex layouts — navigation menus, data tables, multi-column editorial content — the same principle applies: the DOM order should tell a coherent story without CSS. Use table for tabular data with proper th scope attributes. Use nav with list structure for navigation. Use CSS Grid or Flexbox with source order that matches reading order, and reserve order property changes for cases where meaning is not affected.

Applying This

F1 sits in a detection blind spot. Automated tools can flag some source-order issues, but they cannot reliably determine whether a CSS-driven reordering changes meaning — that requires human judgment about content semantics. As our research on automated vs. manual testing methodology documents, this is precisely the category of failure where the 37% detection ceiling bites hardest.

Practical catches for development teams:

• Code review: When you see position: absolute, position: fixed, or CSS order on flex/grid children, ask whether the visual sequence matches DOM sequence. If they differ, ask whether that difference affects meaning.
• Keyboard navigation test: Tab through the page without a mouse. Does focus move in an order that matches the visual layout and makes logical sense? Disorienting tab order is often a symptom of F1-type source order problems.
• Stylesheet-disabled test: In Firefox, disable CSS via View → Page Style → No Style. Read the content linearly. Does it make sense? This takes under two minutes and catches F1 failures immediately.
• Screen reader spot-check: Navigate the specific layout with NVDA or VoiceOver in browse mode. Listen to whether the announced sequence matches the visual grouping.
• Design handoff: Flag multi-column layouts, visual reordering, and positioned elements in design specs. Accessibility review at the design stage prevents F1 from entering the codebase at all.

Teams working across multiple standards frameworks — WCAG 2.2, Section 508, EN 301 549 — should note that SC 1.3.2 is incorporated across all three. The compliance fragmentation challenge is real, but F1 is one of those baseline failures where the fix is consistent regardless of which framework governs your organization.

CORS Perspective

F1 is a systems-level failure as much as a code-level one. Operationally, it emerges when visual design and front-end development work in isolation — designers hand off layouts without accessibility annotations, developers implement visual fidelity without auditing source order. The community impact falls disproportionately on screen reader users and braille display users, who encounter disorganized content with no recourse. From a risk standpoint, F1 violations against SC 1.3.2 represent clear, documented WCAG failures that appear in Title II and Title III (opens in new window) enforcement contexts. Strategically, the fix costs almost nothing at the code level — semantic HTML is not more expensive than span soup — which makes F1 one of the more defensible quick wins in any accessibility remediation backlog. The barrier is organizational awareness, not technical complexity.