CSS locks content to a single orientation

What is this issue?

A stylesheet contains a CSS @media (orientation: portrait) or @media (orientation: landscape) rule that hides content (display: none, visibility: hidden), disables interaction, or otherwise prevents the page from functioning in the orientation it doesn’t target. This is different from ordinary responsive design, which reflows and restyles content across orientations. The failure specifically involves removing access to content or functionality in one orientation rather than adapting it.

WCAG 1.3.4 carries one narrow exception: content genuinely essential to a single orientation, such as a piano-keyboard simulator or a check-deposit camera view that only functions sensibly in landscape, is exempt. That exception is about functional necessity, not design preference: “it looks better in landscape” does not qualify.

Why does this matter?

Some people mount their device in a fixed position because they physically cannot hold and rotate it: a wheelchair-mounted tablet arm, a bed-rail-mounted phone holder for someone with limited mobility, a head-pointer or eye-tracking setup calibrated to a specific screen angle. For these users, “just rotate your phone” isn’t a minor inconvenience to work around; it’s an instruction they may have no physical way to follow at all.

An orientation lock that hides content assumes every visitor can freely reorient their device on demand, which is true for most users most of the time but categorically false for this specific group. The failure mode isn’t degraded usability; it’s a hard wall between the user and the content, with no workaround available on their end, only on the site’s.

Who is affected?

• Motor impairments: a device mounted in a fixed position, common for wheelchair users and people with limited mobility using a mounted tablet or phone holder, cannot be rotated on demand, so an orientation-locked page can remove access entirely rather than degrade it.
• Low vision users: some screen-magnification setups and mounted-device configurations for low-vision users are also fixed to a specific orientation for the same physical reasons, and hit the identical access barrier.

What users experience

Deshawn has cerebral palsy and uses a wheelchair with a tablet mounted on a fixed arm at a landscape angle he calibrated with an occupational therapist for optimal reach and viewing distance; the mount does not rotate. He opens his bank’s mobile web app to check a balance, and the app’s CSS includes @media (orientation: portrait) { .account-summary { display: none; } }, apparently written on the assumption that “mobile” means “portrait.” Because his tablet is fixed in landscape, the entire account summary section never renders for him at all, and there is no in-app message explaining why or any way for him to work around it from his side.

How do I fix it?

Remove any CSS that hides or blocks content based on orientation, and build the layout to adapt (reflow, restyle, or reposition) in both portrait and landscape instead of restricting one. This works because a responsive layout that handles both orientations removes the access barrier at its source, rather than depending on every visitor being able to freely rotate their device.

Start by auditing every @media (orientation: ...) rule in the codebase for display: none, visibility: hidden, or any interaction-blocking property, and replace it with layout adaptations (a different grid arrangement, resized elements, repositioned navigation) that keep the same content and functionality reachable regardless of orientation. If a component is genuinely orientation-essential under WCAG’s narrow exception, document that decision explicitly rather than defaulting to a lock out of convenience.

Code Examples

/* Hides the entire account summary in portrait - blocks access */
@media (orientation: portrait) {
  .account-summary {
    display: none;
  }
}

/* Adapts the layout instead of hiding content */
@media (orientation: portrait) {
  .account-summary {
    flex-direction: column;
  }
}

@media (orientation: landscape) {
  .account-summary {
    flex-direction: row;
  }
}

The original rule removes the account summary from the accessibility tree and the visual page entirely whenever the device is in portrait, which is a hard access failure, not a styling choice. The fixed version keeps the same content present in both orientations and only changes how it’s arranged (a stacked column in portrait, a row layout in landscape), so nothing depends on the user being able to rotate their device.

Common Mistakes

Mistake: “We show a ‘please rotate your device’ message, so users aren’t left with nothing.” A rotate-prompt message still blocks access to the actual content for anyone unable to rotate their device; it communicates the barrier more politely, but it doesn’t remove it. The fix is a layout that works in the orientation the user is actually in, not a more considerate way of telling them to change it.

Mistake: “Our orientation media queries only adjust font size and spacing, so this doesn’t apply to us.” This rule specifically targets rules that hide content or block interaction: adjusting typography or spacing per orientation is exactly the kind of responsive adaptation WCAG 1.3.4 permits and expects. Audit for display: none/visibility: hidden and interaction-blocking properties specifically, not every orientation media query on the page.

Mistake: “Mobile apps are always used in portrait, so a portrait-only design is a reasonable default.” This assumption is exactly what excludes fixed-mount landscape users: the “most common” orientation for most users is not the same as “the only orientation any user can be in.” Build for both regardless of which orientation is statistically more common among your general audience.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s css-orientation-lock rule as part of every scan. Because this rule falls outside axe-core’s default WCAG 2.0/2.1/2.2 A/AA tag set on its own, RedFlag explicitly force-enables it alongside five other rules so it still runs on every scan. The rule inspects stylesheets for @media (orientation: ...) blocks that apply styles restricting content visibility or interaction, based on static CSS analysis.

False negative: the check analyzes CSS rules statically and can miss orientation-locking behavior implemented through JavaScript: a script that listens for an orientationchange event and conditionally hides content via inline styles or class toggles isn’t parsed the same way as a stylesheet rule, so it can slip past this check. False positive: an orientation media query that only adjusts non-blocking properties (font size, padding, grid arrangement) without hiding or disabling anything can occasionally be flagged for review depending on how axe-core’s heuristic interprets the specific properties involved; confirm the actual rendered behavior in both orientations rather than trusting the flag alone. Manual step: physically rotate a real device (or use browser DevTools’ device toolbar rotation control) and confirm all content and functionality remain available and operable in both orientations.

Manual Testing

1. Open the page on a physical mobile device or tablet, or use Chrome DevTools’ device toolbar with the rotation icon.
2. View the page in portrait orientation and confirm all expected content, navigation, and controls are visible and operable.
3. Rotate to landscape (or toggle DevTools’ rotation) and repeat the same check: confirm nothing that was present in portrait has disappeared or become non-interactive.
4. Search the page’s stylesheets for orientation: media queries and review each one for display: none, visibility: hidden, or disabled/non-interactive states applied conditionally by orientation.

Related WCAG Success Criteria

1.3.4 Orientation: Content must not restrict its view or operation to a single display orientation, such as portrait or landscape, unless a specific orientation is essential. This rule is a direct check of CSS rules that create exactly that restriction.

Related Issues

UI component has insufficient contrast and Interactive element is too small to tap accurately share this rule’s focus on physical and motor access to controls, though they address visibility and tap precision rather than orientation.

Page animations have no reduced motion alternative and Text spacing overrides break the layout are other CSS-driven checks worth auditing together, since all three concern whether a page’s presentation layer adapts to a user’s actual physical circumstances rather than assuming a single default context.

Page uses meta refresh with a time limit and Content flashes more than 3 times per second round out this cluster’s focus on giving users control over how content presents itself over time and space, rather than forcing one fixed presentation on every visitor.

Viewport zoom is disabled is another page-level presentation restriction in the same family: where this rule locks a device’s rotation, that one blocks pinch-zoom, and both remove a physical input mechanism low-vision and motor-impaired users depend on.

References

• W3C Understanding 1.3.4: Orientation
• MDN: orientation (CSS media feature)