Orientation Lock and Mobile E-Commerce: What WCAG SC 1.3.4 Actually Requires
Quick answer: WCAG SC 1.3.4 Orientation (Level AA) requires that “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 practice, that means a mobile checkout, product page, or video overlay shouldn’t force a shopper into portrait or landscape and stop working (or stop being viewable) in the other orientation. The two ways sites end up doing this anyway are a CSS trick that locks the layout to one orientation, and a JavaScript call to the Screen Orientation API that locks the whole page — and the fix for both is the same: don’t lock it, unless the content genuinely can’t work any other way.
This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.1 AA requires for this pattern and how to meet it, not whether a specific implementation carries legal risk.
Why this criterion exists
The Understanding doc’s Intent section is specific about who this protects, in its own words: “Some users have their devices mounted in a fixed orientation (e.g. on the arm of a power wheelchair). Therefore, websites and applications need to support both orientations by not restricting the orientation.” A tablet mounted on a stand at a kiosk, or a device set up in a fixed rig, doesn’t rotate just because a website expects it to. If a site only renders correctly in portrait, a user whose device is fixed in landscape doesn’t get a worse version of the page — they get a page that’s sideways, or one that has blocked the content entirely and asked them to do something they physically can’t do.
That second case — a page that detects the “wrong” orientation and displays a message instead of the content — has its own name in the WCAG technique library: Failure F100, “Failure of Success Criterion 1.3.4 due to showing a message asking to reorient device.” It describes exactly the pattern most people picture when they think of “orientation lock” on the web: instead of the content adapting to whatever orientation the device is already in, the user is told to adapt to the content.
The two ways this actually gets built
CSS media-query locking. The older, more mechanical version of this failure uses a
@media (orientation: ...) query paired with a CSS transform to force the page to render
sideways, or simply never styles a landscape layout at all and shows a blocking overlay instead.
Failure Technique F97 names this
directly, with its own worked example: “A news app always shows the content in portrait
orientation… When the device is turned to landscape view, the content appears sideways to the
user.”
The Screen Orientation API. The more deliberate version uses
screen.orientation.lock(),
a JavaScript method that locks the whole document to a named orientation ("portrait",
"landscape", "portrait-primary", and so on). Per MDN’s own reference, it only works inside a
fullscreen context and is mobile-only — support isn’t Baseline, meaning it doesn’t work
consistently across browsers even where it’s implemented. This is the mechanism behind a
fullscreen product-demo video or an in-browser AR “view in your space” feature that snaps to
landscape the moment it opens fullscreen, with no button to get back to portrait short of exiting
fullscreen entirely.
Neither mechanism is inherently disqualifying on its own — the criterion isn’t “never use these APIs,” it’s “don’t use them to prevent a user from viewing or operating the content in their actual orientation” unless that orientation is essential.
What actually satisfies this
The Understanding doc names its own essential-exception examples, and they’re narrow: a banking app’s check-deposit camera view (checks are “about twice as wide as they are high,” so landscape is genuinely required to capture one), a piano app needing landscape width for the keys to be usable, slides built for a projector or television, and virtual reality content shown through goggles that don’t rotate. It also names three compliant examples on the other side: a video site that plays in whatever orientation the user has, a messaging app that works in both, and an eReader that renders a book’s content either way.
None of the exception examples are e-commerce-shaped, and that’s worth sitting with rather than stretching to force a fit. A responsive product page, a checkout form, and a size-guide table have no structural reason to require one orientation — they’re exactly the kind of content the compliant “video site” and “messaging app” examples are meant to generalize from.
If a genuine restriction can’t be avoided, Technique G214 describes the fallback: “when the orientation of the page is locked, provide a button to allow a user to change the orientation.” A fullscreen AR try-on view that only renders in landscape should at minimum offer a visible control to unlock it — not just an exit-fullscreen gesture a shopper has to already know exists.
Where this shows up on an e-commerce site
Applying the criterion to three common patterns, as my own reading rather than anything the Understanding doc names directly:
- A checkout or account flow that shows a “please rotate your device” screen on landscape instead of reflowing the form — the exact F100 pattern, just relocated from a news app to a payment form.
- A fullscreen product-demo or AR “view in your space” video that locks to landscape via the Screen Orientation API with no visible control to exit that orientation short of leaving fullscreen — see Making Product Videos Accessible for the captioning and audio-description side of the same video content.
- A zoom or lightbox overlay (see Making Product Image Galleries and Zoom Accessible) that’s hard-coded to a portrait aspect ratio and clips or distorts the image if the device is rotated, rather than reflowing the zoomed view.
Can an automated scanner catch this?
Partly, and the scope is narrow enough to matter. axe-core ships a real rule for this,
css-orientation-lock, and its own metadata — fetched directly from the rule’s source file rather
than a summarized description — states the check plainly: "help": "CSS Media queries must not lock display orientation". The rule is also tagged experimental, Deque’s own marker that it
isn’t considered fully reliable yet.
The scope matters more than the reliability caveat: the rule’s help text says CSS media queries,
specifically. It has no way to detect a lock applied through the Screen Orientation API in
JavaScript, since that’s a runtime behavior — the DOM and CSS a static scanner reads don’t show
that a script is going to call lock() once the page goes fullscreen. A page that locks
orientation via screen.orientation.lock() can pass this rule cleanly and still fail SC 1.3.4.
The only way to catch that is the same manual step the technique’s own test procedure describes:
open the page in landscape, open it in portrait, and check that both actually work.
FAQ
Does a responsive site automatically satisfy this criterion? Yes, in the sense that matters — the criterion isn’t about layouts looking identical in both orientations, it’s about the content remaining viewable and operable in whichever orientation the device is actually in. A page that reflows differently in portrait versus landscape passes; a page that becomes unusable or gets replaced with a “please rotate” message in one of them fails.
Is locking a fullscreen product video to landscape ever fine? Only if that orientation is essential to the content itself, the same narrow bar as the Understanding doc’s own examples (a check-deposit camera, a piano keyboard). A standard product demo or unboxing video isn’t in that category — it’s the direct analog of the doc’s own compliant “online video site” example, which plays in whichever orientation the user has. If landscape is kept for a genuinely wider viewing experience, G214’s fallback control is the way to stay compliant rather than locking silently.
Does this only apply to native mobile apps? No — the Understanding doc’s scope is “Web pages,” and both mechanisms described above (CSS media queries, the Screen Orientation API) are web technologies, not native app frameworks. Anything rendered in a mobile browser is in scope.
Get a human-reviewed audit, not just a scan
An automated scanner catches an orientation lock built with CSS media queries — it can’t see one built with the Screen Orientation API, because that’s a runtime behavior, not a static markup pattern. Quietramp’s audits pair an automated scan with a manual review that actually rotates the page and checks both orientations, delivered as a prioritized, developer-actionable PDF report. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.
This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA does not resolve ADA or any other legal compliance question, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.
This article was drafted with AI assistance and reviewed by a person for accuracy before publication.