Zoom means enlarging a page, usually with Ctrl or Cmd and the plus key, and two WCAG rules govern what has to survive it. Text has to resize to 200% without losing content or function, and captions and images of text are the two things that rule exempts. Then reflow takes over at a viewport equivalent to 320 CSS pixels wide, or 256 tall for content that scrolls sideways, where reading must never ask you to scroll in two directions at once and nothing may be lost getting there. It does not require the page to become a single column. Those are two different tests, so zooming to 200% can leave a viewport still wider than reflow's target, and two-dimensional scrolling there is not a reflow failure. Browser zoom is the route almost every site takes to the first rule, so an in-page text-size widget is usually work you do not need. It only counts where the text actually reaches 200% and nothing is lost getting there. If your layout clips, overlaps or hides buttons when zoomed, browser zoom has not satisfied anything and that is the failure the first rule was written to catch.
In practice
Two different things get called zoom and the rules treat them as alternatives. Browser zoom scales everything. Text-only resizing scales just the type, and it is what breaks fixed-height containers first. The 200% requirement can be met by any one text-scaling route the browser supports, so browser zoom usually does the job on its own and an in-page text-size widget is work nobody asked for. The word usually is load-bearing. What the rule wants is text at 200% with no content and no function lost, so a layout that comes apart at that size has not been rescued by the browser having a zoom control.
Keep the two tests apart when you write a finding, because reflow is easy to over-apply. It asks for 320 CSS pixels of width for content that scrolls down, 256 of height for content that scrolls sideways, and no information or functionality lost at either. It does not require a single column, and parts of a page that genuinely need two dimensions, like a map or a data table, are excused outright. It also has a floor. Until the viewport reaches the size it names, its test has not been run, so a page scrolling both ways at 200% zoom in a wide window has not failed it and has not passed it either.
The 200% figure has a reason behind it. W3C explains it as complementing older screen magnifiers, which started at 200%, so the number was set against what people already had rather than picked as a round one.
What actually breaks is worth knowing by name. Content that clips, truncates or gets covered at 200% is the classic failure. Form controls that do not grow with the text inside them is another. The modern one is text sized in viewport units, which does not respond to browser zoom the way rem does. A codebase full of vw font sizes can look fine until somebody zooms.
Zoom does not rescue a small target either. Zooming does not change the CSS pixel size of an element, so a control that fails the target size rule at 100% fails it at 400% too. You cannot answer that finding by telling somebody to zoom in.
Why it matters
Enlarging the page is the first adaptation low vision reaches for, and it is why two separate rules exist rather than one. Testing at 100% on a large monitor tests a case the people who need those rules never see. It is also cheap to check, because both tests are things you can do to your own site in a browser you already have open, without installing anything or booking anybody.
The disqualifier
Disabling pinch-zoom on mobile with user-scalable=no is an attempt to take magnification away before any of the rest of this applies. It no longer always lands, because Safari on iOS has ignored it since iOS 10 and other browsers offer a setting to override it, and an app embedding your page in a web view can still honour it. Search your codebase for it anyway, and check whatever generated your viewport meta tag while you are there, because that line is often something a starter template wrote rather than a person.
Where this shows up on the site
Related terms
- ReflowReflow is content rearranging itself to fit a narrow viewport instead of making you scroll sideways to read every line.
- Low visionLow vision is sight loss that ordinary glasses cannot correct, and it covers far more ground than a single blurred-vision picture suggests.
- Screen magnifierA screen magnifier enlarges part of the screen, from the zoom built into every operating system up to dedicated software like ZoomText.
- PerceivablePerceivable is the first of WCAG's four principles, and the standard states it as information and user interface components being presentable in ways people can perceive.
- Contrast ratioA contrast ratio is a number from 1:1 to 21:1 measuring how far apart two colors are in brightness, computed from a formula rather than judged by eye.
Knowing the word is the easy part.
Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.