CSS Media Queries Must Not Lock Display Orientation: How to Fix It

This check flags CSS that uses @media (orientation: …) to force content into a single orientation — typically a transform: rotate(90deg) hack that pins a page to portrait or landscape. Locking orientation breaks WCAG 1.3.4 Orientation and shuts out anyone whose device is fixed in one position, from wheelchair-mounted tablets to people who simply can’t rotate their phone.

Why orientation locking is an accessibility failure

Plenty of users can’t rotate their device on demand. A tablet clamped to a wheelchair arm stays in one orientation permanently. Someone with low grip strength or a tremor may hold a phone in exactly one way. WCAG 1.3.4 (Level AA) says content must not restrict its view to a single orientation unless that orientation is essential. When your CSS detects the “wrong” orientation and rotates the whole page to compensate, you’ve made that restriction for the user — and you’ve usually broken scrolling, touch targets, and layout in the bargain.

A real failing pattern and the fix

/* FAILING: force everything to landscape by rotating in portrait */
@media (orientation: portrait) {
  html {
    transform: rotate(90deg);
    transform-origin: left top;
    width: 100vh;
    height: 100vw;
    overflow: hidden;
  }
}

/* Also failing: a "please rotate your device" wall */
@media (orientation: portrait) {
  body > * { display: none; }
  .rotate-warning { display: block; }
}

/* FIXED: let both orientations work; adapt layout instead of blocking it */
.board {
  display: grid;
  gap: 1rem;
  grid-template-columns: 1fr;      /* portrait: single column */
}
@media (orientation: landscape) {
  .board { grid-template-columns: 1fr 1fr; }  /* landscape: two columns */
}

The fix keeps both orientations fully usable. Instead of rotating the viewport or hiding content until the user complies, it responds to orientation as a layout hint — more columns in landscape, a single column in portrait. Nothing is locked; nobody is told to turn their device.

Lock hacks vs. responsive adaptation

How to detect it on your own site

1. axe DevTools: run a scan and look for “css-orientation-lock”. It parses your stylesheets for orientation media queries that apply a rotating transform and flags the offending rule.
2. Lighthouse: run the Accessibility audit on a mobile emulation profile; content that vanishes or rotates when you flip orientation shows up in the manual-check and contrast/layout items. Toggle the device orientation in DevTools’ device toolbar to reproduce.
3. WAVE: load the page in the extension, then rotate the emulated viewport. WAVE’s structure view makes it obvious when content is hidden or the visual order collapses in one orientation.
4. Real-device test: open the page on a phone with rotation lock off, then physically rotate. If the page rotates its own content the wrong way, hides everything, or nags you to turn the device, you’ve reproduced the failure.

How to fix it

1. Delete any transform: rotate() tied to an @media (orientation) query on html, body, or a top-level wrapper. That’s the core anti-pattern.
2. Remove “please rotate your device” overlays that hide content. If landscape genuinely suits your layout better, optimize for it without blocking portrait.
3. Strip any JavaScript call to screen.orientation.lock() unless the orientation is truly essential (see FAQ).
4. Rebuild the layout with responsive grid or flexbox that reflows to the available width, using @media (orientation: landscape) only to enhance, never to gate access.
5. Re-test by rotating a real device or the DevTools device toolbar; both orientations should show the same content, fully operable.

The one exception, and the stakes

WCAG carves out an exception: content whose orientation is essential may lock. A piano keyboard app, a bank cheque you photograph, or a virtual-reality view can legitimately require landscape, because the task itself depends on it. That bar is high — “our design looks nicer wide” doesn’t clear it. For everything else, locking orientation is a silent exclusion: the user who can’t rotate their device never sees a workaround, just a broken or hidden page. Because this is about how content reflows to the viewport, it sits close to width-based reflow concerns like the viewport minimum-scale and zoom checks — both are about never trapping the user in one fixed view.

FAQ

Can I ever require landscape?

Only when the orientation is essential to the task — think a level/inclinometer tool, a wide data-visualization that’s meaningless narrow, or immersive VR. If the same information can be presented in portrait with reflow, the exception doesn’t apply and you must support both.

Isn’t a “rotate your device” message helpful?

Not to someone who can’t rotate. It reads as a locked door with a sign telling them to do the one thing they’re unable to do. Adapt the layout instead of demanding the user adapt their hardware.

Does using @media (orientation) at all fail this check?

No — the query itself is fine and useful. The failure is specifically using it to rotate the viewport or hide content so one orientation is unusable. Reflowing your grid per orientation passes cleanly.

What about games or apps built for one orientation?

If the orientation is genuinely essential to gameplay or the tool, the WCAG exception covers you. Document why it’s essential; don’t reach for the exception just to avoid building a responsive layout.

Will fixing this affect my mobile SEO?

It helps. Search engines evaluate mobile usability, and content that reflows cleanly to any viewport — rather than rotating or hiding itself — scores better on the mobile-friendliness signals crawlers care about, on top of clearing the WCAG requirement.