The 2025 TestParty Guide to WCAG 1.3.4 – Orientation (Level AA)

Why did the website refuse to rotate? Because it had a bad orientation! 🔄

WCAG 1.3.4 Orientation ensures that users can access and operate your content regardless of whether they're holding their device in portrait or landscape mode. This Level AA criterion prevents websites and apps from forcing users into a single screen orientation—a critical accessibility requirement for people with disabilities who may have their devices mounted in a fixed position.

Table of Contents

• What WCAG 1.3.4 Requires
• Why This Matters
• Quick Implementation Guide
• Common Mistakes to Avoid
• How to Test for WCAG 1.3.4
• How TestParty Helps
• FAQs

What WCAG 1.3.4 Requires

WCAG 1.3.4 requires that your content works in both portrait and landscape orientations unless a specific orientation is truly essential to the function or meaning of the content.

Key requirements:

• Content must be viewable and operable in both portrait and landscape modes
• Users should be able to rotate their device and have content adapt accordingly
• You cannot lock orientation through code or display messages demanding users rotate their device
• The restriction applies to both mobile and tablet experiences

Exceptions where orientation locking IS allowed:

• Bank checks or other documents where orientation is part of the content's nature
• Piano or musical instrument applications that require landscape for proper key layout
• Presentation slides designed for projector display
• Virtual reality content where device orientation has a different meaning

The exception is narrow. "It looks better in landscape" or "we designed it for portrait" are not valid reasons to lock orientation.

Why This Matters

Many people with disabilities have their devices mounted in fixed positions. Someone using a wheelchair may have their tablet mounted to their chair in landscape mode. A person with limited mobility might have their phone in a bedside mount that only works in portrait orientation.

When you lock orientation, you're effectively telling these users they cannot access your content at all. It's not an inconvenience—it's a barrier.

Legal and compliance context:

WCAG 1.3.4 is a Level AA requirement, which means it's mandatory for ADA compliance, Section 508 conformance, EN 301 549 (the European standard), and the European Accessibility Act. Organizations that fail to support both orientations face legal risk, particularly as mobile accessibility lawsuits continue to increase. The criterion was introduced in WCAG 2.1 (2018) specifically to address the growing importance of mobile accessibility.

Business impact:

Beyond compliance, orientation flexibility improves the experience for all users. People naturally rotate their devices based on context—landscape for videos, portrait for reading. When you force a single orientation, you create friction that drives users away. Supporting both orientations is simply good UX that happens to be legally required.

Quick Implementation Guide

The good news: most modern responsive designs already comply with WCAG 1.3.4. The key is avoiding code that actively prevents rotation.

Do:

• Use responsive CSS that adapts to viewport dimensions without caring about orientation
• Test your layouts in both portrait and landscape to ensure usability
• Use CSS media queries based on viewport width/height, not orientation
• Allow the browser and operating system to handle rotation naturally

Avoid:

• CSS that locks orientation: @media (orientation: portrait) { /* hide content */ }
• JavaScript that detects and blocks orientation changes
• Meta tags or manifest settings that restrict orientation
• Messages telling users to rotate their device

Good implementation example:

/* Responsive layout that works in any orientation */
.container {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
  gap: 1rem;
  padding: 1rem;
}

/* Adjust layout based on available space, not orientation */
@media (max-width: 768px) {
  .container {
    grid-template-columns: 1fr;
  }
}

This approach adapts to the available space rather than forcing a specific orientation.

Key WCAG techniques:

• G214: Providing a control to allow access to content in different orientations (only needed if you have a legitimate reason to prefer one orientation but must still allow the other)

Common Mistakes to Avoid

Locking orientation in the manifest or meta tags:

Many developers add "orientation": "portrait" to their web app manifest or use viewport meta tags that restrict rotation. Unless your app truly requires a specific orientation (like a piano app), remove these restrictions.

Showing "please rotate your device" messages:

Displaying an overlay that says "This app works best in landscape mode—please rotate your device" is a WCAG 1.3.4 failure (F100). Even if you allow users to dismiss the message, you're creating a barrier for people who cannot rotate their devices.

Using CSS to hide content in one orientation:

/* FAILURE: Hiding content based on orientation */
@media (orientation: portrait) {
  .main-content {
    display: none;
  }
  .rotate-message {
    display: block;
  }
}

This pattern explicitly violates the criterion by making content unavailable in portrait mode.

Assuming orientation equals device size:

Don't assume landscape means "large screen" and portrait means "small screen." Tablets in portrait mode can be larger than phones in landscape. Base your responsive breakpoints on actual viewport dimensions, not orientation.

How to Test for WCAG 1.3.4

Testing for orientation compliance is straightforward but requires physical testing on real devices or emulators.

Manual testing checklist:

• Open your site on a mobile device or in a responsive browser mode
• Rotate the device between portrait and landscape orientations
• Verify all content remains visible and functional in both orientations
• Check that no messages appear asking you to rotate the device
• Test interactive elements (forms, buttons, navigation) in both orientations
• Verify that content reflows appropriately without horizontal scrolling

What automated tools can catch:

Automated scanners like TestParty can detect some orientation issues by analyzing your code for:

• Manifest files or meta tags that lock orientation
• CSS media queries that hide content based on orientation
• JavaScript that restricts or detects orientation changes

What requires manual review:

Automated tools cannot fully assess whether content is usable in both orientations. You need human testing to verify that:

• Layouts work well in both orientations (not just technically visible)
• Interactive elements remain accessible and usable
• Content doesn't become unusable due to poor responsive design
• Any orientation preference is truly essential (not just a design preference)

The best approach combines automated detection of obvious violations with manual testing on real devices.

How TestParty Helps

TestParty's AI-powered accessibility platform helps teams identify and prevent WCAG 1.3.4 orientation violations throughout the development lifecycle.

What TestParty detects:

TestParty's automated scanning analyzes your codebase for common orientation violations:

• Web app manifest files that specify locked orientation values
• Meta viewport tags that restrict rotation or orientation
• CSS media queries using (orientation: portrait) or (orientation: landscape) that hide or disable content
• JavaScript code that detects orientation and blocks access to features
• Overlay components that display "rotate your device" messages

The platform scans both source code and rendered DOM, catching violations at the template level (where they can be fixed once and cascade across thousands of pages) and at the component level in modern JavaScript frameworks.

How TestParty suggests fixes:

When TestParty identifies an orientation violation, it provides specific, actionable remediation guidance:

• For manifest files: Suggests removing or modifying the orientation property
• For CSS violations: Recommends replacing orientation-based media queries with viewport-width queries
• For JavaScript restrictions: Flags the problematic code and suggests removal or alternative approaches
• For responsive design issues: Provides guidance on creating flexible layouts that work in any orientation

TestParty's AI generates code-level fixes that developers can review and approve before committing. For example, if your manifest locks orientation to portrait, TestParty will suggest removing that line and provide a diff showing exactly what to change.

Developer workflow integration:

Orientation violations often slip through because developers test primarily on desktop or in a single mobile orientation. TestParty prevents these regressions by integrating directly into your development workflow:

• CI/CD gates: Block pull requests that introduce orientation-locking code
• Pre-commit hooks: Catch manifest or CSS violations before code is even committed
• PR annotations: Surface orientation issues as inline comments on the specific lines of code that need attention
• IDE integration: Real-time feedback as developers write CSS or modify manifest files

For teams working with component libraries or design systems, TestParty can flag orientation issues at the component level, ensuring that reusable elements work in both orientations before they're deployed across your application.

Ongoing monitoring:

Orientation compliance can regress when new features are added or third-party libraries are updated. TestParty's continuous monitoring tracks WCAG 1.3.4 compliance over time:

• Scheduled scans detect new orientation violations introduced in recent deployments
• Dashboards show orientation compliance trends across your entire digital property
• Alerts notify teams when regressions are detected
• Audit-ready reports document your orientation support for legal and procurement requirements

For organizations with multiple properties or white-label products, TestParty can monitor orientation compliance across your entire portfolio, ensuring consistent accessibility as your codebase evolves.

FAQs About WCAG 1.3.4

What is WCAG 1.3.4 Orientation in plain language?

WCAG 1.3.4 means your website or app must work in both portrait and landscape orientations on mobile devices. You can't force users to hold their device a certain way unless the orientation is truly essential to what the content is (like a digital piano that needs landscape to show all the keys).

Is WCAG 1.3.4 required for ADA compliance?

Yes. WCAG 1.3.4 is a Level AA criterion, and ADA digital accessibility compliance typically requires meeting WCAG 2.1 or 2.2 Level AA standards. Federal agencies must also meet this requirement under Section 508, and it's mandatory for EN 301 549 and European Accessibility Act compliance.

Can I show a message suggesting users rotate their device?

No. Displaying a message that asks or tells users to rotate their device is a WCAG 1.3.4 failure (F100), even if the message is dismissible. Your content must work in the orientation the user chooses without prompting them to change it.

What counts as "essential" orientation?

Essential orientation is rare and must be inherent to the content itself, not just a design preference. Examples include bank checks (which have a specific physical orientation), piano apps (where landscape is needed for proper key layout), or slides designed for projector display. "It looks better" or "we designed it this way" are not valid reasons.

Does WCAG 1.3.4 apply to desktop websites?

The criterion primarily applies to mobile and tablet experiences where device rotation is possible. Desktop browsers don't typically change orientation, so this requirement is less relevant. However, your responsive design should still adapt to different viewport sizes and aspect ratios, which is good practice regardless of WCAG 1.3.4.

How do I fix a WCAG 1.3.4 violation?

Most violations are fixed by removing code that locks orientation. Check your web app manifest for "orientation" properties, remove CSS that hides content based on orientation media queries, and eliminate JavaScript that restricts rotation. Then test your responsive design in both portrait and landscape to ensure usability.

Some TestParty features described in this article are currently under development. Visit TestParty.ai to learn more about our current capabilities and roadmap, or book a demo at TestParty.ai/book-a-demo to see TestParty in action.

Disclaimer: Some of this article was generated with Large Language Models (LLMs) and Artificial Intelligence (AI). There may be some errors and we advise you to consult with human professionals for detailed questions.