Skip to main content
Accessibility.com, LLC
Category: Mobile Accessibility

Orientation

Simply put

In digital accessibility, orientation refers to the way content is displayed on a screen, either upright (portrait) or sideways (landscape). Accessibility guidance generally advises that content should not be locked to a single orientation, so people who mount their devices in a fixed position or who cannot rotate their device can still use it. The evidence provided here does not include material describing orientation in this accessibility sense.

Formal definition

The evidence packet supplied does not contain authoritative accessibility material defining "Orientation" as used in the Web Content Accessibility Guidelines (for example, the WCAG 2.1 Success Criterion 1.3.4 Orientation, an AA-level criterion added in WCAG 2.1). The sources provided instead concern unrelated meanings of "orientation" in philosophy, student onboarding, and employee onboarding contexts. Because no substantiating accessibility, W3C, or regulatory evidence is present, a precise practitioner-level definition citing specific WCAG version, conformance level, or success criterion text cannot be responsibly generated from this packet. Practitioners should consult the current W3C WCAG documentation directly for the normative definition and understanding documents.

Why it matters

In digital accessibility, orientation matters because many people rely on their devices being usable in whatever physical position works for them. Someone who mounts a phone or tablet to a wheelchair, a bed rail, or a stand may not be able to physically rotate the device, and locking content to a single orientation can effectively lock those users out. Guidance in this area generally advises that content should support both portrait and landscape display so that users are not forced into an orientation they cannot accommodate.

It is important to note that the evidence packet supplied for this entry does not contain authoritative accessibility, W3C, Department of Justice, or Access Board material defining orientation in this sense. The sources available concern unrelated meanings of the word, philosophy, student onboarding, and employee onboarding, and therefore cannot substantiate detailed claims about the corresponding WCAG success criterion, its conformance level, or its normative requirements. As a result, this entry describes the concept only qualitatively and avoids asserting specifics that the provided evidence does not support.

Practitioners who need the normative definition, including the precise WCAG version and conformance level in which an orientation success criterion appears, should consult the current W3C WCAG documentation and its associated understanding documents directly. This entry is not legal advice, and compliance obligations may vary by jurisdiction and evolve through regulation and case law; qualified legal counsel should be consulted for compliance decisions.

Who it's relevant to

Accessibility Engineers and Developers
Those building and testing digital interfaces are generally responsible for ensuring content is not unnecessarily locked to a single orientation. Because the evidence here does not include normative accessibility sources, these practitioners should consult current W3C WCAG documentation for the applicable success criterion, its exceptions, and its testing guidance rather than relying on this entry alone.
UX and UI Designers
Designers making layout decisions that behave across portrait and landscape display directly affect whether users who cannot rotate their devices can access content. Designing for orientation flexibility supports users with mounted or fixed-position devices.
Compliance Officers and Legal Counsel
Those evaluating conformance and legal exposure should be aware that this entry does not cite the normative accessibility standard for orientation, and that requirements evolve through regulation and case law. This content is not legal advice; consult current agency guidance and qualified counsel for compliance decisions.
Users Who Rely on Fixed-Position Devices
People who mount devices to wheelchairs, stands, or other fixtures, or who cannot physically rotate a device, benefit most when content supports both orientations, since orientation locking can prevent them from using the content at all.

Inside Orientation

WCAG Success Criterion 1.3.4 Orientation
Orientation is addressed by WCAG Success Criterion 1.3.4, which was added in WCAG 2.1 at Level AA. It states that content should not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific orientation is essential. It did not exist in WCAG 2.0.
Portrait and landscape modes
The criterion concerns the two primary display orientations of a device screen. Users should generally be able to use content in either portrait or landscape without being locked into one, so that people who mount devices in a fixed position or who cannot easily rotate a device are not excluded.
The 'essential' exception
The criterion allows a specific orientation to be required when it is essential to the function. Examples commonly cited include a piano application or a check-deposit function that relies on a particular orientation. Where orientation is genuinely essential, restricting it may be permissible under the criterion.
Relationship to assistive needs
The criterion primarily benefits users with mobility or dexterity limitations who use a device fixed to a wheelchair or stand, as well as users who otherwise cannot rotate a device. It is one component of an accessible experience and does not by itself guarantee usability for all users.

Common questions

Answers to the questions practitioners most commonly ask about Orientation.

Does the Orientation success criterion mean my content can never lock to a single orientation?
No. WCAG 2.1 Success Criterion 1.3.4 Orientation (Level AA) does not prohibit all orientation locking. It states that content should not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific orientation is essential. The guideline itself recognizes exceptions where a particular orientation is essential to the functionality, such as a piano application, a check-scanning feature, or certain media that must be viewed in a fixed orientation. The intent is to support users who have devices mounted in a fixed position, for example on a wheelchair, rather than to eliminate all use cases for a locked orientation.
Is the Orientation criterion the same as making a page responsive or mobile-friendly?
Not exactly. Responsiveness and Orientation are related but distinct concepts. A responsive design adapts layout to different screen sizes and can help satisfy Orientation, but the specific concern of SC 1.3.4 is that content works in both portrait and landscape without forcing the user into one. A site can be responsive yet still improperly lock orientation, and conversely meeting Orientation alone does not guarantee a fully responsive or usable mobile experience. They address overlapping but different user needs, and conformance with one does not automatically satisfy the other.
Which WCAG version and conformance level does the Orientation criterion fall under?
Orientation is Success Criterion 1.3.4 and was introduced in WCAG 2.1 at Level AA. It was not present in WCAG 2.0. It is retained in WCAG 2.2. Because it is a Level AA criterion, it is commonly included in the conformance targets referenced by organizations aiming for AA, which is the level most frequently cited as a benchmark. Confirm the specific version and level your project is targeting, as requirements can vary by context and evolve through regulation and case law.
How can I avoid unintentionally locking orientation in a web application?
A common source of unintended orientation locking is applying CSS or scripting that restricts the display to a single orientation, or using the display orientation lock features available in some contexts. Reviewing your stylesheets and any orientation-related scripts, testing the interface by physically rotating a device or emulator, and confirming that content reflows and remains operable in both portrait and landscape are practical steps. This entry is general guidance and not a substitute for testing against your specific implementation.
How do I determine whether a fixed orientation is 'essential' and therefore exempt?
The exception applies when a specific orientation is essential to the content or functionality. Evaluating this generally involves asking whether the feature could reasonably function in the other orientation without losing its core purpose. Examples often given for essential orientation include applications that mirror a physical device layout or require a particular aspect ratio to operate correctly. Where an orientation is genuinely essential, the criterion is not violated, but the determination should be made carefully and documented, since claiming an exception broadly may not withstand scrutiny.
How should Orientation be tested?
Orientation is generally verified through manual testing by rotating the device or using device emulation to view content in both portrait and landscape, then confirming that content and functionality remain available and usable. Automated tools detect only a portion of accessibility issues and may not reliably identify orientation restrictions, so manual checks and testing with assistive technologies are typically needed. Testing across the range of devices and viewports your users are likely to encounter helps confirm the behavior in real conditions.

Common misconceptions

Orientation support is required by WCAG 2.0 and has always been part of the guidelines.
Success Criterion 1.3.4 Orientation was introduced in WCAG 2.1 at Level AA and is not present in WCAG 2.0. Practitioners referencing an earlier version should not assume this criterion applies.
The ADA legally requires apps and websites to support both screen orientations.
The ADA is a US civil rights law and does not itself contain detailed technical specifications such as orientation requirements. WCAG, including 1.3.4, is often cited as a benchmark in settlements, regulations, or agency guidance rather than codified in the statute. Consult qualified legal counsel regarding specific obligations.
Locking an app to a single orientation is always a violation.
The criterion includes an exception where a specific orientation is essential to the function. Where an orientation is genuinely essential, restricting it may be permissible; the determination generally depends on whether the restriction is truly necessary rather than a design preference.

Best practices

Design content to function and be operable in both portrait and landscape orientations rather than locking to one, unless a specific orientation is essential to the function.
When restricting orientation, document why that orientation is essential, and reserve such restrictions for cases that genuinely require them.
Avoid relying solely on automated testing for orientation, since automated tools detect only a portion of issues; verify behavior manually by rotating devices and using assistive technologies.
Test with devices mounted in fixed positions, such as on a wheelchair or stand, to confirm users who cannot rotate a device can still access content.
Target WCAG 2.1 Level AA (or a later applicable version) when orientation support is in scope, and confirm which version and conformance level your organization is committing to.
Treat orientation support as one component of accessibility and legal compliance, not a guarantee of either; consult current agency rulemaking and qualified legal counsel for jurisdiction-specific obligations.