Level AAWCAG 2.1

1.3.4 Orientation

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape.

Last reviewed: September 9, 2026

Understanding 1.3.4

Users with mobility impairments often mount their devices in a fixed orientation (e.g., on a wheelchair or stand) and cannot physically rotate them to match an app's assumed orientation. This criterion ensures content works in both portrait and landscape so users aren't locked out simply because their device is fixed in one orientation, unless a specific orientation is essential to the content (such as a piano app or a check-deposit camera view).

How to Meet It

Avoid using CSS or JavaScript to force a single orientation (e.g., the CSS Screen Orientation API's lock() method, or orientation media queries that hide content in one orientation). Design responsive layouts that work correctly in both portrait and landscape. Only restrict orientation when it is essential to the function, such as a piano-keyboard simulator or bank-check scanning.

Code Examples

INCORRECT

// Forces the app into landscape only, blocking users with a fixed-portrait mount
screen.orientation.lock('landscape');

CORRECT

// Let the layout respond to whichever orientation the device is in
// (use responsive CSS instead of locking orientation)

Frequently Asked Questions

Can I ever lock orientation?

Yes, but only when a specific orientation is essential to the content itself: for example, a piano app that needs a wide landscape keyboard, or a bank app's check-deposit camera screen. General content, dashboards, and forms should not be locked.

Related Success Criteria

1.3.1 Info and Relationships 1.3.2 Meaningful Sequence 1.3.3 Sensory Characteristics 1.3.5 Identify Input Purpose

Quick Facts

Criterion1.3.4
LevelAA
IntroducedWCAG 2.1

Automate Compliance

AccessiSight automatically scans and identifies 1.3.4 issues in your codebase.

Try Scanner Free