1.3.4 Orientation
- Level AA
- Perceivable
- Since WCAG 2.1
Summary
This criterion protects people who cannot rotate their device to match the content. The clearest example is a wheelchair user whose phone or tablet is mounted to the chair in a fixed orientation: if an app only works in portrait and the mount holds the device in landscape, the app is unusable. The same barrier affects people with limited dexterity who find physically rotating a device difficult, and anyone using a device fixed to a stand, an arm, or a bed frame. New at Level AA in WCAG 2.1, and it applies unchanged to both web content and software under the European standard.
The auditor's mental model is simple: rotate the device and check that every screen still displays and operates. You are grading whether the content works at all in each orientation, not whether the second orientation is beautifully optimised (a stretched portrait layout that remains fully usable in landscape passes). The essential exception is deliberately narrow: a piano keyboard app that needs landscape width, or a cheque deposit capture screen where the camera framing genuinely requires one orientation, qualifies; "we only designed the portrait layout" does not.
Official wording
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.
EN 301 549 mapping
- Web pages
- Clause 9.1.3.4
- Software and native apps
- Clause 11.1.3.4
Clauses 9.1.3.4 (web) and 11.1.3.4 (software) apply this criterion unchanged, so the same requirement binds web pages and native app user interfaces.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
The web rarely fails this criterion by default, because browsers rotate the viewport with the device and responsive layouts follow. Where web content fails, an author has actively fought that behaviour: a JavaScript or CSS orientation check that replaces the page with a "please rotate your device" overlay, a web app or game calling the Screen Orientation API's lock method in full screen, or a kiosk-style layout that hides content when orientation: landscape (or portrait) matches in a media query.
Test on a real device with the device's own rotation lock switched off: load the key pages, rotate, and confirm content and functionality remain available in both orientations. In desktop devtools, the device toolbar's rotate button simulates the dimension change and will surface orientation media queries; search the CSS for orientation: media queries and the scripts for screen.orientation.lock or orientation-change handlers that gate content. A non-blocking hint suggesting a better orientation is fine, as long as everything still works if the user ignores it.
iOS
This is where the criterion earns its keep. The classic fail is an app whose UISupportedInterfaceOrientations (Info.plist, or the target's General settings in Xcode) lists only portrait: every screen is then locked regardless of how the user holds or mounts the device. Apps can also lock per screen via supportedInterfaceOrientations overrides on view controllers, or at the scene level in SwiftUI apps, so a mostly rotating app can still fail on individual screens.
Test on a physical device with Control Centre's rotation lock OFF (with the user's own rotation lock on, nothing rotates and the test is void). Walk every audited screen in portrait and landscape and note any screen that refuses to rotate. If you have the project or the IPA, checking the plist keys is quick corroborating evidence, but the on-device rotation pass is the test. Be honest in grading: a very large share of production iOS apps ship portrait-locked as a design convention, and under the European standard that is a genuine, frequently failed AA requirement, not a nitpick. iPad multitasking pressure means many iPad apps already rotate; the fails cluster on iPhone-only apps.
Android
The Android equivalent is android:screenOrientation="portrait" (or "landscape") set on activities in the manifest, or setRequestedOrientation called at runtime; in Compose apps the lock still lives at the activity level, so one manifest attribute can pin every composable screen it hosts. As on iOS, locks can be per activity, so test every screen rather than assuming the first one speaks for the app.
Test on a device with auto-rotate enabled in quick settings (and check the system accessibility rotation setting is not pinning orientation itself). Rotate on each audited screen and confirm the layout re-renders and remains operable. With the APK available, inspecting the manifest for screenOrientation attributes tells you exactly which activities are locked; Android Studio's Layout Inspector can confirm which activity a suspect screen belongs to. Watch for dialogs and media screens that rotate while their host screens do not, or vice versa: grade each screen on its own behaviour.
Pass and fail examples
Passes:
- A responsive website that reflows naturally when the device rotates, with no orientation media queries hiding content.
- An app that supports both orientations on every screen, even where the landscape layout is just the portrait layout stretched: operation is preserved, and layout polish is not what this criterion grades.
- A piano keyboard app locked to landscape: the width of the keyboard makes a specific orientation essential.
- A banking app's cheque deposit capture screen locked to match the cheque's aspect ratio, while the rest of the app rotates freely: essential exception, applied narrowly to the one screen that needs it.
Fails:
- An iOS app with
UISupportedInterfaceOrientationsrestricted to portrait for the whole app, with no essential justification for any screen. - An Android app with
android:screenOrientation="portrait"on ordinary content activities such as settings, lists, and forms. - A web page that detects landscape and replaces the content with a full-screen "please rotate your device to portrait" message.
- A web game that calls the Screen Orientation API to lock landscape for menus and settings screens that have no essential orientation need, not just gameplay.
Not a fail under this criterion:
- A landscape layout that works but becomes cramped, or clips content at high zoom: grade layout adaptation under SC 1.4.10 Reflow, not here.
- Nothing rotating because the user's own device rotation lock is on: that is the user's setting, not the author restricting orientation. Retest with the lock off.
- Different layouts or component arrangements per orientation: the criterion permits presentation to change, provided view and operation are preserved in both.
- A dismissible banner suggesting landscape gives a better experience, while everything remains fully usable in portrait.
Commonly confused with
- Reflow, SC 1.4.10. Rotating a device changes the viewport dimensions, so the two often get filed together. Reflow is about content adapting to a narrow width (equivalent to 400% zoom) without two-dimensional scrolling; orientation is about whether the author blocks a display orientation at all. A page that rotates but scrolls horizontally in landscape is a reflow question; a page that refuses to rotate is an orientation fail.
- Motion Actuation, SC 2.5.4. That criterion covers shaking or tilting the device as an input method (undo by shake, tilt to steer) and requires conventional alternatives. Orientation is about the display: which way up the content renders. Tilting into landscape and having the screen rotate is not motion-actuated functionality.
- User rotation lock versus author lock. Only author-imposed restriction fails. If the OS-level rotation lock is on, or an OS accessibility setting pins the orientation, the content is not restricting anything. Always confirm device settings before recording a fail.
- Essential orientation versus preferred orientation. "This screen was designed for portrait" is a preference; the essential exception needs the orientation to be intrinsic to the task, as with a landscape-only instrument or a document capture frame. When in doubt, ask whether the function is impossible, not merely less polished, in the other orientation.
How AUDITSU tests this
AUDITSU's audit walkthrough asks the orientation question on every screen you review: rotate the device (rotation lock off), confirm the screen still displays and operates, and record pass, fail, or not applicable with evidence attached, such as a screenshot of the screen refusing to rotate or the blocking "please rotate" overlay. Because locks can be applied per screen or per activity, the per-screen structure catches the mixed apps that a single app-level check would miss, and the essential exception is recorded as a justification on the specific screen that claims it.
The criterion applies unchanged to web and software under the European standard, so in audits targeting the European Accessibility Act a portrait-locked app is graded as a full AA failure, however common the convention.
For the full guided workflow, see the audit platform.