screen-orientation-consistency
Mobile validation
When content is obscured, covered, or unavailable after the device is rotated, the experience is poor for everyone. For some people it is a complete barrier: users of assistive technologies that support only one orientation, and people who cannot rotate their device, for example because it is mounted on a wheelchair, may be unable to perceive or operate the app. Make sure all content and controls are available and operable in both portrait and landscape orientations. When less space is available, let the content scroll or reflow instead of cutting it off.
Note: This validation covers content that is lost or blocked after rotating. Locking a screen to a single orientation is covered by the related screen-orientation-lock validation.
Pass Patterns
Content that scrolls in landscape
A sign-up form fits on the screen in portrait. In landscape, the form scrolls, so every field and the “Continue” button can still be reached.
Content that rearranges in landscape
A product screen shows its image above the details in portrait, and next to them in landscape. All the same content and controls are available in both orientations.
Fail Patterns
Control pushed off the screen
In landscape, the “Continue” button at the bottom of a sign-up form is pushed off the screen, and the form does not scroll, so users cannot reach it.
Content covered after rotating
In landscape, a fixed banner covers part of a form, so some fields are hidden and cannot be reached.
Try It Yourself
Rotating the device
- Make sure rotation is allowed in the device settings, by turning off the portrait orientation lock.
- Open the app, and go to the screen you want to check.
- Rotate the device from portrait to landscape, and then back to portrait.
- In each orientation, check that you can see, reach, and operate all the content and controls.
Expected results: The screen rotates, and the same content and controls are available and operable in both orientations.
Actual results: In one of the orientations, some content or controls are cut off, covered, or cannot be reached.
FAQ
How does this issue relate to 1.3.4 Orientation?
SC 1.3.4 requires that content is not restricted to a single display orientation, such as portrait or landscape, unless a specific orientation is essential. When content or controls are lost or blocked in one orientation, that content is effectively available in only one orientation, so the criterion is not met.
How does this issue relate to 1.4.10 Reflow
This issue aligns with 1.4.10 Reflow because rotating the device changes the available space. Reflow requires that content and controls remain available and operable when the viewport changes. If items become lost, blocked, or overlapped after rotation, the app does not meet 1.4.10.
Design for both orientations so layouts adapt. When space is limited, let content reflow or scroll instead of clipping or covering elements. All controls must stay reachable and usable after rotation.
Why is this issue marked as Serious?
When content or controls are lost in one orientation, people who cannot change their device's orientation may be unable to use part of the app at all. For other users, it forces them to rotate the device just to complete a task, so it is rated serious.
Standards and Regulations
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 1.3.4 Orientation (AA) | Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific orientation is essential. |
| WCAG 2.2 | 1.4.10 Reflow (AA) | Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions, at a width of 320 CSS pixels or a height of 256 CSS pixels, except for parts of content that require two-dimensional layout for usage or meaning. |
| EN 301 549 | 11.1.3.4 Orientation | Same as the WCAG text. |
| EN 301 549 | 11.1.4.10 Reflow | Same as the WCAG text. |