Resize text 200 percent and reflow: WCAG 1.4.4 vs 1.4.10 explained

Resize text 200 percent: what SC 1.4.4 requires

SC 1.4.4 is aimed first at people with milder visual impairments, who can read enlarged text without a screen magnifier. It covers visually rendered text, including controls and labels that use text.

The W3C states that scaling is primarily the user agent's responsibility: full-page zoom, magnification, text-only resizing, or a text size the user configures. The author's job is to create content that does not prevent the browser from scaling it effectively. Content passes if it can be scaled up to 200% using at least one text scaling mechanism supported by user agents.

Two details matter in practice. First, 200% means up to twice the width and height. Second, if the mechanism offers steps between 100% and 200%, there must be no loss of content or functionality at those intermediate steps, so testing at 200% alone is not enough.

• Excluded: captions and images of text (the latter are also addressed by SC 1.4.5).
• Not covered: content and interface elements controlled by the user agent or platform, such as title attribute tooltips or the operating system's file dialogs.
• If a technology's user agents lack a mechanism such as full-page zoom, the author must provide one or make sure the content works with what is available.

Reflow at 320 CSS pixels: what SC 1.4.10 requires

SC 1.4.10 requires content to be presentable without loss of information or functionality, and without two-dimensional scrolling, for vertically scrolling content at a width equivalent to 320 CSS pixels and for horizontally scrolling content at a height equivalent to 256 CSS pixels. For horizontal languages (left-to-right or right-to-left), text wraps within the width of the viewport; for vertical languages, within its height.

The problem it solves is concrete: when lines run past the edge of the viewport, someone who has enlarged the content has to scroll back and forth to read each line. They lose their place and have to put in more effort. The W3C notes that reflow also helps people on mobile devices and people zooming on larger screens.

Why 320 px? According to the criterion's note, 320 CSS pixels is equivalent to a starting viewport 1280 CSS pixels wide at 400% zoom. The W3C points out that 400% applies to each dimension, not to the area. The value also matched small mobile viewports when the criterion was drafted. In practice the scrollbar and browser interface take up space: on a 1280 × 1024 display at 400% zoom, the usable viewport is 318 × 236 pixels.

Resize text vs reflow: how the two criteria differ

According to the W3C, SC 1.4.4 overlaps with the goal of reflow: it should be possible to increase all text to at least 200% while still meeting 1.4.10. Reflow, on the other hand, does not itself require any level of text enlargement. The two criteria complement each other rather than replace each other.

Responsive sites show how they interact. SC 1.4.4 applies to every layout variant. The W3C uses the example of 20px text in a 1280px window: after zooming to 400%, the page reflows into a 320 CSS pixel viewport, and the author may set the text size to 10px. That text is still displayed at twice the size of the browser default at 100% zoom, even though its CSS size has been halved. Reaching 200% text enlargement while staying inside one specific breakpoint is not required.

• 1.4.4: does text become twice as large without losing anything, including at intermediate steps?
• 1.4.10: at 320 px wide (or 256 px high for horizontally scrolling content), outside exempted content, can everything be read and used without loss, with scrolling in one direction only?
• Above 200%, the W3C notes that zoom, which enlarges text, images and layout regions onto a larger canvas, may be more effective than text resizing; assistive technology dedicated to zoom would usually be used in that situation.

Exceptions you need to know

SC 1.4.10 excludes parts of the content that require a two-dimensional layout for usage or meaning. The criterion's note lists images required for understanding (such as maps and diagrams), video, games, presentations, data tables (not individual cells), and interfaces where toolbars must stay in view while manipulating content. Two-dimensional scrolling is acceptable for those parts.

The exception only covers the section concerned and does not automatically extend to other content. Around a data table placed in its own scrolling container, headings, search fields, pagination and, more generally, the rest of the content must still reflow. Page-level scrollbars in both directions caused by exempted content can pass if the rest of the content only scrolls in one direction, but it is better to confine two-dimensional scrolling to the section that needs it; for example, max-width: 100% on a video removes an unnecessary scrollbar.

• Code and nested lists: indentation conveys hierarchy and can be necessary for code to work; preformatted text whose layout carries meaning (Python indentation, ASCII art) is exempted.
• Carousels: horizontal scrolling inside the carousel is acceptable if each panel fits within 320 px.
• Fixed-size documents shown at print dimensions: they can keep their size, but related panels such as comments are expected to reflow to 320 px.
• For 1.4.4, labels that are too narrow (a webmail subject column, a spreadsheet cell) may be truncated if their full content is available on focus or after activation and the user is told it can be accessed.

Documented failures for resize text and reflow

The Understanding documents for SC 1.4.4 and 1.4.10 list four failures (F69, F80, F94 and F102). Added to these are points of attention drawn from the W3C's test rules and recommendations, which are not listed failures as such.

• F69: resizing text up to 200 percent causes text, images or controls to be clipped, truncated or obscured.
• F80: text-based form controls do not resize when text is resized.
• F94: incorrect use of viewport units to resize text.
• F102: content disappears and is no longer available once the page has reflowed.
• Point of attention: a meta viewport tag that blocks zoom; the related test rule checks precisely that the meta viewport allows zoom.
• Point of attention: sticky or fixed content, such as headers and footers, which can make reading difficult or impossible in small viewports; the W3C strongly suggests making it static at small sizes or letting users toggle it, and reminds that it must not hide the focused element (SC 2.4.11).
• Point of attention: a video wider than the viewport can add an unnecessary scrollbar; max-width: 100% prevents this.

How to fix it: techniques recommended by the W3C

For 1.4.4, the sufficient techniques include using a technology whose common user agents support zoom, liquid layout, and ensuring that text containers resize when the text resizes (containers sized in em, font sizes in percent, named sizes or em, size and position calculated so they scale with text). Another route is to provide on-page controls that progressively enlarge all text up to 200%, or to ensure no loss of content when text grows while its containers keep their width.

For 1.4.10, the W3C cites Flexbox to reflow content, media queries and CSS grid to reflow columns, handling long URLs and strings of text, and width, max-width and Flexbox to fit labels and inputs. As advisory techniques, it mentions media queries to un-fix sticky headers and footers, and max-width and height to fit images. For long strings such as authentication keys, truncated display with a link or reveal mechanism is given as an example.

In practice, the main navigation can collapse into a "More" menu and then into a hamburger button, with no loss of functionality and no horizontal scrolling. An article page can stack into a single column that fits in 320 px. Not everything has to be stacked: each section just needs to be readable without two-dimensional scrolling. The code sample below, written for this article, illustrates these principles.

<!-- Do not block zoom -->
<meta name="viewport" content="width=device-width, initial-scale=1">

<style>
  /* Relative sizes: text follows the user's setting */
  body { font-size: 100%; }
  .callout { padding: 1em; min-height: 3em; } /* no fixed height in px */

  /* Reflow with Flexbox */
  .cards { display: flex; flex-wrap: wrap; gap: 1em; }

  /* Keep media inside the viewport */
  img, video { max-width: 100%; height: auto; }

  /* In small viewports, the header is no longer fixed */
  @media (max-width: 30em) {
    header { position: static; }
  }
</style>

Testing resize text and reflow step by step

A manual test reproduces the situations the W3C describes. Back it up with continuous monitoring to catch regressions introduced by template updates.

• Zoom the browser in steps from 100% to 200% and check at each step that all text remains visible, nothing is clipped or overlapping, and form fields grow.
• Also try text-only resizing where the browser offers it.
• Set a window 1280 px wide and zoom to 400%: check that, apart from content requiring a two-dimensional layout, only vertical scrolling is needed and nothing has disappeared.
• Check navigation, fixed headers, tables, videos and long URLs, then make sure the focused element is not hidden.
• Some user agents, especially older mobile browsers, cannot resize to these exact values; the criterion does not require devices to support them. Test with a browser that does.

Frequently asked questions

Further reading on Conformly

• Guide to fixing 200% zoom in HTML
• Detailed page on RGAA criterion 10.4
• Detailed page on RGAA criterion 10.11

Sources

This article relies on the official sources listed at the end of the page.

• W3C — Comprendre 1.4.4
• W3C — Comprendre 1.4.10