Level AA

Orientation locks fail users whose devices are fixed to a wheelchair, stand, or mount and cannot be rotated

1.3.4 Orientation

In Plain Language

1.3.4 Orientation (Level AA) requires that content not restrict its view and operation to a single display orientation -- portrait or landscape -- unless the specific orientation is essential to the content[1]. The exception is narrow: a check-deposit camera frame that must capture a check edge-to-edge, a piano keyboard whose keys need horizontal travel, a virtual-reality scene authored for one device hold. "Looks better this way" is not essential.

The failure mode is the page or app intercepting the device's natural orientation behavior and forcing one axis. The fix is to stop intercepting it and let responsive layout do its job.

Why It Matters

  • Wheelchair users and users with motor disabilities often have a phone or tablet bolted into a mount fixed in one orientation. They cannot rotate the device to satisfy a "please rotate" overlay -- the overlay is the end of the session[1].
  • Low-vision users often hold a device in landscape because the wider viewport reduces line wrapping after text resize and lets them increase font size without horizontal scroll.
  • Users holding a phone in a non-dominant hand, or with limited grip strength, may only be able to use the device in one orientation. Forcing the opposite axis locks them out.
  • Device-level orientation locks (set by the user in OS settings) are legitimate -- author-level locks override the user's accessibility preference and are the failure 1.3.4 targets.

Examples

Do: Content adapts to both orientations

Dashboard

Content reflows naturally in portrait and landscape. No orientation lock applied.

✔ Page works in any orientation -- layout adapts using responsive CSS

<!-- No orientation lock in the manifest or CSS -->
<!-- Content reflows using standard responsive design -->
<div class="dashboard">
  <h3>Dashboard</h3>
  <p>Content reflows naturally in portrait
     and landscape.</p>
</div>
Don't: CSS locks to portrait only
This page uses CSS to force portrait mode, hiding content when the device is in landscape.

✘ Using orientation: landscape media query to hide content locks out users who cannot rotate their device

<!-- FAILS: hides content in landscape -->
<style>
@media (orientation: landscape) {
  .content { display: none; }
  .rotate-message { display: block; }
}
</style>
<div class="content">Page content</div>
<div class="rotate-message" hidden>
  Please rotate your device to portrait.
</div>
Do: Essential orientation with justification

✔ A piano app may require landscape -- the orientation is essential for the content to function

<!-- Acceptable: piano keyboard is essentially
     a landscape interface -->
<div class="piano-keyboard" role="application"
     aria-label="Piano keyboard">
  <!-- Keys require horizontal space to function -->
</div>
Don't: Manifest locks orientation 
{
  "name": "My App",
  "orientation": "portrait"
}

✘ Web app manifest locks orientation globally -- no essential justification for a general-purpose app

<!-- FAILS: manifest.json locks orientation -->
{
  "name": "My App",
  "orientation": "portrait"
}

<!-- Also fails: screen.orientation.lock() -->
<script>
screen.orientation.lock("portrait");
</script>

How to Fix It

  1. Strip orientation from the web app manifest. Remove any "orientation": "portrait" or "orientation": "landscape" entry from manifest.json. The default "any" hands control back to the device.
  2. Remove screen.orientation.lock() calls. Grep the codebase for screen.orientation.lock and lockOrientation. These Screen Orientation API calls force the viewport axis from JavaScript and fail 1.3.4 the same way the manifest does.
  3. Stop hiding content with orientation media queries. A rule like @media (orientation: landscape) { .content { display: none; } } paired with a "rotate your device" overlay is the canonical failure pattern. Use orientation media queries only to adjust layout (column counts, gutter widths) -- never to gate access to content.
  4. Let responsive layout absorb the rotation. Flexbox and CSS Grid reflow on viewport change without intervention. If a layout breaks at one orientation, the breakage is a responsive-design bug, not a justification to lock the axis.
  5. Document any essential-orientation claim. If content genuinely cannot function in the other orientation -- a check-capture camera frame, a musical-instrument interface, an authored VR scene -- write down the mechanism that makes it essential. The exception is auditable; "we prefer it" is not a mechanism[1].
  6. Test in a fixed orientation. Mount the device, or commit to holding it one way for the full task flow, and walk every page. Anything that becomes unreachable is a 1.3.4 failure.

References

  1. [1] W3C (2023). Understanding Success Criterion 1.3.4: Orientation. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/orientation.html ↩ ↩ ↩