WCAG 1.3.4 Orientation: How to Support Portrait and Landscape Displays

What WCAG 1.3.4 requires

WCAG 1.3.4 Orientation is a Level AA success criterion in WCAG 2.1. It says content must not restrict the display to a single orientation such as portrait or landscape unless that orientation is essential for the content. The rule applies to web pages, responsive sites, hybrid apps and progressive web apps.

Why orientation matters for accessibility

People use devices in the orientation that fits their needs. They may hold a phone one-handed. They may rotate a tablet to use an external keyboard. Locking orientation can block users who rely on a particular orientation or who use assistive tech that works better in one mode. Supporting both orientations reduces barriers for motor, visual and situational limitations.

When a single orientation is allowed

A single orientation is permitted only when it is essential to the function or meaning of the content. Examples where orientation can be essential include certain medical imaging viewers, orientation-dependent games, or instrument panels where rotation changes the data semantics. If you claim an exception, document why the orientation is essential and keep the justification with the product documentation.

How to test for WCAG 1.3.4 compliance

Test on real devices and simulators. Include both phones and tablets. Follow these steps.

• Open the page or app in portrait, then rotate to landscape and back.
• Confirm all functionality remains available and readable without requiring native OS rotation locks.
• Check component layout, menus, dialogs and on-screen controls for overlap or truncation.
• Use keyboard or external input where relevant. Verify focus order after rotation.
• Test with assistive technologies: a screen reader, a screen magnifier and switch control if available.
• Record cases where orientation change is blocked or causes loss of function. Those are likely failures unless you can justify essentiality.

Common failures

• App or web manifest locks orientation to portrait or landscape by default.
• Layout uses fixed pixel widths so content becomes unreadable when rotated.
• Dialogs or menus appear off-screen after rotation and cannot be reached by keyboard or touch.
• Virtual keyboards cover inputs in one orientation and block submission controls.
• Interactive maps or canvases require a specific orientation to use controls.

How to fix orientation problems on web pages

Start with responsive layout and flexible components. Use these practical steps.

• Use responsive CSS: flexible units such as percentages, rem and viewport units instead of fixed pixels.
• Use CSS Grid or Flexbox to let components reflow when width or height changes.
• Handle long content with wrapping and vertical scroll. Avoid horizontal scrolling where possible.
• Ensure modals, menus and popovers are constrained within the viewport after rotation and remain keyboard accessible.
• Test input fields with on-screen keyboards. If a control is obscured, provide a visible way to move or reveal it.

Practical CSS snippets

These show patterns for reflow and orientation-aware styles.

@media (orientation: portrait) {
  /* increase vertical spacing for portrait */
  .main { padding: 1rem; }
}

@media (orientation: landscape) {
  /* wider layout in landscape */
  .two-column { display: grid; grid-template-columns: 1fr 2fr; gap: 1rem; }
}

Also avoid CSS that forces orientation, for example by using device-height calculations in a way that breaks on rotation.

How to handle mobile apps and PWAs

Native apps and progressive web apps sometimes set orientation in their manifest or native configuration. For WCAG 1.3.4 you should not lock orientation unless essential.

• For native apps, avoid android:screenOrientation or iOS equivalents unless essential. If you must lock, document the reason.
• For PWAs, check the web app manifest orientation setting before shipping locked orientation.

Decision checklist: Is orientation essential?

Use this checklist to decide if you can restrict orientation.

• Does rotation change the meaning of the content or the sequence of steps?
• Is there no technically feasible way to preserve the content or controls in the non-preferred orientation?
• Would supporting both orientations create a safety risk or invalidate data?
• Can you document the justification clearly for support and testing teams?

If the answer is yes to any question, consider whether you can redesign the feature to avoid locking orientation. Only keep an orientation lock when you can justify it and record that justification.

Real-world scenario and fix

Scenario: a data-entry tablet app places submit and navigation buttons at the bottom. When a user rotates to landscape the on-screen keyboard covers the submit button.

Fix steps:

1. Change layout so controls move above the keyboard using a wrapper that adjusts on focus.
2. Allow the input area to scroll so the control remains visible.
3. Test with hardware keyboard, on-screen keyboard and with accessibility tools.

Testing matrix to include in QA

Include these test cases in your quality assurance checklist.

• Portrait to landscape rotation on multiple device sizes
• External keyboard attached and detached while rotating
• Screen reader active while rotating
• Browser zoom and system text size changes plus rotation

Documentation and developer handoff

When you accept an orientation exception, document it. Include the technical reason, the platforms affected, and test steps. For each page or view list the supported orientations and the evidence that the restriction is essential.

Summary checklist to meet WCAG 1.3.4

• Do not lock orientation unless essential and documented.
• Ensure layout reflows and controls remain reachable after rotation.
• Test with assistive technologies and external input devices.
• Update manifests and native settings to remove unnecessary orientation locks.

Following these steps will help you meet WCAG 1.3.4 and keep your interface usable for people who rely on a particular device orientation.