WCAG 2.2 success criterion, Level AA
WCAG 1.3.4 Orientation
Content must work whether the screen is held upright or sideways. Locking a page to portrait or landscape is only allowed when that orientation is essential.
- Number
- 1.3.4
- Level
- AA
- Added in
- WCAG 2.2
- Guideline
- 1.3 Adaptable
- Principle
- Perceivable
What it asks
Some people cannot turn their device. A tablet mounted on a wheelchair, a phone fixed to a bed frame, or a device in a stand sits in one orientation, and the person has to use whatever appears. A page that insists on landscape, or shows a "please rotate your device" message, has locked them out.
This rule says content must not restrict its view and operation to a single orientation. The content may look different in each one; a layout that reflows is fine. What it may not do is refuse to work, hide controls, or show a blocking message until the device is turned.
The exception is for content where a particular orientation is essential: a piano keyboard app, a bank cheque that must match a physical form, or a slide shown in the shape it was designed for. The exception has to be justified. "Our designer preferred portrait" is not essential.
The common causes are a CSS media query that hides the content or shows a rotate prompt in one orientation, a transform that rotates the whole page to force the other orientation, and script that reads the orientation and refuses to continue. Native app orientation locks are outside WCAG for web content, but a web app that mimics one is not.
Its official name is success criterion 1.3.4 Orientation, at Level AA. It was added in WCAG 2.2, under guideline 1.3 Adaptable and the principle Perceivable. The W3C’s normative text says, in part:
“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.”
From WCAG 2.2, W3C. Full explanation: Understanding 1.3.4 Orientation.
Who it helps
People with motor disabilities whose device is mounted in a fixed position, and people with low vision who hold a device in landscape to get larger text and a wider line. Anyone whose rotation lock is on, or whose device is in a stand or a car mount.
What passes and what fails
These pass
- A page that reflows between a single column in portrait and two columns in landscape, with everything reachable in both.
- A video player that shows the video at a different size in each orientation but plays in both.
- A form that is usable in both orientations, with the same fields and buttons.
- A piano practice app that is landscape only, because the keyboard layout is essential to it.
These fail
- A mobile web app that shows "Please rotate your device" in portrait and nothing else.
- A video editing page that works in landscape and hides its controls in portrait, with no portrait layout.
- A CSS rule that applies
transform: rotate(90deg)to the whole page in one orientation, to force the other. - A game page that locks itself to landscape through script, for a game that would work in either.
How to test it by hand
- Open the page on a phone or tablet, or in the browser’s device mode, in portrait.
- Use the page: read it, reach every control, complete its main task.
- Rotate to landscape and do the same.
- In each orientation, look for anything missing, any control that cannot be reached and any message asking you to rotate.
- Check the CSS for
orientationmedia queries that hide content or rotate the page, and script that reads the orientation. - If the page is locked to one orientation, ask whether that orientation is essential to the content, and write down the reason.
What automated testing can decide
What a machine can decide
A CSS lock is in the stylesheet, and automated testing can find one and report it as a failure. Automated testing can also view the page in both orientations and list the controls that exist in one and not the other.
What it cannot
Rotating a device changes the width of the page as well as its orientation, and most layouts respond to width. A control that disappears in portrait may be tucked behind a menu button rather than lost, which is ordinary responsive design. Automated testing can tell that something vanished; whether it vanished for good, and whether an orientation is essential to the content, needs a person.
How Dreven handles it
Dreven looks at your pages for content or controls that depend on one orientation and shows you what it found, with the page and a picture of it.
A reviewer decides each result, including whether any lock is essential, and the report records the decision. Nothing is assumed.
No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.
Related criteria
- 1.4.10 Reflow (Level AA). Content must reflow at narrow widths without scrolling in two directions.
- 1.4.4 Resize Text (Level AA). Text must be resizable to 200% without loss.
- 2.5.4 Motion Actuation (Level A). Functions triggered by moving the device need an alternative.
Questions people ask
Is a "please rotate your device" message a WCAG failure?
Yes, unless the orientation is essential to the content. A message that blocks the page until the device is turned restricts the content to one orientation, which is what 1.3.4 forbids.
Does the page have to look the same in portrait and landscape?
No. It can reflow and rearrange. It has to work in both: the same content and controls must be reachable, and nothing may block the page in one orientation.
What counts as an essential orientation?
One where the content cannot work the other way, such as a piano keyboard or a cheque that must match a printed form. The reason should be written down in the conformance report, not assumed.