# Pages locked to portrait or landscape
Source: https://easeweb.dev/learn/orientation
Topics: Zoom, reflow and text spacing > Pages work in portrait and landscape (WCAG 1.3.4)
The fix: Delete the orientation rules that hide the page, cover it with a message or turn it sideways, and let the layout follow the width instead: one column on a narrow screen, more when there is room. Where one orientation suits a part better, say so in a note people can dismiss, over a page that still works.
Test with: touch, zoom, keyboard
References: https://www.w3.org/WAI/WCAG22/Understanding/orientation.html https://www.w3.org/WAI/WCAG22/Techniques/failures/F97 https://www.w3.org/WAI/WCAG22/Techniques/failures/F100 https://www.w3.org/WAI/standards-guidelines/act/rules/b33eff/ https://developer.mozilla.org/en-US/docs/Web/CSS/@media/orientation https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Manifest/Reference/orientation
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
## What happens
A café's order-ahead page lists its drinks and food, each with a price and an Add button. Held upright, it works. Turn the phone on its side and the menu disappears: in its place, centred on a white screen, is "Please turn your phone upright to use this site." Nothing else on the page can be read or pressed until the phone is turned back.
The same lock is often written the other way round. A page designed for a wide screen, such as a seat map, a game or a slideshow, turns itself sideways in portrait with a CSS transform, so its text runs down the screen and only reads once the phone is turned.
## Why it fails
Success criterion 1.3.4, Orientation, is level AA and was added in WCAG 2.1. Content must not restrict its view and operation to one display orientation, portrait or landscape, unless that orientation is essential. W3C names both forms here as failures: F100, a message asking people to reorient the device, and F97, locking the orientation, which includes turning the page with a transform.
The criterion is about the page, not the person's own settings. Someone who has locked their phone's rotation has chosen an orientation, and a page without a lock follows it. The essential exception is narrow: the Understanding document's examples are a banking page that photographs a cheque, which is wider than it is tall, and a piano whose keys would be too small in portrait. "It looks best this way" is not essential, and neither is a design that was only ever drawn one way round.
Changes that come from the size of the screen are not covered either. A page that shows one column in portrait and two in landscape passes, because nothing is restricted: both views have the same content and controls.
## Who is affected
The lock usually comes with a height limit, such as `max-height: 500px`, so it only fires on phones. That is exactly where the mounted devices are, and on a desktop or a laptop no one on the team ever sees it.
## What automation and AI miss
A scanner loads the page once, at one window size, so it only meets one orientation, and the page works in that one. axe's orientation rule looks for a page turned with a transform, but it is experimental and is not part of a standard run, and it doesn't look for content hidden behind a message. EaseWeb's audit renders each page in both orientations at phone size and reports content that one of them hides or covers. A code assistant asked to "make the page portrait only" writes the very media query that fails, and asked to fix 1.3.4 it sometimes softens the message's wording and leaves the page hidden.
## Before: the page hidden behind a message in landscape
```html
Please turn your phone upright to use this site.
…
```
```css
.turn-message {
display: none;
}
@media (orientation: landscape) and (max-height: 500px) {
main {
display: none;
}
.turn-message {
display: flex;
align-items: center;
justify-content: center;
min-height: 100vh;
}
}
```
On a phone held sideways, the media query hides the whole menu and shows only the request to turn the phone. A person who can't turn it can't order.
## Before: the page turned sideways in portrait
```css
@media (orientation: portrait) {
body {
transform: rotate(90deg);
transform-origin: top left;
position: absolute;
top: 0;
left: 100%;
width: 100vh;
height: 100vw;
}
}
```
In portrait, the page is drawn on its side, so it only reads in landscape. Everything is still there, but its text runs from the top of the screen to the bottom, and a phone fixed upright can't be turned to straighten it.
## After: one layout that follows the width
```html
…
```
```css
/* No orientation rules: the menu is one column on a narrow screen,
and two or more where there is room, in either orientation. */
.menu {
display: grid;
gap: 1rem;
grid-template-columns: repeat(auto-fill, minmax(min(100%, 16rem), 1fr));
}
```
The message and the orientation rules are gone, so the page shows the same menu both ways round. In landscape the phone is wider, so the grid fits two columns; in portrait it fits one. The layout responds to the space it has, which is what an orientation query was standing in for, and it also works in a narrow window on a desktop or a split screen on a tablet, where orientation says nothing useful.
## Implementation decisions
Keep orientation queries out of decisions about what is shown. If a layout really is better in one orientation, such as a wide seat map, there are ways to say so without locking:
- A suggestion: a short note, such as "Turn your phone for a bigger map", that people can dismiss, with the map still usable beneath it.
- Scrolling inside its own box: the map keeps its width and scrolls sideways within a frame people can reach and scroll with a keyboard, as [pages that scroll sideways on a narrow screen](/learn/reflow) describes.
- A control: a button that switches the part to a view that fits, such as a list of seats instead of the map. W3C's technique G214 describes this.
A phone in landscape is short: about 390 CSS pixels tall, less once the browser's own bars are drawn. A sticky header, a cookie banner and a bottom bar together can leave almost nothing of the page to read. That is not a lock, but it makes landscape unusable all the same. Let fixed bars scroll away, or shrink them, below a height of about 500 pixels.
Scripts and installed web apps can lock orientation too. `screen.orientation.lock()` works only in full screen, so it turns up in games and video players; leave it out, or offer it as a choice people make. An installed web app takes its orientation from its manifest's `orientation` member: leave the member out, or set it to `any`.
Turning the phone fires `resize`, and some pages rebuild themselves on it. Keep what people typed, what they opened and where focus was when the orientation changes.
## Verify the fix
1. Open each page template on a phone held upright, then turn it on its side, or use the browser's device toolbar at 390 by 844 and 844 by 390 pixels. Confirm the same content and controls are there both ways, and nothing asks you to turn the phone.
2. With the phone's rotation lock on, complete the site's main tasks, such as ordering or signing up, once in portrait and once in landscape.
3. Turn the phone halfway through a task, with a form half filled and a menu open. Confirm nothing typed is lost, and focus stays where it was.
4. Repeat steps 1 and 2 on a tablet, or at 768 by 1024 and 1024 by 768 pixels.
5. Search the stylesheets and scripts for orientation media queries, `screen.orientation.lock` and the manifest's `orientation`, and confirm none of them hides, covers or turns the page.
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the site's layout or shared styles change.
## Limits
This is a starting pattern, not a guarantee for every page. Some content does need one orientation, and the essential exception covers it, but only that part: the rest of the site still has to work both ways. A layout that passes 1.3.4 can still fail other criteria in landscape, such as text cut off at a short height or a focused control hidden under a sticky bar. Test the complete journey on the devices and mounts your users rely on.
---
Get this guide in your coding agent: MCP https://easeweb.dev/mcp (setup at https://easeweb.dev/services/developers)