Search topics
Pages locked to portrait or landscape
An orientation media query hides the page and asks people to turn their phone, or turns the page sideways, so it only works in the orientation its designers chose.
@media (orientation: landscape) and (max-height: 500px) { main { display: none; } } The problem
People whose phone or tablet is fixed in one position can't use a page that only works the other way round.
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.
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.
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.
3 of 10 groups affected
- No vision (not affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (affected)
- Cognitive (not affected)
- Seizures (not affected)
- Limited reach and strength People who can't hold a phone or turn it keep it in a mount on a wheelchair, a bed or a desk, fixed one way round. A page that only works the other way is closed to them, and asking them to turn it doesn't help.
- Limited manipulation People who use a switch or a head pointer often have the device mounted in front of them and set up once for them, so turning it means waiting for someone else to do it.
- Limited vision People with low vision often turn the phone on its side to get bigger text on a wider line, and in landscape the page is gone.
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.
Try it
Order a flat white with the phone upright, then turn it on its side.
Use the switch to turn the phone. Imagine it is fixed in a mount and can only stay one way: can you still read the menu and press Add?
Broken Can you fix this?
Order ahead
The phone is upright. It works this way round. Turn the phone to see the other.
The fix
Delete the orientation lock and let the layout follow the width.
- 1Never hide, cover or turn the page in an orientation media query.
- 2Lay out by width, so both orientations get the same content and controls.
- 3Suggest a better orientation in a note people can dismiss, never in a message that replaces the page.
The page hidden behind a message in landscape
<div class="turn-message">Please turn your phone upright to use this site.</div><main>…</main><main>…</main>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.
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.
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.
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 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.
Fixing this with an AI coding assistant? Get this guide as Markdown, or get every guide in your coding agent.
Verify the fix
5 checks, no mouse.
Test with: Touch, Zoom, Keyboard
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.
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.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.