Understanding WCAG 1.3.4 Orientation in WordPress

This post is part of a series where we explain Web Content Accessibility Guidelines (WCAG), an internationally recognized standard for measuring website accessibility. For more posts in this series, visit our Web Accessibility WCAG 2 Knowledge Base.

When a webpage is designed for mobile devices, asking users to “rotate your device to continue” may seem harmless. However, users who have their devices mounted in a fixed position or have difficulty physically rotating them may be unable to access content restricted to portrait or landscape mode.

That’s where WCAG Success Criterion 1.3.4: Orientation comes in. 1.3.4 Orientation requires that users can view and operate content in both portrait and landscape orientations, unless a particular orientation is essential.

Whether you’re choosing a WordPress theme, adding a form, or building an interactive feature, following WCAG 1.3.4 helps ensure that users can access and interact with your website in the orientation that works for them.

In this article, we’ll explain what WCAG Success Criterion 1.3.4 requires, why it matters for WordPress websites, common implementation mistakes, and practical ways to ensure your content works in both orientations.

What is WCAG 1.3.4 Orientation?

WCAG Success Criterion 1.3.4 Orientation (Level AA) states:

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.
Web Content Accessibility Guidelines 1.3.4

In plain terms: Users should generally be able to view and interact with your website in either portrait or landscape orientation.

The goal isn’t to force designers to create two completely different versions of every page. Instead, it prevents websites from unnecessarily locking users into one orientation.

This criterion is particularly relevant to content such as:

Forms
Online applications
E-commerce interfaces
Interactive widgets
Games
Maps
Dashboards
Video and media players
Responsive layouts

Exceptions apply when a particular orientation is genuinely essential to the activity. For example, a piano application that requires a landscape layout to accurately represent the instrument may have a legitimate reason to restrict orientation.

The important word here is essential. Simply preferring one orientation because it looks better isn’t enough.

Article continued below.

Stay on top of web accessibility news and best practices.

Join our email list to get notified of changes to website accessibility laws, WordPress accessibility resources, and accessibility webinar invitations in your inbox.

Comments

This field is for validation purposes and should be left unchanged.

Email(Required)

Name

First Last

Why WCAG 1.3.4 Matters for WordPress Websites

People visit WordPress websites using phones, tablets, laptops, and other devices, each with different screen sizes and ways of interacting with content. Some users switch between portrait and landscape depending on the task, while others keep their device in one orientation for comfort, readability, or physical support.

For example, imagine someone completing a form on their phone in portrait mode. A message such as “Please rotate your device to landscape to continue” assumes they can easily turn their phone. For someone whose device is mounted in place or who needs help repositioning it, that requirement can prevent them from finishing the form.

This can create barriers for people who:

Mount a device in a fixed orientation, such as on a wheelchair or desk stand, and cannot easily rotate it when a website asks them to.
Have limited mobility, which may make turning or repositioning a phone or tablet difficult or require assistance from another person.
Use a device in a particular position, such as while reclining or resting it on a supportive surface, where changing orientation may be uncomfortable.
Use assistive technology, such as switches or an adapted device mount, with controls positioned for their current setup.
Need a specific orientation for their setup, such as landscape mode to make reading magnified text more comfortable.
Simply prefer one orientation over another, whether for reading, typing, or navigating, and should generally be able to use the website in that orientation.

Accessibility is often about avoiding unnecessary restrictions. If your content works perfectly well in both orientations, there is usually no good reason to prevent someone from choosing the one that works best for them.

Common Failures

Locking the Entire Website to One Orientation

One of the most obvious failures is using code or design patterns that prevent the website from being used unless the device is rotated.

Websites with this restriction may actually show an error message if someone tries to view the site in portrait mode:

“This website is only available in landscape mode.”

If you see CSS code like this, it’s a red flag:

/* Hides the entire interface in portrait orientation */
@media (orientation: portrait) {
  main {
    display: none;
  }

  .rotate-device-message {
    display: block;
  }
}

/* Show a full-screen "rotate your device" overlay in portrait orientation */
@media (orientation: portrait) {
  .rotate-overlay {
    position: fixed;
    inset: 0;
    z-index: 999999;
  }
}

If there is no essential reason to restrict people to only one orientation, it can prevent users from accessing or interacting with the content.

Hiding Content in One Orientation

A website doesn’t necessarily need an explicit “rotate your device” warning to fail this criterion.

If any non-decorative content or important controls disappear when the device is held in portrait mode, the page fails this criterion. For example, this CSS:

/* Hides specific elements in portrait orientation */
@media (orientation: portrait) {
  .landscape-only {
    display: none;
  }
}

The user may still be able to access the page, but if text content or functionality they need to understand the page or complete a task is missing, it fails.

Content and functionality should remain available in both orientations unless a specific orientation is essential.

Breaking the Layout When the Device Rotates

Responsive design is important here.

A page might look great in portrait orientation but become unusable when rotated to landscape. Buttons could overlap, text could become inaccessible, or interactive controls could disappear outside the viewport.

Simply allowing the page to rotate isn’t enough. Users need to be able to view and operate the content in the available orientation.

Using Orientation Restrictions for Convenience

Sometimes orientation restrictions are introduced because the design is easier to manage that way.

For example:

“The dashboard looks better in landscape, so we’ll require landscape.”

That’s not necessarily an accessibility justification.

If the content can reasonably be presented in portrait orientation, restricting users to landscape creates an unnecessary barrier.

The question isn’t whether one orientation is preferable. The question is whether the restriction is essential.

What Conformance to 1.3.4 Ensures

Meeting WCAG 1.3.4 helps ensure users aren’t unnecessarily restricted based on how they orient their device.

Conformance particularly benefits people who:

Use devices mounted in a fixed position
Have limited mobility
Have difficulty physically rotating a device
Use a particular orientation as part of their assistive setup
Prefer portrait or landscape for their browsing needs

It also supports a better responsive experience for everyone.

This is an important distinction: WCAG 1.3.4 doesn’t require your design to look identical in portrait and landscape. Responsive layouts can, and often should, adapt to the available space.

What matters is that the content and functionality remain available.

How to Meet WCAG 1.3.4 in WordPress

The good news is that most WordPress websites don’t need anything complicated to meet this criterion. The key is to make sure your theme, blocks, plugins, and custom components don’t unnecessarily lock users into portrait or landscape mode.

1. Check Your Theme for Orientation Restrictions

Start with your WordPress theme.

Look for messages such as:

“Please rotate your device.”

or:

“This site is best viewed in landscape mode.”

When a site requires a specific orientation to access content or functionality, ask why. A reason such as “because that’s how the design was created” generally isn’t enough to justify the restriction. For custom themes, start by checking the CSS and JavaScript for orientation-specific rules or scripts.

For example, look for:

@media (orientation: landscape) {
    /* styles */
}

@media (orientation: portrait) {
    /* styles */
}

Using orientation-specific CSS isn’t automatically a problem. In fact, it’s perfectly reasonable to adjust a layout based on orientation. The problem is when the CSS hides essential content or makes functionality unavailable in one orientation.

2. Test Your WordPress Forms in Both Orientations

Forms are one of the first things I would test on a WordPress site. Try completing your contact, login, registration, and search forms in both portrait and landscape mode. Include checkout, donation, and multi-step forms where relevant, and follow each process through to completion to confirm users can see every field, understand the instructions, activate controls, and submit successfully.

Pay special attention to forms created with plugins or form builders. A form that looks perfectly fine on desktop may behave differently when the viewport changes, leaving fields, buttons, or instructions difficult to reach. Rotating the device partway through a form can also help you spot problems that aren’t apparent when testing each orientation separately.

For more guidance on form accessibility, watch or read the recap HTML Forms and Web Accessibility with Cam Beaudoin for practical advice on creating accessible, usable forms. You can also watch or read How Accessible Are WordPress Forms by Default? to learn how popular WordPress form plugins compare and what accessibility issues to look for when testing your own forms.

3. Check Your Navigation

Responsive navigation can behave very differently when the viewport changes, so test your WordPress site’s main navigation, mobile menus, mega menus, and dropdowns in both portrait and landscape mode. Include search interfaces and off-canvas menus, checking that users can open them, reach their controls, and follow links in either orientation.

As you rotate the device, make sure navigation remains available and usable. A mobile menu may change to a full navigation bar in landscape mode, which is fine as long as users can still reach the same destinations. However, navigation that disappears completely or prevents users from opening or closing a menu needs further investigation.

For more guidance on building accessible WordPress menus, watch or read the recap for Anatomy of an Accessible Navigation with Steve Jones. The session covers navigation structure, responsive behavior, and practical development techniques to help keep menus usable across different screen sizes and input methods.

4. Check Modals and Pop-Ups

Modals are another common trouble spot, especially when rotating a device reduces the available screen height. Open every important modal in both portrait and landscape mode, then rotate the device while the modal is open to check whether:

The entire dialog is visible: Check that the dialog fits within the available screen space or provides a way to reach all of its content through scrolling. Users should be able to understand and interact with it in either orientation.
The close button is available: Make sure the close control remains visible or reachable after rotation. Users should be able to dismiss the modal without turning their device back.
Content isn’t cut off: Look for text, images, and form fields that become clipped when the layout changes. Instructions and error messages should remain readable without requiring a specific orientation.
Buttons remain accessible: Check that users can reach and activate buttons such as “Submit,” “Accept,” or “Cancel.” Pay attention to buttons near the bottom of the dialog, where reduced screen height can make them harder to reach.
The user can scroll through the content: For longer dialogs, check that users can scroll within the modal to reach all information and controls. Make sure scrolling moves the modal’s content rather than only the page behind it.
The dialog doesn’t extend beyond the viewport: Watch for fixed widths, heights, or positioning that push parts of the modal off-screen. The dialog should adapt to the available space so its edges and controls don’t become unreachable.

This is particularly important for WordPress sites using third-party pop-up, cookie-consent, or form plugins. A modal that works well in portrait may become difficult or impossible to use in landscape, so test both opening it in each orientation and rotating the device while it’s open.

5. Keep Important Content Available in Both Orientations

As your WordPress layout adapts to portrait and landscape mode, make sure users can still access the information and controls they need. Orientation-specific CSS can help adjust spacing, rearrange columns, or reposition elements, but it can also hide content that users rely on to complete a task.

For example, these rules hide any element with the class .important-content in the specified orientation:

/* Hides content in portrait orientation */
@media (orientation: portrait) {
    .important-content {
        display: none;
    }
}

/* Hides content in landscape orientation */
@media (orientation: landscape) {
    .important-content {
        display: none;
    }
}

These are separate examples. Using both rules together would hide the element in both orientations. The display: none declaration also removes the element from the accessibility tree, making it unavailable to screen reader users.

When reviewing your theme or custom CSS, check what each orientation-specific rule hides and whether users have another way to access the same information or functionality. A navigation bar that becomes a mobile menu can still provide access to every page. However, hiding a checkout button, required form field, or booking option without an accessible alternative can prevent users from completing their task.

Choose layout adjustments that preserve access, such as stacking columns, allowing text to wrap, or moving secondary information into an accessible expandable section. After making changes, test the affected content in both orientations to confirm users can find the information, reach the controls, and complete the same tasks.

6. Check WordPress Blocks and Plugins

Don’t limit your testing to your theme. WordPress websites often rely heavily on plugins and third-party components, so check anything that creates interactive content in both portrait and landscape mode, including:

Sliders and carousels: Move through the slides and check that navigation arrows, slide selectors, and pause controls remain accessible. Make sure rotating the device doesn’t hide slide content or prevent users from following links.
Galleries: Open images and test any lightbox controls in both orientations. Users should be able to browse images and close the expanded view without having to rotate their device.
Maps: Check that users can access map controls, search for locations, and read location details in either orientation. Watch for information panels that cover controls or become impossible to dismiss.
Charts: Test interactive features such as filters, tooltips, and data selectors in both orientations. Make sure users can still access the information without encountering a message that requires them to rotate their device.
Forms: Complete and submit forms in each orientation, checking that fields, instructions, error messages, and buttons remain accessible. For multi-step forms, move through every step to catch restrictions that may appear later.
Booking interfaces: Work through selecting a date, choosing a time, entering details, and confirming a booking in both orientations. Pay particular attention to calendars and time selectors that may become difficult to use when the available space changes.
Product configurators: Try selecting product options, reviewing previews, and adding the configured item to the cart. Check that customization controls and purchase buttons remain available in either orientation.
Page builders: Test the published layouts and interactive elements created with your page builder, including tabs, accordions, and navigation widgets. Check whether orientation-specific settings hide content or prevent users from operating these elements.
Pop-ups: Trigger pop-ups in both orientations and check that users can read the content, activate buttons, and reach the close control. Rotate the device while a pop-up is open to see whether any controls become inaccessible.
Video players: Test playback, captions, volume, and full-screen controls in both orientations. Check whether starting playback or entering full screen forces a particular orientation or blocks viewing until the device is rotated.

You don’t necessarily need to inspect the code for every plugin. Start by interacting with each component as a visitor would. When something disappears, becomes inaccessible, or requires users to rotate their device, investigate further to identify the cause.

7. Test at 200% and 400% Zoom Too

Orientation testing shouldn’t happen in isolation. Increasing browser zoom can reduce the space available for content and trigger responsive layouts, helping you spot problems that may also appear when a device is rotated. Test important pages at 200% and 400% zoom and look for:

Content being cut off: Check that headings, paragraphs, images, and form fields remain readable as the layout changes. Fixed-size containers can clip content when text becomes larger or wraps onto additional lines.
Controls moving outside the viewport: Watch for menus, search fields, and dialog controls that get pushed off-screen. Users should be able to reach them through an appropriate layout adjustment or scrolling.
Horizontal scrolling: Look for pages that require users to scroll sideways to read each line of text. Check whether wide elements, such as tables or images, are causing the entire page to overflow.
Overlapping elements: Check whether text, navigation, banners, or floating widgets cover other content at increased zoom. Pay particular attention to sticky headers and cookie notices that can occupy much of the available screen space.
Hidden content: Make sure responsive layout changes don’t remove information users need to understand or complete a task. Content moved into a menu or expandable section should still be easy to find and access.
Inaccessible buttons: Try activating important buttons, including those used to submit forms, dismiss notices, or complete purchases. Check that they aren’t clipped, covered by other elements, or placed somewhere users cannot reach.

These checks complement orientation testing; zoom-related issues may fall under other WCAG requirements, such as Resize Text and Reflow. Responsive design should preserve access to information and functionality as the available space changes, so don’t assume a layout is accessible simply because it responds to the viewport.

8. Test Actual User Tasks on an Actual Device

Test your WordPress site in both portrait and landscape mode by completing common tasks, such as navigating menus, submitting a contact form, or checking out, on an actual phone (not just on your computer). In each orientation, make sure users can access the content and controls they need without being forced to rotate their device. Pay attention to messages that block access until the device is rotated, as well as buttons or fields that become unavailable in one orientation.

When you find a restriction, determine whether the orientation is essential to the task or simply a design choice. “That’s how the design was created” generally isn’t enough to justify it. For custom themes, check the CSS and JavaScript for rules or scripts that hide content or prevent interaction based on orientation, then repeat the affected tasks after making changes.

For more guidance on mobile accessibility testing, watch or read the recap for Mobile Accessibility: Building and Testing Accessible Mobile Sites & Native Apps with Gian Wild. The session explores mobile testing guidelines and accessibility features such as screen rotation, pinch zoom, and native screen readers, helping you expand your testing beyond orientation alone.

9. If You Find an Orientation Restriction, Ask One Question

When you encounter an orientation restriction, don’t immediately assume it’s a failure.

Ask:

Is this orientation essential to the activity?

If the answer is yes, document why. If the answer is no, remove the restriction, or redesign the experience so users can access the content and functionality in either orientation.

A Quick WordPress Testing Checklist

When reviewing a WordPress site for WCAG 1.3.4, I like to keep the testing focused on what visitors need to read, find, and do. Start with your most important pages and features, then work through this checklist in both portrait and landscape mode. Test each orientation separately and rotate the device while interacting with the page to catch issues that appear during the change.

Test important pages in portrait. Start with your homepage, landing pages, and other frequently visited content, checking that information and features remain accessible.
Test important pages in landscape. Review the same pages, paying attention to how the reduced screen height affects content, navigation, and fixed elements.
Complete key user tasks in both orientations. Try actions such as finding a product, creating an account, or making a booking without rotating the device to finish.
Test forms and checkout flows. Follow every step, checking that fields, instructions, error messages, and submit buttons remain available.
Test navigation and menus. Open dropdowns, mobile menus, and search interfaces to confirm users can reach the same destinations in either orientation.
Test modals and pop-ups. Make sure users can read the content, scroll when needed, activate buttons, and close the dialog after rotation.
Test interactive WordPress blocks and plugins. Try galleries, sliders, maps, and other components to check that their content and controls work in both orientations.
Look for “rotate your device” messages. Determine whether these messages merely suggest an orientation or block access until the user rotates their device.
Check that essential content isn’t hidden. Watch for information, fields, or instructions that disappear in one orientation without another way to access them.
Check that controls remain usable. Confirm that buttons, links, and other controls aren’t clipped, covered, or pushed into areas users cannot reach.
Test responsive behavior at different viewport sizes. Look for layout changes that make content or functionality unavailable, and investigate whether they depend on orientation or the available space.
Investigate any orientation restriction and determine whether it is truly essential. Document why the activity requires that orientation; a design preference alone doesn’t justify the restriction.

Portrait and landscape layouts can look different while providing an equally usable experience. The goal is to give users access to your content and the ability to complete tasks in the orientation that works best for them.

What About Video and Other Content?

Content doesn’t need to look identical in portrait and landscape mode. For example, a video originally created in landscape can keep its original proportions when viewed in portrait. What matters is that users can watch it and access its controls without being required to rotate their device.

WCAG 1.3.4 allows exceptions when a particular orientation is essential to the content or activity. However, a layout preference or design decision alone doesn’t establish that need. When reviewing your WordPress site, consider whether the content truly depends on a specific orientation or whether the design could adapt while preserving its information and functionality.

Start Making Your WordPress Site More Flexible

WCAG 1.3.4 Orientation helps ensure users can access and operate your website in portrait or landscape mode, unless a specific orientation is essential.

Making your website accessible does not require every layout to look identical in both orientations. Instead, allow your design to adapt while keeping content and controls available. For example, a navigation bar can become a mobile menu as long as users can still reach the same pages. Forms should remain usable, pop-ups should keep their controls within reach, and videos should play without requiring users to rotate their devices. These changes help people use your website in the orientation that works for them, including those whose devices are mounted in a fixed position.

As you review your website, ask yourself one simple question: Could someone access the content and complete the same tasks without rotating their device? If the answer is yes, you’re well on your way to meeting WCAG Success Criterion 1.3.4 and creating a more accessible web experience.