Zoom and reflow (WCAG 1.4.4 and 1.4.10): text at 200% and 400%

W3C says people with low vision might need to zoom in to read a page. Success criterion 1.4.4 Resize Text exists so that doubling the text does not clip it, hide it or break the controls, which lets people with milder visual impairments read without a screen magnifier. Success criterion 1.4.10 Reflow exists because zooming makes content larger but the viewport smaller: when lines run past the edge, W3C says, readers must scroll back and forth, can lose their place and spend much more physical and cognitive effort.

Both are Level AA. W3C's ACT rule on the viewport tag says 1.4.4 applies to WCAG 2.0 and later, but 1.4.10 was added in WCAG 2.1 (what is new in WCAG 2.1), so a standard that stops at 2.0 does not include it; see which WCAG version applies. A CSS pixel is the unit a browser lays a page out in, not a physical screen pixel, which is why zooming changes how many fit across a window. Every size below is in CSS pixels.

What each criterion requires

How the two criteria fit together

Resize Text asks whether text can get bigger without damage. Reflow asks whether the whole page still works in a narrow column. W3C says text should be enlargeable to 200 percent while the page still meets Reflow.

Resize Text is mostly the browser's job. W3C says browsers are primarily responsible for scaling, through full-page zoom, text-only resizing and user-set text sizes. Content passes if it scales to 200 percent by at least one mechanism browsers support, so the author's job is not to block that scaling and not to break when it happens. If the zoom mechanism, whether the browser's or the author's, offers steps between 100% and 200%, none of them may lose content or functionality. A truncated label can pass when the full text is available on focus or activation and users are told.

Reflow does not require text to grow. W3C's example is a responsive page with 20 pixel text at 1280 pixels wide and 10 pixel text at 320 pixels wide. At 400% zoom the 10 pixel text is still displayed at twice the size of the 20 pixel text at 100% zoom, so 200% enlargement remains available.

Responsive design can meet Reflow. Rearranging content is not a loss while everything stays reachable. W3C's example is a one-column page where, as zoom increases, the navigation moves into a "More" menu and then a hamburger button, with every function still available. Removing a control to make the page fit is the failure F102 describes.

1.4.4 excepts images of text, but W3C prefers real text. Images of text tend to pixelate when scaled and are harder to adjust for contrast and color (see images of text).

What 200% and 400% mean in practice

Zoom does not change the window. It makes every CSS pixel bigger, so fewer fit across it. Divide the window's width at 100% by the zoom to get the width the page is laid out at:

The 200% row is our arithmetic. The other three are W3C's equivalences on its Reflow page, including 256 CSS pixels tall for content that scrolls horizontally, such as vertical text. W3C notes that 400% applies to each dimension, not to the area. Real windows come out a little smaller: its example of a 1280 by 1024 display at 400% measured about 318 by 236 pixels, because the scrollbar and the browser's toolbars take space. The criterion does not require devices to support those exact sizes. Our advice: test at the zoom your browser gives you and, where you can, at an exact 320 pixel width.

Test it in six steps

The sequence is GotAlt's routine. The pass conditions in it come from the two W3C Understanding pages.

1. Start at 100%. Open the page in a desktop browser with the window as wide as it goes. Every later step is a comparison with this.
2. Zoom to 200%. Use the browser's zoom (Ctrl and plus on Windows, Command and plus on a Mac) and read the whole page. Look for text that is clipped, overlaps another line or sits in a box that did not grow, and for controls that no longer fit. Check the steps between 100% and 200% as well.
3. Zoom to 400%. The page is now laid out about 320 CSS pixels wide. Scroll down: you should only scroll vertically. A horizontal scroll bar on the page fails unless it comes only from content that needs a two-dimensional layout and everything else still reflows.
4. Use every function. At 400%, open the menu, search, filters, a form, the cart, the cookie banner and any dialog. Each must still be reachable and usable.
5. Tab through the page. Focus should stay visible and not disappear behind a sticky header or footer, which W3C notes can cover focused elements in zoomed views. Our keyboard accessibility test covers this as its focus not obscured check.
6. Repeat on each template. Check one home page, article, listing page, form and checkout rather than every URL, because pages built from a template share their layout code. This is GotAlt's suggestion, not a W3C method.

Write down the page, the zoom level and the element for each problem so a fix can be retested at the same setting. Zoom is one of the checks in how to test website accessibility.

What fails and how to fix it

The codes are the W3C technique and failure IDs listed on the two Understanding pages, and the middle column is our reading of what usually causes each symptom. The viewport-unit failure shows how: zooming shrinks the viewport measured in CSS pixels, so text sized only as a share of the viewport shrinks with it and ends up the same size on screen. For choosing sizes in the first place, see accessible typography.

W3C's "Meta viewport allows for zoom" rule fails a viewport tag that sets user-scalable to no or sets maximum-scale below 2. It maps the rule to 1.4.4 and notes that the rule relates to 1.4.10 as well. The simplest fix is to set neither:

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

MDN warns that user-scalable=no prevents people with low vision from reading and understanding a page, and says WCAG requires a minimum of 2 times scaling while the best practice is to allow 5 times. The ACT rule adds that desktop browsers ignore the viewport tag and most modern mobile browsers ignore it by default or offer an option to allow zooming, so only people with older mobile browsers can experience the problem the rule tests. A page can fail the rule and still satisfy 1.4.4 when another mechanism lets the text be resized.

What may scroll in two directions

Reflow excepts parts of a page that need a two-dimensional layout for usage or meaning, such as maps, diagrams, video, games, presentations and data tables. Three limits keep the exception from swallowing the rule:

• It covers the part, not the page. W3C's failing example is a page with both scrollbars where the table meets the exception but the paragraphs after it do not reflow. Its passing example puts the table in its own scrollable container, so two-direction scrollbars do not appear at the page level.
• A table's grid is excepted; what surrounds it is not. Per W3C, individual cells, headings, search fields and pagination should still reflow. Our guide to accessible data tables covers the scrollable container and keyboard access.
• Media should still fit. W3C's example of a video with no maximum width of 100% passes because everything else reflows, but W3C calls the page-level scroll bar it causes unnecessary, since readers may look for content that is not there. Slicing a graphic into stacked blocks, W3C says, would make it difficult to understand, so keep media inside the viewport instead (C37). Horizontal carousels pass when each panel fits within 320 CSS pixels (G225); see accessible carousels.

Text spacing sits next to these checks

A third criterion, 1.4.12 Text Spacing (Level AA), fails for a similar reason: boxes that clip or overlap text. It asks for no loss of content or functionality when a reader sets line height to at least 1.5 times the font size, spacing after paragraphs to 2 times, letter spacing to 0.12 times and word spacing to 0.16 times (W3C's Understanding page). W3C lists F104 for clipped or overlapped content when text spacing changes.

What automated tools can and cannot see

Zoom is a partly automated area. A rule can flag a viewport tag that blocks zoom, and the free scan does. Everything else depends on laying the page out at a size: whether text is clipped, whether a control has vanished, whether a sticky bar covers focus. Our automated testing coverage page says software can detect sideways scrolling at that width, but whether content or function is lost needs a person.

None of GotAlt's checks measures reflow or clipped text at 200% or 400%. The free scan reads the HTML a server sends, and the browser check on monitored pages loads each page once at one window size; what we check explains why. Treat a clean scan as a viewport tag that allows zoom, not as a pass.

Check it yourself

The main tool is a browser zoom and a pair of eyes. These free tools help around it:

• The accessibility bookmarklet does not measure zoom or reflow. It reads the page as your browser has rendered it, so you can zoom in, open the collapsed menu, run it and see the names, labels and text contrast of the layout a zoomed-in reader gets. In W3C's example, navigation moves behind a menu button as zoom increases; the bookmarklet can tell you whether that button has an accessible name. "Run the checks again" re-reads the page after you change the zoom. Using it this way is our suggestion.
• Scan my site for free flags a viewport tag that disables zoom on the pages it scans, alongside its other rule-based checks.
• The WCAG audit checklist tracks all 55 Level A and AA criteria, including 1.4.4 and 1.4.10, and exports a CSV file. It keeps one status per criterion for each audit, so keep one audit per template or note the template with each result.

This page is general information, not legal advice. A pass at 200% and 400% does not show that a site meets WCAG or any law. Email newsletters meet the same narrow-width questions; see accessible email newsletters.