WCAG 1.3.4: Orientation

What This Rule Means

WCAG 1.3.4 Orientation is a Level AA criterion introduced in WCAG 2.1 and carried forward into WCAG 2.2. It states that content must not lock itself to a single display orientation—either portrait (vertical) or landscape (horizontal)—unless that specific orientation is essential to the function of the content. In practice, this means that web pages and web-based applications must respond correctly and remain fully operable regardless of whether the user's device is held vertically or horizontally, or whether orientation is controlled by the device's operating system or by the user's own preferences.

The criterion targets situations where developers use CSS media queries, JavaScript, or device APIs to deliberately restrict content to one orientation. A common violation is displaying a message such as "Please rotate your device to landscape mode" while simultaneously hiding or disabling all interactive content in portrait mode. Another violation occurs when a web application applies a CSS transform or forcibly rotates the viewport, overriding the user's device orientation setting.

What counts as a pass: Content is accessible in both portrait and landscape orientations. All text, interactive elements, forms, navigation, and media remain visible and operable regardless of how the device is oriented. The layout may adapt—using responsive design techniques such as CSS Flexbox, CSS Grid, or media queries—but nothing is removed or made inoperable based on orientation alone.

What counts as a fail: Content that hides, disables, or blocks interaction in one orientation; messages instructing users to rotate their device without providing a working alternative; JavaScript that listens to DeviceOrientationEvent or screen.orientation and then locks or disables parts of the UI; or CSS that uses @media (orientation: portrait) to display a blocking overlay or display: none on critical content.

The essential exception: WCAG acknowledges that some content has an inherently orientation-specific purpose. A piano keyboard application may legitimately require landscape mode because a portrait layout cannot render enough keys to be musically useful. A bank cheque deposit feature that relies on the camera capturing a horizontal cheque may require landscape. A virtual reality headset interface may require a fixed orientation to function. However, the bar for "essential" is high—mere developer convenience or aesthetic preference does not qualify. The exception must be justified by a fundamental requirement of the content itself, not a design choice.

Why It Matters

Orientation restrictions disproportionately affect people with physical and motor disabilities. Consider a wheelchair user whose tablet is mounted in a fixed portrait position on their chair's armrest. They cannot physically tilt the device, so any content that requires landscape orientation becomes completely inaccessible to them. This is not a hypothetical edge case—mounting assistive technology devices in fixed orientations is a common accommodation for people with conditions such as cerebral palsy, spinal cord injuries, ALS, or severe arthritis.

Beyond mounted devices, many users rely on the operating system's orientation lock feature for reasons unrelated to disability. A user lying in bed may lock their phone to portrait to prevent the screen from constantly flipping. A user with vestibular disorder—a condition affecting the inner ear and balance—may find sudden layout shifts caused by orientation changes disorienting or physically nauseating. Forcing these users to unlock their device orientation to access your content creates an unnecessary and discriminatory barrier.

Cognitive accessibility is also a factor. Users with cognitive disabilities often benefit from consistent, predictable layouts. An application that suddenly blocks content or displays an error-like message asking for a device rotation can be confusing and alarming, particularly for users who may not understand why their device is showing a warning instead of the expected content.

From a usability and business perspective, orientation restrictions hurt all users. A significant portion of mobile web traffic occurs in portrait mode, and restricting a site to landscape can result in immediate abandonment. Search engines also increasingly factor mobile-friendliness and Core Web Vitals—including stable layout behavior—into their ranking algorithms, meaning orientation-related issues can have a measurable negative impact on SEO performance and organic traffic.

Globally, approximately 1.3 billion people live with some form of disability according to the World Health Organization. A meaningful proportion of this group uses mobile devices as their primary or sole means of accessing the internet, making mobile orientation accessibility particularly consequential.

Related Axe-core Rules

WCAG 1.3.4 Orientation requires manual testing. There is no automated axe-core rule that reliably detects orientation restrictions, because the violation depends on runtime behavior, conditional rendering logic, and the physical state of a device—none of which static DOM analysis or automated page scanning can evaluate. The following explains why automation falls short and what manual testers must look for:

• No automated axe-core rule (manual testing required): Automated accessibility scanners such as axe-core, Lighthouse, or IBM Equal Access Checker analyze the DOM and CSSOM at a single point in time. They cannot simulate a device being rotated, evaluate what happens to the layout when screen.orientation changes, or determine whether a CSS @media (orientation: landscape) block is hiding critical content. A scanner might see that all elements are present and technically visible in the orientation it tested, without knowing that half of them vanish in the alternate orientation. This is why WCAG 1.3.4 is classified as requiring manual testing—no tool can substitute for actually rotating a real device or simulating rotation in a browser's developer tools.
• JavaScript orientation lock detection: Scripts that call screen.orientation.lock() or listen to window.addEventListener('orientationchange', ...) in order to redirect or disable content cannot be detected by static analysis. A linter could flag the use of these APIs in source code, but it cannot determine whether the resulting behavior constitutes a WCAG violation without human judgment about whether an essential exception applies.
• CSS-based blocking overlays: A stylesheet might use @media (orientation: portrait) { .orientation-warning { display: block; } } to show a full-screen blocking message in portrait mode. Axe-core, scanning the page in landscape, would never encounter this element in a visible state and would report no issue. Only testing in portrait mode—or inspecting the CSS for orientation-conditional blocking patterns—reveals the violation.

How to Test

1. Run an automated scan as a baseline: Open the page in Chrome, Firefox, or Edge. Use the axe DevTools browser extension or run a Lighthouse accessibility audit to establish a baseline. While these tools will not detect orientation violations directly, they may flag related responsive design issues, viewport meta tag problems, or missing ARIA that compound orientation accessibility failures. Note that a clean automated report does not confirm compliance with 1.3.4.
2. Use browser DevTools device emulation: In Chrome or Edge, open DevTools (F12), click the device toolbar icon (Ctrl+Shift+M / Cmd+Shift+M), and select a mobile device such as iPhone 14 or Galaxy S21. Toggle between portrait and landscape orientations using the rotation icon in the device toolbar. Systematically verify that all content—navigation, headings, body text, forms, buttons, images, and media—remains visible and operable in both orientations. Look for blocking overlays, hidden sections, or disabled interactive elements that appear in one orientation but not the other.
3. Test on real devices: Connect an Android or iOS device and open the page in the mobile browser. Physically rotate the device between portrait and landscape. Confirm that the operating system's orientation lock (when enabled) does not cause content to break or display a rotation prompt. Test with the orientation lock both on and off.
4. Screen reader testing with orientation simulation: On iOS with VoiceOver enabled (triple-click side button), navigate the page in portrait orientation using swipe gestures. Then rotate to landscape and verify that VoiceOver's reading order and accessible names remain correct. On Android with TalkBack, perform the same test. Use NVDA with Firefox on desktop and simulate orientation via DevTools to verify that the accessibility tree is consistent across orientations.
5. Inspect CSS and JavaScript for orientation restrictions: In DevTools, open the Sources or Elements panel and search the stylesheet for orientation: portrait and orientation: landscape media queries. Review what each block does: does it hide content with display: none, apply a blocking overlay, or simply adjust layout? Search JavaScript files for screen.orientation, orientationchange, and screen.orientation.lock. Evaluate whether any found patterns lock the UI or block content.
6. Verify the essential exception: If the site intentionally restricts orientation, confirm that a documented, justified essential use case exists. The exception must be content-driven, not cosmetic. Document your finding with a screenshot and the specific justification.

How to Fix

CSS blocking overlay in portrait mode — Incorrect

<!-- A full-screen overlay shown only in portrait that blocks all content -->
<style>
  .rotate-prompt {
    display: none;
    position: fixed;
    inset: 0;
    background: #fff;
    z-index: 9999;
    text-align: center;
    padding: 2rem;
  }
  @media (orientation: portrait) {
    .rotate-prompt {
      display: flex; /* blocks all underlying content */
    }
  }
</style>
<div class='rotate-prompt'>
  <p>Please rotate your device to landscape mode.</p>
</div>
<main id='app-content'>
  <!-- All application content here -->
</main>

CSS blocking overlay in portrait mode — Correct

<!-- Remove the blocking overlay entirely. Use responsive CSS to adapt the layout instead. -->
<style>
  /* Portrait layout: stack elements vertically */
  @media (orientation: portrait) {
    .dashboard-grid {
      grid-template-columns: 1fr;
    }
  }
  /* Landscape layout: side-by-side columns */
  @media (orientation: landscape) {
    .dashboard-grid {
      grid-template-columns: 1fr 1fr;
    }
  }
</style>
<main id='app-content'>
  <div class='dashboard-grid'>
    <!-- Content adapts layout but is always accessible -->
  </div>
</main>

JavaScript orientation lock — Incorrect

<script>
  // Locks screen to landscape and shows an error if it fails (e.g. on iOS)
  screen.orientation.lock('landscape').catch(function() {
    document.getElementById('orientation-error').style.display = 'block';
    document.getElementById('main-content').style.display = 'none';
  });
</script>
<div id='orientation-error' style='display:none'>
  This application only works in landscape mode.
</div>
<div id='main-content'>
  <!-- Application content -->
</div>

JavaScript orientation lock — Correct

<script>
  /*
    Do not lock orientation via JavaScript.
    Instead, listen for orientation changes and adapt the UI
    without hiding or disabling content.
  */
  window.addEventListener('orientationchange', function() {
    var isPortrait = window.matchMedia('(orientation: portrait)').matches;
    // Adjust layout class for styling only — never hide content
    document.body.classList.toggle('portrait-layout', isPortrait);
    document.body.classList.toggle('landscape-layout', !isPortrait);
  });
</script>
<div id='main-content'>
  <!-- All content remains visible and operable in both orientations -->
</div>

Viewport meta tag preventing orientation change — Incorrect

<!-- Some older implementations tried to fix orientation via viewport -->
<meta name='viewport' content='width=device-width, initial-scale=1, user-scalable=no'>
<!--
  While 'user-scalable=no' does not directly lock orientation,
  combining it with CSS transforms that rotate the viewport
  is a known anti-pattern that creates orientation accessibility failures.
-->
<style>
  /* Anti-pattern: rotating the entire body to simulate landscape on a portrait device */
  @media (orientation: portrait) {
    body {
      transform: rotate(90deg);
      transform-origin: left top;
      width: 100vh;
      overflow-x: hidden;
    }
  }
</style>

Viewport meta tag preventing orientation change — Correct

<!-- Use a standard responsive viewport tag. Never rotate the body via CSS transforms. -->
<meta name='viewport' content='width=device-width, initial-scale=1'>
<!--
  Let the browser and operating system handle orientation naturally.
  Design responsively so the content works at all viewport aspect ratios.
  Use CSS Grid and Flexbox to reflow content, not transforms.
-->

Common Mistakes

• Using @media (orientation: portrait) to apply display: none to navigation menus, sidebars, or main content areas. Any CSS orientation query that removes content from view—rather than simply repositioning it—is a potential violation. Audit every orientation media query in your stylesheet to ensure it only changes layout, not content availability.
• Calling screen.orientation.lock() for non-essential applications. This Web API is intended for games and specific media use cases. Using it in a standard web application or e-commerce site to "improve aesthetics" in landscape mode does not qualify as an essential exception and creates a direct WCAG 1.3.4 violation.
• Displaying a "rotate your device" splash screen without an accessible alternative. Even if a brief orientation hint is shown, it must never block access to the content. If shown at all, it must be dismissible, not cover the main content, and be conveyed as a suggestion rather than a requirement.
• Assuming mobile users always prefer landscape for video content. Embedding a video player that disables playback controls or the play button in portrait mode—forcing users to rotate before they can interact—violates 1.3.4 unless the video format genuinely cannot be rendered in portrait (which is almost never true for standard web video).
• Applying CSS transform: rotate(90deg) to the <body> or a root container in one orientation. This simulates orientation change in CSS rather than allowing the device to handle it naturally, creating broken layouts, off-screen content, and severe accessibility tree confusion for screen readers.
• Failing to test orientation behavior during QA because teams only test on desktop browsers. Desktop browser DevTools orientation simulation is not always used during standard QA cycles. Orientation should be an explicit item in mobile test plans, verified on both iOS and Android real devices.
• Overriding orientation behavior inside iframes without accounting for the parent page's orientation state. Third-party widgets, embedded maps, and payment iframes may independently lock orientation. Even if your page is compliant, hosting a locked iframe makes your page non-compliant unless the iframe's essential exception is documented.
• Using server-side user-agent detection to serve a "landscape-only" version of a page to mobile users. Redirecting mobile users to a separate URL that only works in landscape, without providing a portrait-compatible fallback, is a systemic violation that also creates a SEO and URL canonicalization problem.
• Applying orientation restrictions only in production builds, making them invisible during development testing. Feature flags or A/B testing frameworks sometimes activate orientation-locking code only in specific environments or for specific user segments, causing the violation to be missed during pre-launch accessibility audits.
• Assuming the essential exception applies because a designer prefers the landscape layout. The essential exception is a high legal and ethical bar. It requires that the content's primary function is fundamentally impossible in the alternate orientation—not merely that it looks better or that the team ran out of time to implement a responsive portrait layout.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular No. 2025/10, published in the Official Gazette (Resmî Gazete) No. 32933 on June 21, 2025, establishes a comprehensive national framework for digital accessibility. The Circular mandates that covered entities comply with WCAG 2.2 Level AA, which explicitly includes WCAG 1.3.4 Orientation. This means that any digital service or website operated by a covered entity must not restrict content to a single orientation, reflecting the Circular's intent to ensure that all citizens—including those with disabilities—can access digital services regardless of how they physically interact with their devices.

The entities covered by the Circular and required to achieve Level AA conformance include: public institutions and agencies (all government bodies operating websites and digital services), banks and financial institutions, hospitals and healthcare providers, telecommunications companies with 200,000 or more subscribers, e-commerce platforms, travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE). For these entities, orientation restrictions that violate 1.3.4—such as government portals that demand landscape-only access or banking apps that lock to portrait mode for non-essential reasons—constitute direct non-compliance with binding national regulation.

The Accessibility Logo (Erişilebilirlik Logosu), issued by the Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı), is a certification mark that signals conformance with the national accessibility standard. Achieving Level AA conformance is a prerequisite for obtaining this logo. Organizations seeking the Erişilebilirlik Logosu must demonstrate that their digital properties pass all Level A and Level AA criteria, including 1.3.4. An orientation restriction failure—even in a minor section of a site—can jeopardize the entire certification.

Because WCAG 1.3.4 requires manual testing and cannot be confirmed by automated scans alone, covered entities should incorporate orientation-specific test cases into their formal accessibility audit processes. Documentation of testing results in both portrait and landscape orientations on real devices should be maintained as part of the accessibility conformance records required for regulatory compliance and logo certification. The Accsible SDK assists organizations in identifying and addressing orientation-related barriers as part of a holistic approach to meeting Turkey's evolving digital accessibility obligations.