1.3.4 Orientation

WCAG 2.2 · 1.3.4 AA Perceivable

What it requires

Content and functionality must not be restricted to a single display orientation — such as portrait or landscape — unless a specific orientation is essential. When a user rotates their device, the page should follow and remain fully usable in both orientations. Locking the view forces some people to rotate a device they cannot easily turn.

The exception is narrow: a specific orientation may be required where it is genuinely essential, for example a piano app, a cheque-deposit camera view, or a virtual-reality experience designed for one orientation. Visual preference is not a valid reason to lock.

  • People who mount a device in a fixed position — for example, a wheelchair-mounted tablet that is permanently in landscape.
  • People with motor or dexterity disabilities who cannot reliably rotate a phone or tablet by hand.
  • Users who have set a system-level orientation lock (often for the same access reasons) and find the app fighting it.
  • Low-vision users who magnify in one orientation and lose content when the other is forced.

How to detect it

Checks for orientation lock
Check How Catches the failure?
Rotate the device On a real phone or tablet, rotate between portrait and landscape and confirm content reflows and stays usable in both. Yes — the primary manual test.
Inspect the CSS Look for @media (orientation: …) rules that hide content or show a "rotate your device" overlay. Yes — reveals deliberate locks.
Check the markup / manifest Look for the screen.orientation.lock() API or an orientation field in a web app manifest. Yes — programmatic locks.
Automated tools (axe, etc.) Some scanners flag orientation-locking media queries. Partial — confirm manually; tools miss script-based locks.

How to fix it

  1. Remove any orientation lock in the web app manifest or the screen.orientation.lock() call unless the orientation is essential.
  2. Delete CSS that hides content or shows a "please rotate" message in one orientation.
  3. Build a responsive, reflowing layout that works in both portrait and landscape at all viewport sizes.
  4. If you scope styles by orientation, adjust the layout — never remove functionality.
  5. Re-test by rotating a real device in both directions.
Adjust layout, don't lock 
/* Good: reflow per orientation, keep all content usable */
@media (orientation: landscape) {
  .gallery { grid-template-columns: repeat(3, 1fr); }
}
@media (orientation: portrait) {
  .gallery { grid-template-columns: 1fr; }
}
/* Avoid: hiding content or forcing a single orientation */

Copy-paste tests

Automated coverage

The axe-core rule css-orientation-lock flags failures of this criterion. Run it via the axe DevTools browser extension or axe-core in CI. Automated tools only catch some failures — script-based locks and essential-orientation judgements still need a human.

Run this in the browser console

orientation-lock-check.js 
// Read-only: surface possible orientation locks for review.
const hits = [];
for (const sheet of document.styleSheets) {
  let rules;
  try { rules = sheet.cssRules; } catch (e) { continue; }
  for (const r of rules || []) {
    if (r.media && /orientation\s*:/i.test(r.media.mediaText)) {
      hits.push({ media: r.media.mediaText, css: r.cssText.slice(0, 120) });
    }
  }
}
const manifest = document.querySelector('link[rel="manifest"]');
console.log('manifest link:', manifest ? manifest.href : 'none — inspect for "orientation"');
console.table(hits);

What to check manually: rotate a real device between portrait and landscape and confirm all content reflows and stays usable, and decide whether any remaining lock is genuinely essential — no script can judge that.