"We're responsive, we tested the breakpoints, mobile is fine." It is a reasonable thing to believe after a QA pass that opened the site on a few device widths and confirmed nothing visually broke. It is also, very often, wrong in a specific and predictable way, because resizing a desktop layout down to fit a phone screen and building a genuinely usable phone experience are two different problems, and the shortcuts that make the first one look fine on a quick visual check are frequently the exact things that break the second one for real users.
This is not about touch target sizing, which is its own well-covered failure category. It is about two quieter, more structural failures that responsive breakpoint testing routinely misses entirely, because both of them can look completely fine in a five-second glance and only actually break the moment a real user with low vision, or a user relying on browser zoom, tries to use the page as intended.
The Stat: The most damaging responsive accessibility failure is restricting user zoom in the viewport meta tag, setting user-scalable=no or capping maximum-scale at 1.0, which breaks the page completely for low-vision users regardless of any other fix on the page. (Source: W3C WCAG 2.1, Success Criterion 1.4.10 Reflow)
Failure One: Locking Down User Zoom
Many mobile sites still ship a viewport meta tag with user-scalable=no or maximum-scale=1.0, most often added years ago to prevent an accidental double-tap-zoom from disrupting a carefully designed layout, and never revisited since. The consequence is severe and specific: a low-vision user who relies on pinch-to-zoom to read text at a comfortable size loses that ability completely, on every page, for every piece of text, regardless of how good the site's color contrast or font choices otherwise are. No other accessibility fix on the page compensates for this, because zoom is the user's own compensating mechanism, and this setting removes it outright.
The fix is almost always a one-line change: removing user-scalable=no and any maximum-scale restriction below a reasonable ceiling (WCAG's Resize Text guidance effectively expects support up to 500% zoom without loss of content or function). The layout concerns that originally motivated the restriction are almost always better solved with actual responsive CSS than with disabling zoom entirely, which solves the layout team's problem by creating a much larger one for a real user.
Failure Two: Fixed-Width Containers That Break Reflow
The second failure is quieter and harder to catch with a glance: layout containers, embedded videos, or form inputs given a static pixel width rather than a fluid, percentage- or viewport-relative one. At a normal zoom level this often looks completely fine, because the fixed width happens to be narrower than the viewport. The moment a user zooms in, or the moment the page is viewed on a narrower device than whatever width was hardcoded, content overflows the visible area, and the user is forced into horizontal scrolling just to read a single line of text, a functional failure of WCAG 1.4.10 Reflow.
This failure is genuinely easy to miss in routine breakpoint testing, because breakpoint testing usually checks a fixed set of common device widths at default zoom, exactly the condition under which a fixed-width element is least likely to visibly break. It surfaces specifically when a real user does something breakpoint testing does not simulate: zooms in, uses an unusually narrow or unusually wide real device, or has larger default font settings configured at the OS level.
Why These Two Compound Each Other
Locked zoom and fixed-width layout are each bad independently, and considerably worse together. A user who cannot zoom because of the first failure has no way to compensate for text that is genuinely too small to read comfortably. A user who can zoom, because the first failure has been fixed, but runs into the second failure the moment they do, gets a new problem in exchange for solving the old one: the layout breaks and overflows exactly when they use the one tool available to make it readable. Fixing only one of the two often just moves where the failure shows up rather than resolving it.
How This Differs From Touch Target Sizing
It is worth being explicit that this is a different failure category from touch target sizing, which our existing mobile accessibility touch targets piece covers directly. Touch target size is about whether a control is physically large enough to tap accurately. Zoom locking and layout reflow are about whether the page's actual content, independent of any specific control, remains readable and usable once a user needs to view it larger than the design's default assumption. A site can have perfectly sized touch targets and still fail both of the failures covered here, and vice versa; they are separate checks worth running separately, not substitutes for each other.
Why Breakpoint Testing Alone Misses Both Failures
It is worth being specific about why a normal QA pass across a handful of device widths so reliably misses both of these. Breakpoint testing is designed to confirm the layout adapts correctly across a defined set of common screen sizes, at the browser's default zoom level. Both failures described here sit outside exactly that test condition: locked zoom only becomes a problem the moment a user actually tries to zoom, something a breakpoint checklist never does by design, and fixed-width overflow often stays invisible until either zoom or an unusually sized device pushes content past a hardcoded boundary. A QA process can run cleanly through every planned breakpoint, get full marks, and still ship both of these failures untouched, because neither one requires a new screen width to trigger. Both require a user actually doing the thing the fixed layout assumed nobody would need to do.
What to Actually Check
Two concrete tests catch both of these directly: try to pinch-zoom on a real mobile device and confirm it actually works, and once zoomed in, confirm no content requires horizontal scrolling to read a single line of text or use a single control. Both take under two minutes and neither requires specialized tooling, just a real phone and a willingness to actually zoom in rather than trusting that breakpoint testing already covered it.
For a full breakdown of interaction-order failures that show up under similar conditions, our focus management checklist for single-page apps covers a related but distinct class of mobile and SPA-specific issues worth checking alongside these two. If your mobile experience has never been tested at real zoom levels on a real device, our free accessibility tools are a fast first pass, and our team is reachable directly at experts@wcag.world for a deeper manual review. The W3C's own guidance on Reflow and Resize Text are both worth reading in full for the complete technical requirement behind both fixes above.