WCAG 1.3.4 — Orientation

What this requires

Content must not restrict its view or operation to a single display orientation, like portrait or landscape, unless a specific orientation is essential. Users with their device mounted in a fixed orientation — common for assistive setups — need both orientations to work. The rare exceptions (a piano-keyboard app, a cheque-deposit camera) genuinely require a specific orientation; almost no website does.

How AI coding tools fail this

When asked to "make this look right on mobile" or "lock to portrait for the onboarding flow", AI tools reach for CSS or JS that explicitly restricts orientation: screen.orientation.lock("portrait"), a @media (orientation: portrait) block with no landscape companion, or an "rotate your device" splash that hides all content in landscape.

The second pattern: layouts assembled with hard-coded 100vw and 100vh assumptions that break catastrophically in the other orientation — content cropped, controls offscreen, modals unreachable. The code doesn't lock orientation explicitly but the result is the same.

The third: pixel-perfect designs that assume portrait phone, where landscape just stretches everything past the viewport. The user can rotate, but the experience is unusable.

Failing examples

Programmatically locking orientation site-wide:

useEffect(() => {
  if ("orientation" in screen) {
    // eslint-disable-next-line
    (screen.orientation as any).lock?.("portrait");
  }
}, []);

A "please rotate your device" screen blocking access in landscape:

<>
  <main className="block landscape:hidden">{children}</main>
  <div className="hidden landscape:flex">
    Please rotate your device to portrait to continue.
  </div>
</>

Passing examples

A responsive layout that adapts to both orientations:

<main className="mx-auto grid w-full max-w-screen-md gap-4 p-4 sm:grid-cols-2">
  {children}
</main>

If you genuinely need an orientation for one essential step, scope the constraint to that step (not the whole site) and explain why:

<section aria-labelledby="cheque-heading">
  <h2 id="cheque-heading">Capture your cheque</h2>
  <p>
    This step uses your camera in landscape so the full cheque fits
    in frame. You can return to portrait after capture.
  </p>
  <CameraView mode="landscape" />
</section>

Edge cases

OS-level orientation locks (the user's system setting) are not the site's concern. The criterion bans the author restricting orientation, not the user choosing to.
"Essential" is narrow. A nicer layout is not essential. A cheque scan, a piano keyboard, or a virtual-reality scene that depends on physical rotation can be essential.
CSS responsive design at common breakpoints generally satisfies the criterion without any orientation-specific code.
@media (orientation: landscape) is fine as long as both orientations result in functional content.
Embedded games and 3rd-party content still count. If your page hosts an iframe that locks orientation, your page fails.

How Jeikin handles this

axe-core flags screen.orientation.lock and CSS rules that hide content in one orientation, mapping each to WCAG 1.3.4. The dashboard tracks each finding through resolution and records when an exception was approved (essential orientation for a specific step).