WCAG 1.3.4: Orientation
“Please rotate your device” assumes the user can. Many cannot — their tablet is mounted to a wheelchair, a bed frame, or an arm stand in one fixed position. This criterion is direct: content must display and operate in both portrait and landscape, unless a specific orientation is genuinely essential to what the content does.
The success criterion, in full
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.
Note the pairing: view and operation. It is not enough that content technically renders when rotated — it must also remain usable. And the exception is deliberately narrow: essential means the content cannot fulfill its purpose in the other orientation, not that one orientation was designed first.
Who this helps
This criterion exists because for a significant group of users, device orientation is not a preference — it is fixed by their equipment:
People with mounted devices
Wheelchair users commonly have a phone or tablet fixed to the chair; others mount devices to beds, desks, or hospital equipment. The mount's orientation is the orientation.
People with limited dexterity or strength
Rotating a device requires grip, wrist rotation, and coordination. For users with tremor, arthritis, paralysis, or limb difference, a forced rotation can be difficult or impossible.
People with low vision
Some users deliberately choose landscape for longer line lengths at large text sizes. A portrait-locked experience takes that adaptation away.
Everyone with a propped-up device
A phone in a car mount, a tablet in a kitchen stand, a device lying flat where auto-rotate misfires — orientation flexibility is universal design in the most literal sense.
The requirement and the essential exception
The rule covers both halves of the user experience in each orientation:
- View: all content renders in both orientations. No orientation shows a blocking overlay, blank screen, sideways layout, or cut-off regions with no way to reach them.
- Operation: every task can be completed in both orientations. Controls remain reachable and usable — a visible layout with an unreachable submit button still fails.
- No forced lock: the content itself must not pin the orientation via the Screen Orientation API, app-manifest orientation settings, or CSS that only functions one way.
When is an orientation “essential”?
Rarely. The Understanding document offers a short list of the kind of content that qualifies: a bank check capture screen (checks have a fixed landscape geometry), a piano keyboard application (a playable keyboard needs landscape width), projector slides, and some virtual reality content. Even then, scope the lock to the specific screen that needs it — the check capture view, not the whole banking app.
What does not qualify: brand preference, an unfinished landscape layout, “most users hold their phones this way,” or a game that was simply designed portrait-first. If the purpose of the content survives rotation, the orientation is not essential.
Pass and fail examples
- Pass — Responsive app that reflows on rotation. A messaging app shows a single conversation column in portrait and adds the conversation list beside it in landscape. Different layouts, same content and functions — exactly what the criterion intends.
- Pass — Check-deposit capture screen locked to landscape. A banking app locks only its check-photo screen to landscape because a check's fixed aspect ratio makes landscape capture essential. The rest of the app works in both orientations.
- Fail — 'Please rotate your device' overlay. A dashboard shows a full-screen overlay in portrait telling users to switch to landscape, hiding all content behind it. Users with mounted devices can never get past it.
- Fail — Web app calls screen.orientation.lock('portrait'). A quiz app locks itself to portrait for visual polish. On a landscape-mounted tablet the content renders sideways, restricting view and operation to one orientation without an essential reason.
- Fail — Landscape hides the submit button. A form works in portrait, but in landscape a fixed header and keyboard leave the submit button unreachable and non-scrollable. The orientation isn't blocked, but operation in it is — still a failure.
Code examples
Adapt with orientation media queries — never block
The orientation media feature is your friend when used to rearrange content, and a failure when used to hide it.
/* ✗ Failing: portrait users get a wall instead of the app */
@media (orientation: portrait) {
.app { display: none; }
.rotate-nag { display: flex; } /* "Please rotate your device" */
}
/* ✓ Passing: both orientations work; layout adapts */
.gallery {
display: grid;
grid-template-columns: 1fr; /* portrait: single column */
}
@media (orientation: landscape) {
.gallery {
grid-template-columns: 1fr 1fr; /* landscape: two columns */
}
}Don’t lock orientation in JavaScript or the manifest
Search your codebase for these — they are the programmatic versions of the rotate-your-device wall.
// ✗ Failing: hard-locks a general-purpose app to portrait
await screen.orientation.lock("portrait");
/* ✗ Failing: PWA manifest pinning every screen to one orientation */
{
"name": "My App",
"display": "standalone",
"orientation": "portrait"
}
/* ✓ Passing: let the platform rotate freely */
{
"name": "My App",
"display": "standalone"
/* omit "orientation", or use "any" */
}Design for short viewports, not just narrow ones
Most landscape breakage is really a short-viewport bug: a phone in landscape is ~400px tall, and fixed headers plus non-scrolling containers swallow the content. Test with height, not only width.
/* ✓ Keep tall fixed chrome from eating short landscape viewports */
@media (orientation: landscape) and (max-height: 500px) {
.site-header { position: static; } /* stop pinning the header */
.modal {
max-height: 90dvh; /* dynamic viewport height */
overflow-y: auto; /* content scrolls, not vanishes */
}
}Common failures
- Full-screen 'please rotate your device' overlays that hide all content in one orientation.
- Calling screen.orientation.lock() (or equivalent wrapper APIs) to pin a general-purpose app to one orientation.
- Setting "orientation": "portrait" (or landscape) in a PWA or hybrid app manifest without an essential reason.
- Modals and menus that cannot scroll in landscape on phones, leaving confirm buttons below a short viewport with no way to reach them.
- Fixed headers, footers, and cookie banners that together consume a short landscape viewport, hiding the actual content.
- Interactive canvases or games that only wire up touch coordinates for one orientation and misregister taps in the other.
- Claiming 'essential' for what is really a design preference — a portrait-first layout is a choice, not an essential orientation.
- Testing rotation only on the home screen: the failure is usually three screens deep, in the checkout modal or the video player.
How to test for 1.3.4
- 1
Rotate a real device through your key journeys
With auto-rotate on, walk the critical flows — sign-up, search, checkout, media playback — in portrait, then repeat in landscape. Every step must be completable both ways.
- 2
Look for blocking behavior, not just broken layout
Watch specifically for rotate-nag overlays, blank screens, sideways-rendered content, and screens that snap back or refuse to rotate. Any content-imposed restriction is a failure candidate.
- 3
Check operation in the risky spots
In each orientation, open modals, dropdowns, and on-screen-keyboard flows. Confirm buttons remain reachable (scrolling counts) and nothing interactive is trapped off-screen in the short landscape viewport.
- 4
Audit the code for locks
Search for screen.orientation.lock, orientationchange hacks, "orientation" keys in web app manifests, and @media (orientation: …) blocks that set display: none on primary content. Each hit needs an essential justification or a fix.
- 5
Use emulators for breadth, hardware for truth
DevTools device mode's rotate toggle catches CSS-level problems fast across many viewport sizes. But manifest and API locks only manifest on real devices or installed PWAs, so finish on hardware.
Orientation problems cluster with the other responsive criteria — if a screen fails here it often fails 1.4.10 Reflow too. Track both in the WCAG 2.2 checklist.
Frequently asked questions
What does WCAG 1.3.4 Orientation require?
It 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 other words: whichever way the user's device is turned, your content must display and function. You do not have to make both orientations look identical — layouts can and should adapt — but you cannot lock users into one orientation or show a 'please rotate your device' wall. It was introduced in WCAG 2.1 at Level AA and is unchanged in WCAG 2.2.
Who is harmed when a site forces one orientation?
Chiefly people whose device orientation is fixed. Wheelchair users often have a phone or tablet mounted to the chair in a set orientation; people with limited hand or arm mobility may have a device mounted on a bed frame or stand they cannot easily adjust; some people with dexterity impairments physically cannot rotate a device quickly or at all. For them, 'just rotate your phone' is not an option — a portrait-locked app on a landscape-mounted tablet is simply unusable.
What counts as 'essential' under the orientation exception?
An orientation is essential only when the content fundamentally cannot serve its purpose the other way. The Understanding document's examples include a bank check for mobile deposit (checks have a fixed landscape aspect ratio) and a piano keyboard application (a usable keyboard needs landscape width). Slides projected for an audience and some VR content are also cited. What is never essential: your designer preferring portrait, the layout being 'not optimized' for landscape yet, or analytics saying most users hold phones vertically.
Does 1.3.4 mean both orientations must show the same layout?
No. Adapting the layout is encouraged — showing more columns in landscape, rearranging panels, moving navigation — as long as the same content and functionality are available and operable in both orientations. What fails is restriction: blocking one orientation, hiding content or controls in it, or rendering an interface that cannot actually be used when rotated. Responsive design that reflows with orientation is exactly the intended solution.
Is using the Screen Orientation API to lock orientation always a failure?
Locking the content to one orientation fails 1.3.4 unless the essential exception genuinely applies. Web apps can attempt screen.orientation.lock() (and hybrid/native wrappers have manifest settings like 'orientation': 'portrait'); using those to hard-lock a general-purpose app is the canonical failure. Note the flip side: if the user has locked their own device's orientation in system settings, that is the user's choice and not your failure — the criterion governs restrictions the content imposes.
How do I test 1.3.4 quickly?
On a real phone or tablet with device auto-rotate enabled, load each key screen and rotate between portrait and landscape. Verify all content is visible, nothing is cut off, no overlay demands a specific orientation, and every task can be completed both ways. In desktop DevTools, toggle the device emulator's rotate button for a fast first pass — but confirm on real hardware, because emulators don't run the native-wrapper or manifest-level locks that cause many real-world failures. Also grep the codebase for orientation.lock and orientation manifest keys.
Related Success Criteria
Information, structure, and relationships can be programmatically determined.
Content can be presented in a meaningful sequence without losing meaning.
Instructions don't rely solely on sensory characteristics of components.
The purpose of input fields can be programmatically determined.
The purpose of User Interface Components can be programmatically determined.