Mobile Accessibility: Zoom, Reflow and Touch Targets

Updated October 27, 2026 · 8 min read

Many people use a phone with the text enlarged, the page zoomed, or the device mounted in a fixed orientation. Mobile layouts that block zoom, break when enlarged, or use tiny tap targets are common findings in accessibility audits, and they are usually inexpensive to fix.

This guide covers the viewport tag, reflow, text resize, touch target size and orientation. It is general information, not legal advice. For legal questions, such as how a demand letter applies to your situation, talk to an attorney.

Why this matters on mobile

People with low vision often rely on pinch-zoom or larger text settings. People with motor impairments, tremors, or limited dexterity may struggle with small or crowded buttons. Some people use a phone or tablet mounted to a wheelchair, which fixes the screen's orientation.

Automated scanners can reliably catch some of these issues, such as a viewport tag that blocks zoom. Others, like reflow and target spacing, need a quick manual check.

For context on how these criteria fit into the wider standard, see the WCAG 2.1 AA checklist and WCAG 2.2 vs 2.1.

Disabled pinch-zoom: the viewport meta tag

The viewport meta tag tells mobile browsers how to size the page. Some templates add settings that stop users from zooming.

What to remove

This tag blocks zoom:

<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">

Both user-scalable=no and a low maximum-scale (such as 1) restrict zoom. Together they can prevent a user from enlarging the page.

The fix

Use a plain viewport tag:

<meta name="viewport" content="width=device-width, initial-scale=1">

This is the safest pattern. It sets the layout width to the device width and leaves zoom under the user's control.

Notes on browser behavior

Some mobile browsers, notably on iOS, have at times ignored or overridden zoom restrictions to help users. Do not rely on that. Behavior varies by browser and version, and other browsers and assistive settings may respect your restriction. Removing the restriction is the reliable fix.

WCAG addresses this under 1.4.4 Resize Text, which expects text to be resizable up to 200% without assistive technology and without loss of content or function. See WCAG 1.4.4 Resize Text. Blocking zoom can cause a failure of that criterion.

Common sources

• A theme or page builder template that ships with the restrictive tag.
• A copied snippet from an older tutorial aimed at making a site "feel like an app".
• A plugin or app that injects its own viewport tag, creating duplicates. Check the rendered HTML, not just your template.

Reflow: content must work at 320 CSS pixels

WCAG 2.1 success criterion 1.4.10 Reflow asks that content can be presented without loss of information or functionality, and without scrolling in two dimensions, at a width equivalent to 320 CSS pixels (for vertically scrolling content). In practice, a user who zooms in a lot should get a single column that scrolls vertically, not a page they must pan left and right.

There are exceptions for content that needs two-dimensional layout to be usable, such as data tables, maps, diagrams and some images. For those, horizontal scrolling can be acceptable.

Typical reflow failures

• Fixed-width containers (for example width: 1024px) that do not shrink.
• Multi-column layouts that never collapse to one column.
• Wide tables, embedded iframes, or images that overflow their parent.
• Long unbroken strings, such as URLs or email addresses, that push the layout wider.
• Fixed or sticky headers and banners that cover most of a zoomed-in screen.
• Text clipped inside fixed-height boxes.

CSS patterns that help

img, video, iframe {
  max-width: 100%;
  height: auto;
}

.container {
  width: 100%;
  max-width: 70rem;
  padding-inline: 1rem;
}

.long-text {
  overflow-wrap: anywhere;
}

.table-wrap {
  overflow-x: auto;
}

Use relative units such as rem, %, and flexible grids (display: grid with auto-fit or flexbox with flex-wrap: wrap) instead of fixed pixel widths. Avoid setting fixed heights on text containers.

Sticky headers and chat widgets

A tall fixed header can take up much of the viewport once the user zooms. If it blocks content, consider letting it scroll away on small screens. Floating chat buttons and banners can have the same effect. See Cookie Banners, Popups and Chat Widgets: Accessibility Traps.

How to test reflow with browser zoom at 400%

A browser at 400% zoom on a window about 1280 CSS pixels wide produces an effective viewport of about 320 CSS pixels. This is the standard way to check 1.4.10 without a phone.

Steps

1. Open the page in a desktop browser and make the window full width at about 1280 pixels wide. On a larger monitor, resize the window or use developer tools to set a width of 1280.
2. Zoom the browser to 400% (Ctrl and + on Windows or Linux, Cmd and + on Mac, until the zoom reads 400%).
3. Scroll through the whole page, then check key flows such as navigation, search, product pages, cart and checkout.
4. Look for horizontal scrolling, clipped or overlapping text, controls that disappear, and content hidden behind fixed elements.
5. Repeat on each distinct page template, not just the home page.

What to record

Also try the browser's developer tools device mode set to a width of 320 pixels, then confirm on a real phone when you can. Browser zoom approximates but does not perfectly match a real device.

Text resize (1.4.4)

WCAG 1.4.4 expects text to be resizable up to 200% without assistive technology, with no loss of content or functionality. Test it by zooming the browser to 200% and by increasing the default text size in the browser or phone settings.

Things that commonly fail:

• Font sizes set in fixed pixels inside containers that clip content.
• Text embedded in images, which does not scale cleanly.
• Fixed-height buttons or menu items where enlarged text overflows.

Prefer rem or em for font sizes and let containers grow with their content. Related reading: WCAG 1.4.4 Resize Text.

Touch target size and spacing

WCAG 2.2 added success criterion 2.5.8 Target Size (Minimum), at level AA. It generally expects pointer targets to be at least 24 by 24 CSS pixels, with exceptions. One exception allows smaller targets if there is enough spacing around them, so that a 24 pixel circle centered on each target does not overlap another target. Other exceptions cover cases like inline links within a sentence, targets where an equivalent control exists, and sizes determined by the browser.

The 2.5.8 criterion is new in WCAG 2.2 and is not part of WCAG 2.1. Which version applies to you depends on the standard you or your counterparties are using, which is a question for an attorney. The 2.2 changes are covered in WCAG 2.2 vs 2.1.

WCAG 2.2 also has a stricter, level AAA criterion, 2.5.5 Target Size (Enhanced), at 44 by 44 CSS pixels. Many teams use roughly that size as a practical design goal for primary mobile controls, even though AA requires less.

Practical fixes

• Give icon buttons, close buttons and menu toggles a comfortable minimum size, with padding rather than just a larger icon.
• Space out adjacent links and buttons, such as quantity steppers, footer links and filter chips.
• Make the whole row or card a tap target where it makes sense, rather than a tiny text link.

.icon-button {
  min-width: 44px;
  min-height: 44px;
  padding: 10px;
}

Icon-only controls also need accessible names. See Icon Buttons Without Labels.

Orientation lock

WCAG 1.3.4 Orientation (added in 2.1, level AA) expects content not to be restricted to a single display orientation, such as portrait only, unless a specific orientation is essential. People who mount a device in one orientation cannot rotate it.

Check that:

• Your CSS does not hide or break the layout in landscape.
• No script locks the screen orientation for ordinary pages.
• Landscape views still reflow and remain usable.

Genuine exceptions exist, for example a piano app or a check-deposit camera view, but a normal store or brochure site rarely qualifies.

A quick mobile checklist

1. Remove user-scalable=no and low maximum-scale from the viewport tag.
2. Check the rendered HTML for duplicate viewport tags added by plugins.
3. Zoom to 400% on a 1280 pixel window and look for two-dimensional scrolling.
4. Zoom to 200% and enlarge default text size, then check for clipping.
5. Check target size and spacing on navigation, forms, and cart controls.
6. Rotate the device and confirm both orientations work.
7. Test key flows, especially checkout, on a real phone.

Automated tools help with the viewport tag and some target-size checks, but reflow, clipping and spacing usually need a human look. Pair this with a keyboard test and a screen reader pass, and keep notes of what you checked and when, as described in Why a dated accessibility audit record matters.

To see how your pages score on the issues a scanner can detect, you can run a free scan. Remember that no automated tool, and no single fix, can guarantee a site meets WCAG or protects you from a claim.

Frequently asked questions

Is it okay to disable pinch-zoom if my site is designed for mobile?

No. Blocking zoom takes away a basic tool that many people with low vision depend on, and it can cause a failure of WCAG 1.4.4. A responsive layout does not make zoom unnecessary. Remove user-scalable=no and any low maximum-scale value from the viewport tag.

What does 320 CSS pixels mean for my layout?

It is the width at which WCAG 1.4.10 expects content to work without horizontal scrolling. Testing at 400% browser zoom on a window about 1280 pixels wide gives roughly that width. Content like data tables, maps and diagrams can be exempt when two-dimensional layout is needed.

Do I have to meet the 24 pixel touch target rule?

The 24 by 24 CSS pixel rule is in WCAG 2.2 success criterion 2.5.8, not WCAG 2.1. Which version applies to you is a question for an attorney. Even if you target 2.1, adequately sized and spaced targets help real users, so it is a sensible fix either way.

Can I lock my site to portrait orientation?

Generally not. WCAG 1.3.4 expects content to work in both orientations unless a specific one is essential. Some users cannot rotate their device, so a portrait-only restriction can block them. Most ordinary business sites have no essential need for it.

Can browser zoom replace testing on a real phone?

It is a good first check, but not a perfect substitute. Zooming a desktop browser to 400% approximates a 320 pixel viewport, yet phones differ in browsers, text settings and touch behavior. Use both methods and test your most important flows, such as checkout, on at least one real device.

Related

• WCAG 2.1 AA checklist for business websites
• WCAG 2.2 vs 2.1: What Changed and Which One to Target
• WCAG 1.4.4 Resize Text
• A 5-Minute Keyboard Accessibility Test for Your Online Store

Proof of Access provides technical accessibility assessments. We are not a law firm and nothing on this page is legal advice. If you have received a demand letter or a lawsuit, talk to an attorney.