WCAG 1.3.4 · Level AA · EN 301 549 9.1.3.4

Orientation

Requires that content works in both portrait and landscape and is not locked to one display orientation, unless a specific orientation is essential.

In brief

Some people mount their phone or tablet in a fixed position, for example on a wheelchair, a stand or a desk, and cannot rotate it. If an app or site works in only one orientation, they cannot use it at all.

This criterion requires that content does not restrict its view and operation to a single display orientation, portrait or landscape, unless a specific orientation is essential. Users should be able to use the content whichever way their device is turned.

What does it cover?

  • Both orientations: The content works in portrait and in landscape. The layout adapts instead of being locked.
  • What counts as a restriction: Locking the orientation in code, in the manifest or in the app settings, or showing a message that asks the user to rotate the device.
  • Essential exceptions: Some content needs a specific orientation, for example a bank check deposit, a piano app, a virtual reality experience or slides that need a wide view.
  • Web and mobile: The criterion applies to websites, installed web apps and native apps. It is mostly about touch devices.
  • Out of scope: Reflow and zoom at small screen sizes are covered by 1.4.10 (Reflow). Controls that need a gesture are covered by 2.5.1.

Who does it affect?

People who cannot rotate their device use it in the position it is fixed in. This includes many wheelchair users and people with motor impairments, who mount a device on a chair or desk. It also helps people with low vision who choose the orientation that suits them best, and anyone using a tablet in a case or stand.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Content that adapts to the orientation is part of "perceivable" and "operable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 1.3.4 by reference and turns it into separate clauses for each kind of ICT.

Where WCAG 1.3.4 appears in EN 301 549
ClauseType of ICTWhat it requires
9.1.3.4Web pagesWeb content must satisfy WCAG success criterion 1.3.4.
11.1.3.4Non-web software (native mobile apps)Software must satisfy the criterion, unless a specific orientation is essential.

Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 1.3.4 is the same in WCAG 2.1 and 2.2. It is a Level AA criterion.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. Do not lock the orientation in CSS

Do not rotate the page with CSS to fake a fixed orientation. Let the layout adapt.

Incorrect
@media (orientation: portrait) {
  body {
    transform: rotate(90deg);
    width: 100vh;
    height: 100vw;
  }
}
Correct
.layout { display: flex; flex-wrap: wrap; gap: 16px; }

@media (orientation: landscape) {
  .sidebar { flex: 0 0 240px; }
}

2. Do not lock the orientation in JavaScript

The Screen Orientation API can lock the orientation. Avoid it unless the orientation is essential.

Incorrect
screen.orientation.lock("portrait");
Correct
// No lock. If the orientation really is essential,
// explain why in your documentation.

3. The web app manifest

The orientation member of a manifest locks an installed web app. Leave it out, or use any.

Incorrect
{
  "name": "Corpowid app",
  "orientation": "portrait"
}
Correct
{
  "name": "Corpowid app",
  "orientation": "any"
}

4. Do not ask the user to rotate the device

A "please rotate your device" screen blocks the people who cannot rotate it.

Incorrect
<div id="rotate-warning">
  Please rotate your device to portrait.
</div>
Correct
<!-- Show the same content in both orientations -->
<main>…</main>

5. A layout that adapts

Use flexible units and wrapping, so content fits both orientations.

Incorrect
.form { width: 360px; height: 640px; }
Correct
.form { max-width: 100%; min-height: 100vh; }
.fields { display: grid; gap: 12px; }

@media (orientation: landscape) and (min-width: 600px) {
  .fields { grid-template-columns: 1fr 1fr; }
}

Code examples for mobile

The same rule applies in native mobile apps. Allow all orientations the app can reasonably support, and adapt the layout.

iOS (SwiftUI)

<!-- Info.plist: allow portrait and landscape -->
<key>UISupportedInterfaceOrientations</key>
<array>
    <string>UIInterfaceOrientationPortrait</string>
    <string>UIInterfaceOrientationLandscapeLeft</string>
    <string>UIInterfaceOrientationLandscapeRight</string>
</array>

// SwiftUI: the layout adapts to the available space
import SwiftUI

struct ProfileView: View {
    var body: some View {
        ViewThatFits {
            HStack(alignment: .top, spacing: 24) { photo; details }   // wide
            VStack(alignment: .leading, spacing: 16) { photo; details } // narrow
        }
        .padding()
    }

    private var photo: some View { Image("profile").resizable().scaledToFit() }
    private var details: some View { Text("Ada Lovelace") }
}

Android (Jetpack Compose)

<!-- AndroidManifest.xml: do not lock the orientation -->
<activity
    android:name=".ProfileActivity"
    android:screenOrientation="unspecified" />

// Compose: the layout adapts to the available width
import androidx.compose.foundation.layout.BoxWithConstraints
import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.Row
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.unit.dp

@Composable
fun ProfileScreen() {
    BoxWithConstraints {
        if (maxWidth > 600.dp) {
            Row { Photo(); Details() }      // wide
        } else {
            Column { Photo(); Details() }   // narrow
        }
    }
}

How to test

  • Rotate the device: Open each page and screen in portrait and landscape. Does everything still work?
  • Look for a lock: Search the code for the CSS rotation trick, screen.orientation.lock, the manifest orientation, screenOrientation in AndroidManifest.xml and the supported orientations in Info.plist.
  • Look for "rotate" messages: Does the page or app ask the user to rotate the device?
  • Check the layout: Is anything cut off, hidden or unusable in the other orientation?
  • Test on a real device: Browser emulation does not always honor the lock. Test on a phone and a tablet.
  • Check the exception: If you restrict the orientation, is it truly essential? Write down the reason.
  • Use a checker as a start: Some tools detect a manifest or CSS lock, but only a person can decide whether an orientation is essential.

Common mistakes

  • Locking the app to portrait by default: It is the most common cause of failing this criterion.
  • Using a CSS transform to fake an orientation: It breaks in unexpected ways and blocks the people who cannot rotate.
  • "Please rotate your device" screens: They block users whose device is fixed.
  • Setting the manifest to portrait: It locks an installed web app.
  • Using fixed pixel sizes: The layout does not fit the other orientation.
  • Claiming essential without a reason: Convenience is not the same as essential.
  • Testing only in portrait: Landscape is often broken in small ways.
  • Forgetting tablets: Tablets are often fixed in a case or stand.

Sources

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.

Corpowid is recognized by Gartner

Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.

Have questions about Corpowid?

Let’s connect.

We will get back to you as soon as possible.