Category: Mobile Accessibility

Screen Orientation Lock

Also known as: Lock Rotation, Lock Screen Rotation, Orientation Lock, Lock Orientation

Simply put

Screen orientation lock is a setting or function that keeps a device's display fixed in a single orientation, such as portrait or landscape, so it does not rotate when the device is physically turned. Users can typically enable this on their own devices, for example through the Control Center on an iPhone or a rotation setting on Android. It can also be applied by a website or app, which may fix the display to a specific orientation for its content.

Formal definition

Screen orientation lock refers to both a user-controlled device setting and a programmatic web capability that constrains the display to a particular orientation. On the web platform, the Screen Orientation API (W3C) defines an OrientationLockType and a ScreenOrientation.lock() method that locks the containing document's orientation to a specified value, preventing automatic reorientation on device rotation. At the operating-system level, users can independently enable orientation lock (for example, the Lock Rotation control on iOS or comparable Android settings and utilities) to override an application's preferred orientation. From an accessibility perspective, developers should be cautious about programmatically forcing a single orientation, since restricting content to one orientation can create barriers for users who rely on a fixed device orientation, such as those using a mounted wheelchair device. Note that this entry describes technical behavior and is not legal advice; specific conformance obligations depend on the applicable standard and jurisdiction.

Why it matters

Screen orientation lock matters in accessibility because the orientation a user needs is not always the orientation a website or app prefers. Some people rely on a fixed device orientation for physical reasons, for example when a device is mounted to a wheelchair in a single position. If content is programmatically constrained to only portrait or only landscape, those users may be unable to rotate their device to a usable position, effectively locking them out of the content or forcing an awkward viewing angle.

The tension arises from two competing controls. A user can enable orientation lock at the operating-system level to keep the display fixed the way they need it, but a website or app can also use the web platform's Screen Orientation API to force its own preferred orientation. When developers force a single orientation without a functional reason, they can override the accommodation a user has set up for themselves. For this reason, developers should generally avoid restricting content to one orientation unless the orientation is essential to the content's function.

This entry describes device features and technical behavior rather than a specific legal obligation. Whether restricting orientation creates a compliance problem depends on the applicable standard and jurisdiction, and readers with legal questions should consult qualified counsel and review current requirements.

Who it's relevant to

Web and app developers

Developers deciding whether to call ScreenOrientation.lock() or otherwise constrain a document's orientation should weigh the accessibility impact. Forcing a single orientation can create barriers for users who depend on a fixed device orientation, so restricting content to one orientation is generally best reserved for cases where the orientation is essential to the content's function.

Users of assistive and mounted devices

People who rely on a fixed device orientation, such as those using a device mounted to a wheelchair in a single position, may be unable to accommodate content that forces a different orientation. The operating-system orientation lock lets these users keep the display in the position they need, but a site or app that forces its own orientation can undermine that setup.

Accessibility testers and QA teams

Testers should verify that content works in the orientation a user has locked and does not force a single orientation without a functional reason. Because behavior can differ between what an app prefers and what the user has set at the device level, manual testing with orientation lock enabled is useful for surfacing these conflicts.

UX designers

Designers planning layouts should consider that users may have orientation lock enabled for their own reasons. Designing content that adapts to both portrait and landscape, rather than assuming a preferred orientation, helps avoid barriers for users with fixed-orientation setups.

Inside Screen Orientation Lock

Screen Orientation Lock

A design or system behavior that restricts content display to a single orientation, either portrait or landscape, preventing the interface from adapting when a user rotates their device.

WCAG Success Criterion 1.3.4 Orientation

A Level AA success criterion added in WCAG 2.1 that generally requires content not to restrict its view and operation to a single display orientation, unless a specific orientation is essential.

Essential Exception

The provision within the orientation requirement recognizing that certain content may legitimately require a specific orientation, such as a piano application or check-depositing scenario, where the fixed orientation is essential to function.

Assistive Technology and Mounting Considerations

The accessibility rationale behind supporting both orientations, since some users have devices mounted in a fixed position (for example, on a wheelchair) and cannot easily rotate them to match a locked orientation.

Responsive and Adaptive Layout

The technical approach of allowing content to reflow and adjust to the available viewport so it remains usable in whichever orientation the user prefers or is able to use.

Common questions

Answers to the questions practitioners most commonly ask about Screen Orientation Lock.

Does locking a screen to a single orientation violate WCAG?

Not automatically. WCAG 2.1 Success Criterion 1.3.4 Orientation (Level AA) generally requires that content not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific orientation is essential. So an orientation lock is a concern where it is not essential, but the criterion itself recognizes exceptions. Because this is a WCAG success criterion rather than a codified ADA technical rule, how it factors into legal compliance in a given jurisdiction is a separate question best directed to qualified legal counsel.

If an app allows an orientation lock, does that mean it fails accessibility requirements?

Not necessarily. SC 1.3.4 includes an exception for cases where a specific orientation is essential to the content, and the criterion is generally concerned with content that forces a single orientation on the user rather than with user-controlled preferences. Meeting or missing this single success criterion also does not, by itself, determine whether an experience is usable for all users or whether it satisfies broader legal obligations, which depend on regulation and case law that continue to evolve.

How can we determine whether a specific orientation is genuinely essential?

The 'essential' exception in SC 1.3.4 is generally understood to apply narrowly to content where the presentation depends on a particular orientation, such as certain media or specialized interactions. Teams commonly document the rationale for any orientation restriction and confirm that the restriction is a functional necessity rather than a design convenience. Where the need is not clear-cut, supporting both orientations is often the safer approach.

What testing approaches help confirm orientation support?

Manual testing by rotating the device or emulator between portrait and landscape and confirming that content adapts and remains operable is commonly used. Testing with assistive technologies, and with system-level orientation settings enabled, helps confirm the experience for users who rely on a fixed device orientation. Automated tools detect only a portion of issues, so manual and assistive technology testing are generally required to validate orientation behavior.

Does supporting both orientations require a separate layout for each?

Not necessarily a separate design. Responsive and adaptive layout techniques are commonly used so that a single design reflows to accommodate both portrait and landscape. The goal under SC 1.3.4 is generally that content does not lock the user into one orientation, so the emphasis is on the content adapting rather than on maintaining duplicate layouts.

How should orientation support be handled for users who lock their device orientation at the system level?

A user who has set a system-level orientation lock is exercising a personal preference, which is distinct from an application forcing a single orientation. SC 1.3.4 is generally concerned with content-imposed restrictions, so respecting the user's system setting while still supporting both orientations when that setting is not applied is commonly the intended behavior. Confirming this through testing with the system lock both enabled and disabled helps validate the outcome.

Common misconceptions

Locking screen orientation is always prohibited under accessibility guidelines.

The relevant WCAG success criterion permits a fixed orientation where a specific orientation is essential to the content's purpose; the requirement generally applies where orientation is not essential rather than imposing an absolute ban.

This requirement is part of the original WCAG 2.0 standard.

The Orientation success criterion (1.3.4) was introduced in WCAG 2.1 at Level AA and is not present in WCAG 2.0, so version matters when citing this criterion.

Supporting both orientations is a cosmetic preference rather than an accessibility need.

Some users rely on devices mounted in a fixed position and cannot rotate them, so allowing both orientations can be necessary for those users to access content at all.

Best practices

Design layouts to reflow and remain fully operable in both portrait and landscape orientations rather than locking to one.

Reserve fixed orientation only for cases where a specific orientation is genuinely essential to the content's function, and document that justification.

Test content by rotating actual devices, including with assistive technologies, since automated checks detect only a portion of orientation-related issues.

Consider users with fixed or mounted devices who cannot rotate their screens when deciding whether to constrain orientation.

When targeting WCAG 2.1 or later Level AA conformance, verify content against Success Criterion 1.3.4 and confirm the version you are claiming.

Consult qualified legal counsel and current agency guidance regarding which standards apply to your context, as this entry is not legal advice and requirements evolve.