WCAG 1.4.4 Resize text

Who resize text is for

Many people read the web with bigger text than the designer chose. Some have low vision and need large letters but do not use a full screen magnifier. Others are older and find small type tiring. Some set a larger default font size in their browser or phone once and leave it there. All of them expect the page to cope when the letters grow.

When it does not cope, the result is not just ugly. Words disappear behind other boxes, buttons lose their labels, and parts of a form become unreachable. That is the loss of content or function the rule talks about.

What WCAG 1.4.4 actually requires

Three points sum it up:

• Up to 200 percent. The test size is double the default. Text may of course go larger, but 200 percent is what you must support.
• No assistive technology needed. The page must work with the browser's own zoom or text size settings, not only with a separate magnifier program.
• No loss. All text stays visible and readable, and all functions keep working.

The rule does not demand a particular method. Zooming the whole page, which most browsers do by default, is the usual way to meet it. It also does not forbid horizontal scrolling at 200 percent; avoiding two way scrolling is the job of a later rule, 1.4.10 Reflow, which tests at 400 percent.

Testing at 200 percent

1. Load the page on a laptop or desktop at its normal 100 percent size.
2. Press Ctrl++ (or Command++ on a Mac) until the zoom level reads 200 percent. Ctrl+0 resets it.
3. Work down the whole page, section by section. Look at navigation, headings, cards, tables, footers and anything in a fixed box.
4. Open each menu, accordion, modal and tooltip, and fill in at least one form, including its error messages.
5. On a phone, check that you can pinch to zoom. Some sites switch that off in the page code.
6. Optionally, in Firefox choose View, Zoom, Zoom Text Only and repeat. Only the text grows, which exposes boxes that cannot stretch.

Where text breaks when it grows

Let zoom work: the viewport tag and units

Two small pieces of code cause many resize failures. The first is the viewport tag that blocks pinch zoom on phones:

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

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

The second is how boxes and fonts are sized. A rem is a unit relative to the root font size, so it grows when a person raises their default text size. Pair it with boxes that can stretch:

body { font-size: 1rem; line-height: 1.5; }
.card { min-height: 12rem; padding: 1rem; }
.card h3 { font-size: 1.25rem; }

Edge cases auditors argue about

• Horizontal scrolling at 200 percent. Allowed under this rule, though it is a poor experience. The reflow rule sets the stricter bar.
• Content moved into a menu. Fine, as long as it is still reachable at the larger size.
• Text drawn by a script as pixels, or inside a video player. If people can read it and it is not a caption, it should grow too, or the same information must be available as real text.
• Larger text settings on phones. Native apps and web views should respect them. Our mobile apps guide covers this.

How 1.4.4 fits with reflow and spacing

Resize text is the oldest of a family of rules about flexible text. Reflow (1.4.10, added in 2.1) asks for single direction scrolling when zoomed to 400 percent. The spacing rule (1.4.12, also 2.1) checks that layouts survive wider line, letter and word spacing; see our text spacing guide. The rule on pictures of words (1.4.5) keeps text real, so it can grow at all. A layout that passes the reflow test usually passes this one too, so many teams test both in the same session.

For W3C's own explanation and techniques, read W3C Understanding Resize Text. Add this check to your WCAG checklist run for every template, not only the home page.