Screen Orientation in Public Apps and Web Apps

Devices that cannot be turned

A resident who uses a power wheelchair has a tablet clamped to the armrest in landscape. A transit pass app that only works upright cannot be used, and the screen cannot simply be turned by hand.

WCAG 1.3.4 (Level AA) requires that content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific orientation is essential. The principle is that people should use content in the orientation that suits them, and a device-level orientation lock set by the user should be respected.

What counts as essential, and what does not

The Understanding document gives examples where one orientation is essential: capturing a bank check, a piano app whose keys need physical width, slides meant for a projector or television, and virtual reality content. "Essential" means removing the restriction would change the content or its function in a way that cannot be delivered another way.

A layout that changes with screen size is not a restriction. A page can reflow into one column in portrait and two in landscape. What the criterion rules out is a lock or a message that demands a particular orientation.

Where public apps and web apps lock the screen

Benefit portals, transit tickets, parks apps and clinic check-in tools are often built portrait-first and then locked, because that is the screen the designer tested. Wheelchair-mounted, desk-mounted and stand-mounted devices are common for people who cannot easily operate a rotating device. A "Please rotate your device" overlay, a manifest entry or an app setting that fixes the orientation each turn a convenience for the team into a barrier for the user. Mobile apps are in scope of the Title II rule too; see mobile apps.

Web: manifest, scripts and overlays

A web app manifest can pin the orientation. Leave it unset, or allow any.

{
  "name": "Metro Pass",
  "display": "standalone",
  "orientation": "portrait"
}

{
  "name": "Metro Pass",
  "display": "standalone",
  "orientation": "any"
}

Scripts can lock the screen too. Remove the lock and respond to the available space in CSS.

screen.orientation.lock('portrait-primary');

/* No lock. Adapt the layout instead. */
@media (orientation: landscape) {
  .pass-card { display: grid; grid-template-columns: 1fr 1fr; }
}

A "rotate your device" message is a restriction, even when it is dressed as a courtesy.

@media (orientation: landscape) {
  body::before {
    content: "Please rotate your device";
    position: fixed; inset: 0; z-index: 99;
    background: #000; color: #fff;
  }
}

@media (orientation: landscape) {
  .pass-card { flex-direction: row; }
  .pass-qr { width: 40vh; }
}

Native apps: manifest and Info.plist

On Android, an activity can be fixed in the manifest. The default lets the user's choice and device settings decide.

<activity
    android:name=".TripPlannerActivity"
    android:screenOrientation="portrait" />

<activity
    android:name=".TripPlannerActivity"
    android:screenOrientation="unspecified" />

On iOS, the supported orientations are listed in Info.plist (and per view controller). Include landscape for content that does not need to be upright.

<key>UISupportedInterfaceOrientations</key>
<array>
  <string>UIInterfaceOrientationPortrait</string>
</array>

<key>UISupportedInterfaceOrientations</key>
<array>
  <string>UIInterfaceOrientationPortrait</string>
  <string>UIInterfaceOrientationLandscapeLeft</string>
  <string>UIInterfaceOrientationLandscapeRight</string>
</array>

How to check it

1. Open the page or app on a phone or tablet with orientation lock off. Rotate it. Does everything stay available?
2. Repeat with the device's orientation lock on, once in portrait and once in landscape. The content should follow the lock, not fight it.
3. In browser developer tools, switch the device emulation between portrait and landscape.
4. Search the manifest, scripts and style sheets for orientation locks and "rotate" messages.

If a screen is intentionally one orientation, document why it is essential.

Mistakes to avoid

• Locking everything to portrait during development and shipping it.
• A full-screen "rotate to continue" overlay.
• Treating "it looks better upright" as essential.
• Forgetting a landscape layout for forms, which pushes the submit button off screen when the keyboard opens.
• Calling a reduced feature set in landscape "supported".

Ship it when

• Every view works in portrait and landscape, unless a specific orientation is essential.
• No lock, overlay or setting forces one orientation.
• Any essential exception is limited to the single view that needs it.

Sources

• Understanding SC 1.3.4: Orientation (W3C), opens in a new tab
• 28 CFR Part 35, Subpart H: Accessibility of Web Information and Services (eCFR), opens in a new tab

Standard version: WCAG 2.1 (W3C Recommendation, 5 June 2018), as named in the Title II web rule. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official ADA statute and regulations, and ask a lawyer how they apply to you.