WCAG 1.3.4 Orientation requires that your website work in both portrait and landscape and never force users into a single rotation — unless one orientation is genuinely essential. If turning a phone sideways breaks your layout, leaves content stuck the wrong way, or triggers a “please rotate your device” message, you fail this Level AA checkpoint.

What 1.3.4 Orientation requires

The normative text from the W3C Web Accessibility Initiative is short: “Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.”

In plain terms: the user — not your site — decides whether they browse upright or sideways. Your job is to let the layout reflow to whichever orientation the device is in. This is a new criterion in WCAG 2.1, set at conformance level AA, which is the level most ADA web claims are measured against.

The exception is narrow. Orientation can be locked only when a single view is essential to the content. W3C’s own examples are a bank check (printed wider than tall), a piano app that needs landscape for playable key spacing, slides for a projector, and virtual-reality content. A storefront, restaurant menu, contact form, or booking flow has no essential reason to lock orientation — so for almost every small-business site, the exception does not apply.

One clarification that trips people up: 1.3.4 is about restricting orientation, not about layout changing with screen size. A different layout in landscape is fine. Refusing to show content in landscape is the violation.

Who it affects

Locking orientation is one of the few accessibility failures that hurts users who otherwise have a perfectly usable, well-built page. Per the W3C Understanding document, the people harmed are:

  • People with dexterity or motor disabilities whose device is physically mounted in a fixed position — for example, a phone or tablet clamped to the arm of a power wheelchair. They cannot rotate the device to “match” your locked layout, so if you only support portrait and their mount is landscape, your content is unreachable.
  • Low-vision users who deliberately browse in landscape to enlarge text and fit more readable content across the screen. Force them back to portrait and you take away their magnification strategy.

It also affects ordinary users in mundane ways — anyone holding a tablet in a stand, reading on a kickstand case, or filling out a long form they’d rather complete in landscape. Unlike many WCAG criteria, this one isn’t mediated by a screen reader; it’s about the raw ability to view and operate your content in the orientation the person has chosen.

Concrete failures and the fix

The W3C documents two specific failures for this criterion. Here’s what each looks like in real code, and how to correct it.

Failure F97 — locking orientation with CSS

The classic violation is a CSS orientation media query that uses a transform to force one view. A site detects landscape, then rotates the whole page back to portrait so it “looks right”:

/* FAILS 1.3.4 — forces portrait by rotating the page */
@media screen and (orientation: landscape) {
  html {
    transform: rotate(-90deg);
    transform-origin: left top;
    width: 100vh;
    height: 100vw;
    overflow: hidden;
    position: absolute;
    top: 100%;
  }
}

This is F97: failure due to locking the orientation to landscape or portrait view. It hijacks the user’s choice and usually leaves scrolling and tap targets misaligned.

The fix is to delete the lock and let the layout respond. Use orientation (or width) media queries to adjust the design, never to reject an orientation:

/* PASSES 1.3.4 — adapts to each orientation instead of blocking one */
@media screen and (orientation: landscape) {
  .gallery { grid-template-columns: repeat(3, 1fr); }
}
@media screen and (orientation: portrait) {
  .gallery { grid-template-columns: 1fr; }
}

On native or installable web apps, the same lock often lives in a web-app manifest. Change a fixed value like "orientation": "portrait" to "orientation": "any" (or remove the key) so the OS lets the user rotate.

Failure F100 — telling users to rotate

The second documented violation, F100, is showing an overlay that says “Please rotate your device to portrait mode to continue.” Blocking the experience behind a rotation demand is itself a failure — even if the underlying layout could have reflowed. Remove the interstitial and let both orientations work.

If — and only if — an orientation truly is essential, the sufficient technique G214 is to provide a control that lets the user access the content in the other orientation anyway, rather than hard-blocking it.

How to test it

You don’t need specialized software to catch most 1.3.4 problems:

  1. Rotate a real device. Open each key page and complete each key flow (browse, add to cart, fill the form, check out) on an actual phone and tablet, rotating between portrait and landscape. The content should reflow and stay fully operable both ways.
  2. Watch for the three tells: the layout stays sideways, content refuses to reflow or gets clipped, or a “rotate your device” message appears. Any of those is a fail.
  3. Use the browser emulator. Chrome and Edge DevTools device toolbar has a rotate button; toggle orientation while inspecting.
  4. Search the code. Grep your CSS for orientation: media queries combined with transform: rotate(, and check any manifest.json for a fixed orientation value. These are the usual culprits behind F97.
  5. Check the ACT rule. W3C’s automated-testing rule for this criterion is literally “Orientation of the page is not restricted using CSS transforms,” which is what most scanners look for.

Automated scanners catch the CSS-transform pattern but routinely miss app-manifest locks and JavaScript that calls screen.orientation.lock(). That gap is exactly why thorough work pairs tooling with hands-on review during an accessibility audit.

Why orientation matters legally

Orientation is, above all, a mobile failure — and mobile is where the traffic and the lawsuits now live. Roughly 60% of global web traffic comes from phones (StatCounter, via Statista), so a layout that refuses to rotate breaks the experience for the majority of visitors and the majority of plaintiffs’ testers, who file from a phone. UsableNet counted 4,187 digital accessibility lawsuits in 2024 (UsableNet 2024 Year-End Report) and reported the total climbing past 5,000 in 2025, including 3,117 federal website cases, a 27% jump (UsableNet 2025 Year-End Report). A growing share of those federal filings now come from self-represented testers using automated scanners — and a forced-orientation overlay or a transform: rotate() lock is exactly the kind of pattern an automated ACT-rule check flags in seconds.

What makes 1.3.4 distinct from most criteria a demand letter lists is where the defect lives. A locked orientation is rarely a one-line alt-text miss — it’s a manifest.json key, a screen.orientation.lock() call, or a CSS transform baked into the build, so it tends to fail the same way on every page and is trivial to reproduce and document in a complaint. Courts and the U.S. Department of Justice continue to treat WCAG 2.1 AA as the practical yardstick for an accessible site under the ADA, and 1.3.4 — added at exactly that level — sits squarely inside it. For broader context on how these cases unfold, see ADA website lawsuits and how to avoid one.

This is general information, not legal advice. A forced-orientation lock that’s “essential” for one app (a piano keyboard, a VR view) may be a clear violation on a storefront — for how the essential exception applies to your specific build, consult a qualified accessibility attorney.

Fixing orientation the right way

An orientation lock is the clearest case there is for why overlays don’t work. The restriction never lives in the page’s visible content — it lives one layer down, in a @media (orientation: landscape) transform, an "orientation": "portrait" line in your manifest.json, or a screen.orientation.lock() call that fires before any overlay script even loads. An accessibility widget runs inside the locked page; it cannot unlock the viewport, rewrite the manifest the OS already read, or reach a native orientation API. That’s why we’re deliberately anti-overlay: the only real fix is to correct the source.

Our hands-on remediation for this criterion is specific and short: locate every lock (CSS transform, manifest key, and JS call — the three places scanners routinely miss two of), delete the lock, replace any blocking media query with a responsive one that adapts each orientation instead of rejecting it, and then re-test on a real phone and tablet so portrait and landscape both stay fully operable. If a single orientation genuinely is essential, we add the G214 control that lets users reach the content the other way rather than hard-blocking them. It’s the same source-level discipline we bring to keyboard navigation and sibling criteria like 1.4.3 Contrast (Minimum).

Not sure whether your site locks orientation anywhere? Start with a free scan — we’ll rotate your key pages, check your manifest and CSS, and flag rotation failures alongside everything else standing between you and WCAG 2.1 AA.