WCAG 1.3.4 Orientation: Don't Lock the Screen

A CSS media query locks your layout to portrait. For a wheelchair user with a mounted tablet, that's not a minor inconvenience — it's a wall. The device is bolted to the chair arm. It cannot rotate. And your application just told it to.

WCAG 1.3.4 Orientation (opens in new window) is a Level AA success criterion under Principle 1 (Perceivable), Guideline 1.3 (Adaptable). The requirement is concise: content must not restrict display to a single orientation — portrait or landscape — unless that restriction is essential. "Essential" is a narrow exception. A piano keyboard app that genuinely requires landscape to function qualifies. A news article that locks to portrait because a developer assumed mobile means portrait does not.

THE REQUIREMENT

The W3C Understanding document (opens in new window) draws a precise boundary worth understanding. This criterion governs author-imposed restrictions, not device-level settings. When a user activates their phone's system-level orientation lock, every application is expected to honor that setting — that's the user exercising control. WCAG 1.3.4 addresses the inverse: when a developer overrides the user's environment and forces a specific orientation regardless of what the device or user prefers.

The distinction matters operationally. A page that doesn't restrict orientation will automatically respect whatever the system-level setting is, because the user agent handles it. The compliance target is: do not restrict. The implementation target is: remove the code that restricts.

WHY THIS MATTERS

The W3C's own intent statement leads with a concrete scenario — power wheelchair users with mounted devices. That's not incidental. It reflects the real population this criterion was designed to protect.

Consider the actual experience: a user with limited or no hand mobility uses a tablet mounted to their wheelchair. The mount is fixed. Rotating the device is not an option. When a site locks to portrait and the mount is in landscape, the content renders sideways, truncated, or inaccessible. There is no workaround available to the user. The barrier is total.

Beyond wheelchair users, the affected population is broader than most teams anticipate:

• Users with motor impairments who have positioned a device at a specific angle for stability
• Low-vision users who prefer landscape for wider text reflow and larger effective viewport
• Users in fixed physical positions — lying down, in a hospital bed, using a mounted kiosk
• Users with cognitive disabilities who have configured their environment deliberately and find unexpected layout changes disorienting

This is a criterion where the failure mode is invisible during standard desktop QA and even most mobile testing — because testers rotate their devices freely. The users who can't rotate are the ones who encounter the wall.

HOW TO MEET IT

The sufficient technique is G214 (opens in new window): use content that does not restrict its view to a single orientation. In practice, this means auditing your CSS and JavaScript for patterns that force orientation.

The two documented failure modes are F97 (opens in new window) and F100 (opens in new window). F97 covers locking orientation via CSS. F100 covers locking via JavaScript screen orientation APIs.

CSS failure pattern:

/* F97 — This locks content to portrait only */
media screen and (orientation: landscape) {
  body {
    transform: rotate(-);
    /* or display: none; or visibility: hidden; */
  }
}

Some implementations go further, displaying a "please rotate your device" overlay that blocks all content in the non-preferred orientation. That overlay is the failure — it prevents access rather than adapting layout.

JavaScript failure pattern:

// F100 — Locking via Screen Orientation API
screen.orientation.lock('portrait-primary');

This API exists for legitimate use cases (games, camera apps). For general web content, calling it without an essential-use justification violates 1.3.4.

Conformant approach:

/* Responsive layout that adapts to both orientations */
.content-grid {
  display: grid;
  grid-template-columns: ;
}
media screen and (orientation: landscape) {
  .content-grid {
    grid-template-columns:  ; /* Reflow, dont block */
  }
}
media screen and (orientation: portrait) {
  .content-grid {
    grid-template-columns: ;
  }
}

The orientation media query is not the problem. Using it to adapt layout is fine. Using it to hide or block content is the failure.

APPLYING THIS

This is one of those criteria where automated testing is genuinely limited. Our research paper Beyond Detection: Why Context Separates Automated Testing from Manual Audits documents the ceiling on automated detection — roughly 37% of accessibility barriers. Orientation locking sits in the hard-to-detect category because it requires runtime evaluation in a specific device state.

That said, static analysis can catch some patterns:

For development teams, the most effective catch is a code review checklist item: flag any use of screen.orientation.lock() and any CSS block that applies display: none, visibility: hidden, or transform: rotate conditionally on orientation. These warrant a documented justification — and if the justification isn't "essential functionality," the pattern should be removed.

Design-side prevention matters here too. If a designer specifies a layout that only works in one orientation, the constraint needs to surface in design review, not after implementation. Adaptive layouts that reflow across orientations should be the default expectation in any responsive design system.

For teams managing multiple compliance frameworks simultaneously — WCAG, Section 508, EN 301 549 — The Compliance Framework Paradox is worth reading. Orientation is one of the criteria where the standards largely align, which makes it a lower-complexity fix in a multi-standard environment.

CORS PERSPECTIVE

From an operational capacity standpoint, WCAG 1.3.4 is one of the more tractable criteria to address systematically. The failure modes are specific, the fix is usually a CSS or JavaScript removal rather than a build, and the testing protocol — while requiring deliberate setup — is straightforward to document and repeat. The real operational risk is that this criterion gets deprioritized because it's invisible in standard testing workflows. Teams that build orientation-lock checks into their CI pipeline and design review process will close this gap durably; teams that rely on ad-hoc QA will keep reintroducing it. The community impact is asymmetric: the users who hit this barrier hardest are the ones with the fewest workarounds available.