F100: The 'Please Rotate' Message That Fails WCAG 1.3.4

2012: responsive design becomes mainstream. 2018: WCAG 2.1 introduces Success Criterion 1.3.4 Orientation (opens in new window), explicitly requiring content to work in both portrait and landscape. 2025: the orientation door slam is still shipping in production.

The pattern is so common it has its own informal name. And W3C's Failure F100 (opens in new window) documents it precisely: showing a message that asks users to rotate their device — instead of actually reorienting the content — is a WCAG 2.2 failure. Not a warning. Not a best-practice gap. A failure.

The Failure

F100 targets WCAG 2.1 Success Criterion 1.3.4 Orientation (opens in new window), which requires that content not restrict its view and operation to a single display orientation unless that orientation is essential to the content's function.

The failing pattern — what the W3C document calls an orientation "door slam" — looks like this:

/* Orientation "door slam" Styling */
media all and (orientation: landscape) {
  .rotate {
    display: block;
  }
  .content {
    display: none;
  }
}
media all and (orientation: portrait) {
  .rotate {
    display: none;
  }
  .content {
    display: block;
  }
}

<!-- Orientation "door slam" HTML -->
<div class="rotate">Please rotate your device!</div>
<div class="content">
  ...
</div>

The CSS detects orientation via the viewport's width-to-height aspect ratio — portrait when height ≥ width, landscape otherwise. When landscape is detected, content is hidden and the rotate message appears. The W3C document is precise about what makes this a failure: detecting orientation is not the problem. The decision to serve only one orientation is.

Why This Matters

The users most harmed by this pattern are those who cannot physically rotate their devices.

A wheelchair user may have their tablet mounted in a fixed position. Someone with limited arm mobility may use their phone in a single orientation because repositioning is difficult or painful. A screen reader user navigating in landscape may have configured their assistive technology around that layout. For all of these users, "please rotate your device" is not a helpful prompt — it's a wall.

The experience is immediate and complete: the content disappears. Not degraded, not harder to use — gone. Replaced by a message that assumes the user has the physical capacity and situational freedom to comply. That assumption is exactly what SC 1.3.4 exists to challenge.

Cognitive accessibility is also relevant here. Users with certain conditions rely on consistent, predictable interfaces. An unexpected full-screen message replacing content creates confusion and disorientation — particularly when the user doesn't understand why the content vanished or how to get it back.

The Fix

The correction is architectural, not cosmetic. Instead of hiding content and showing a message, the content itself must reflow for both orientations. CSS media queries remain the right tool — they just need to do actual layout work instead of a display swap.

/* Responsive layout that works in both orientations */
media all and (orientation: landscape) {
  .content {
    display: flex;
    flex-direction: row;
  }
  .sidebar {
    width: 30;
  }
  .main {
    width: 70;
  }
}
media all and (orientation: portrait) {
  .content {
    display: flex;
    flex-direction: column;
  }
  .sidebar {
    width: 100;
  }
  .main {
    width: 100;
  }
}

No rotate message. No hidden content. The layout adapts; the content remains accessible in both states.

The W3C standard does allow one exception: if a specific orientation is "essential" to the content's function. A piano keyboard application that genuinely requires landscape to render the instrument usably could qualify. A marketing page, a checkout flow, a dashboard — these do not. The essential exception is narrow by design.

Applying This

This failure is partially detectable by automated tools, but the detection is shallow. A tool can flag display: none applied inside an orientation media query — but it cannot determine whether the hidden element is decorative, supplemental, or the entire page content. That distinction requires human judgment.

For code review, the signal to catch is any display: none or visibility: hidden rule scoped inside @media (orientation: landscape) or @media (orientation: portrait). That pattern warrants immediate scrutiny. Pair it with a quick manual check: rotate a real device or use browser DevTools' device emulation to toggle orientations and verify content remains available in both.

For design systems, the fix belongs upstream. Component libraries that include orientation-specific display rules should be audited for door-slam patterns before they propagate across an entire product. A single shared component with this failure can create F100 violations across dozens of pages simultaneously.

Automated testing tools can be configured to flag orientation media queries for manual review — not as automatic failures, but as a queue for human verification. Our research on automated versus manual testing methodologies shows this kind of "flag for review" approach is more accurate than treating automated findings as definitive. The 37% detection ceiling on automated tools means orientation failures can easily slip through without a deliberate manual step in the workflow.

Teams working across multiple standards frameworks — WCAG, Section 508, EN 301 549 — should note that SC 1.3.4 compliance applies across all three. The compliance framework landscape can make it tempting to treat these as separate checklists, but F100 is a failure under all of them.

CORS Perspective

From an operational capacity standpoint, F100 is a high-value fix: the effort is low, the impact is immediate, and the pattern is identifiable in a single code review pass. The door slam often exists not because teams made a deliberate accessibility tradeoff, but because orientation-specific CSS felt like a reasonable UX solution at the time — and nobody tested it with a mounted device or a fixed-orientation assistive technology setup. Building orientation testing into design QA checklists and flagging display: none inside orientation queries in linting rules converts this from a recurring failure into a caught pattern. The risk exposure is real — SC 1.3.4 is an explicit WCAG 2.2 criterion with no ambiguity about what constitutes failure — but the remediation path is among the most straightforward in the WCAG catalog. Fix the CSS, remove the message, verify in both orientations. Done.