When Content Vanishes: Understanding WCAG Failure F102

In the early days of responsive web design, the dominant metaphor was graceful degradation — the idea that content could be stripped away as screens shrank, leaving only the essential. That framing made sense when mobile devices were an afterthought. It made less sense after smartphones became the primary internet access point for many disabled users. And it makes no sense at all under WCAG 2.2, which treats content disappearance at narrow viewports not as a design tradeoff, but as a documented failure.

WCAG Failure F102 (opens in new window) addresses exactly this: content that exists at wider viewport widths and simply vanishes when the viewport narrows to 320px. Not repositions. Not collapses into a disclosure widget. Disappears.

The Failure

Success Criterion 1.4.10 Reflow (opens in new window) requires that content can be presented in a single column without loss of content or functionality, without requiring two-dimensional scrolling — at a viewport width equivalent to 320 CSS pixels. The operative phrase is without loss of content. F102 is the failure mode that occurs when that condition is violated.

The W3C's official description is precise: content that is unavailable at wider widths after reflow to 320px fails this criterion. The standard explicitly acknowledges that content may need to move — repositioned into a single column, tucked into a disclosure area, offered through a dialog, or linked to an alternate view. All of that is acceptable. What isn't acceptable is content that simply ceases to exist in the rendered page.

The failure catalog includes five concrete patterns:

• A sidebar block of blog navigation links that disappears entirely in single-column view
• Labels above text inputs that are hidden and replaced by placeholder text on reflow, with no mechanism to reveal the dedicated label on focus
• Sections of content text that vanish without a disclosure widget offering access
• Information-carrying images that disappear without an equivalent alternative or link
• A global search field that disappears without an icon, menu option, or path to equivalent search functionality

These are not edge cases. They are common patterns in production codebases.

Why This Matters

For a compliance officer reading through an accessibility audit, F102 violations can look like minor layout issues. They are not. They represent content that specific users cannot access at all.

Consider the user who relies on browser zoom or OS-level display scaling to enlarge text. At 400% zoom on a 1280px display, the effective viewport width drops to approximately 320px. That user — who may have low vision, a cognitive disability affecting reading at small sizes, or a motor impairment that makes horizontal scrolling difficult — now encounters a page where the search function has vanished, where the navigation sidebar is gone, where form labels have been replaced by placeholder text that disappears the moment they click into the field.

The placeholder-as-label pattern deserves particular attention. Placeholder text is not a label. It disappears on input focus, creating a memory burden for users with cognitive disabilities. When a responsive design removes the visible label on reflow and substitutes only a placeholder, it compounds the original accessibility problem with a reflow failure. The user at 320px viewport width now has neither a persistent label nor the label that existed at wider widths.

Keyboard-only users and switch device users navigating forms encounter the same problem: the label that would have identified the field is gone, and the placeholder — already gone on focus — was never an adequate substitute.

This isn't abstract. Our research on testing methodology gaps documents that automated tools catch, at most, 37% of accessibility failures. F102 violations are precisely the kind of failure that automated scanning misses — a tool can confirm that an element exists in the DOM, but it cannot easily determine that the element is visually hidden, display:none, or simply absent from the reflowed layout in a way that eliminates user access.

The Fix

F102 is a failure document, not a technique document — it describes what goes wrong, not a single correct solution. The corrective approach depends on what the content is and why it disappeared.

For sidebar navigation that disappears:

<!-- Failure: sidebar removed from DOM at narrow viewport via JS or CSS -->
<aside class="sidebar" style="display:none">!-- hidden at 320px -->
  <nav aria-label="Recent posts">...</nav>
</aside>
<!-- Fix: reposition into single column flow, or use a disclosure widget -->
<details>
  <summary>Recent Posts</summary>
  <nav aria-label="Recent posts">...</nav>
</details>

For labels replaced by placeholders:

<!-- Failure: label hidden at narrow viewport, placeholder substituted -->
<label for="email" class="visually-hidden-mobile">Email address</label>
<input type="email" id="email" placeholder="Email address">
<!-- Fix: label must remain visible and persistent at all viewport widths -->
<label for="email">Email address</label>
<input type="email" id="email" placeholder="name@example.com">

The label fix is non-negotiable. Placeholder text may supplement a label, but it cannot replace one — at any viewport width. The CSS class visually-hidden-mobile that removes a label from the visual layout at narrow viewports creates an F102 failure.

For information-carrying images that disappear:

<!-- Failure: image removed via CSS at narrow viewport -->
<img src="chart.png" alt="Sales by region Q3" class="hide-mobile">
<!-- Fix: reposition or provide equivalent access -->
<figure>
  <img src="chart.png" alt="Sales by region Q3">
  <figcaption>
    <a href="/data/q3-sales-by-region">View Q3 sales data as table</a>
  </figcaption>
</figure>

The key principle across all fixes: content must remain available to the user at 320px. The method of availability can change. The content itself cannot disappear.

Applying This

For development teams, catching F102 failures requires a specific testing protocol — automated scanning alone will not surface them. The methodology research on this site documents why hybrid approaches are necessary.

A practical testing checklist for reflow failures:

In code review, flag any CSS that uses display:none, visibility:hidden, or opacity:0 inside responsive breakpoints targeting narrow viewports. These are not automatic failures — visually decorative elements may legitimately be hidden — but they warrant explicit review against F102 criteria. Ask: is this content informational? Is it functional? If yes, where does it go?

Design system documentation should explicitly state which components are permitted to reposition, which may use disclosure patterns, and which must remain fully visible at all viewport widths. That policy decision — made once at the design system level — prevents F102 failures from being reintroduced component by component across a codebase.

Organizations navigating multiple compliance frameworks should note that F102 applies across all technologies per the W3C's own applicability statement, and that SC 1.4.10 is incorporated by reference into Section 508 through the 2017 refresh. The compliance framework analysis on this site examines how organizations can manage these overlapping obligations without paralysis — but the reflow requirement is consistent across frameworks, which simplifies prioritization here.

CORS Perspective

F102 sits at an interesting intersection of all four CORS dimensions. From a community standpoint, the users most affected — those relying on zoom, screen magnification, or low-vision accommodations — are often the same users least likely to file formal complaints, making the failure invisible to organizations that wait for grievances. Operationally, the fix requires a testing protocol change more than a remediation sprint; teams that build reflow testing into their standard viewport QA process prevent the failure systematically. The risk dimension is real: SC 1.4.10 is a Level AA requirement under WCAG 2.2 (opens in new window), incorporated into Section 508 and increasingly cited in DOJ enforcement and settlement monitoring. Strategically, framing reflow compliance as a mobile quality issue — not just an accessibility checkbox — tends to generate broader team buy-in, since the same 320px viewport test that catches F102 failures also catches general mobile layout regressions.