Skip to main content
Perceivable WCAG 1.3.4

1.3.4 Orientation

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

Level AA Serious WCAG 2.1 (new) WCAG 2.2

What this rule means

Success Criterion 1.3.4 requires that web content works in both portrait and landscape orientations unless a specific orientation is essential to the functionality. Essential exceptions include a piano keyboard app that requires landscape mode or a bank check scanner that must match check dimensions. Most web content has no such requirement.

This criterion was introduced in WCAG 2.1 primarily to address mobile accessibility. Users who mount their devices on wheelchairs or assistive mounts often cannot rotate them. Locking content to a single orientation renders it inaccessible to these users.

Why it matters

People with physical disabilities may have their devices permanently mounted in one orientation. A wheelchair-mounted tablet fixed in landscape mode cannot be rotated to portrait. If a website forces portrait-only viewing, the user simply cannot use it. This creates a hard barrier to access.

Even beyond disability, forcing orientation degrades user experience. Users reading in bed, using split-screen multitasking, or using foldable devices all benefit from content that adapts to any orientation.

Related axe-core rules

There are no automated axe-core rules for orientation detection. Testing requires manually rotating the device or using browser developer tools to simulate orientation changes. CSS media queries and JavaScript orientation locks must be reviewed manually.

How to test

  1. Open the page on a mobile device and rotate between portrait and landscape. Verify content and functionality remain fully accessible in both orientations.
  2. Use browser developer tools to toggle between portrait and landscape in the device emulator.
  3. Search the codebase for screen.orientation.lock(), CSS media queries using orientation: portrait or orientation: landscape, and meta viewport tags that restrict orientation.
  4. Check the web app manifest for an "orientation" field that locks to a single mode.

How to fix

Ensure your CSS works in both orientations using responsive design techniques:

/* Use flexible layouts that adapt to any orientation */
.container {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
  gap: 1rem;
}

/* Adapt layout based on available space, not orientation */
@media (min-width: 768px) {
  .sidebar { grid-column: span 1; }
  .main    { grid-column: span 2; }
}

Do not use the Screen Orientation API to lock orientation unless it is essential:

// Bad: locking orientation without essential reason
screen.orientation.lock("portrait");

// Good: allow natural orientation
// Simply do not call screen.orientation.lock()

In your web app manifest, avoid restricting orientation:

// Bad: locks to portrait
{
  "orientation": "portrait"
}

// Good: allows any orientation
{
  "orientation": "any"
}

Common mistakes

  • Using screen.orientation.lock("portrait") for a regular web application with no essential orientation requirement.
  • Setting "orientation": "portrait" in the web app manifest for a content site.
  • CSS that only accounts for one orientation, causing content overflow or hidden elements in the other.
  • Dismissing landscape mode testing because "most users are on portrait" — users who cannot rotate their devices are excluded.
  • Modal dialogs or forms that become unusable in landscape because they exceed the viewport height.

Resources