1.4.4 Resize Text

Level AA
Perceivable
Since WCAG 2.0

Summary

Many people with low vision do not use a screen reader or magnifier; they simply need the text bigger. This criterion protects them: text must be able to reach 200 percent of its default size using only what the platform already offers (browser zoom, text size settings, system font scaling), and at that size nothing may be lost. "Without assistive technology" is the key phrase: the user should not need special software, because zoom and text-size controls built into browsers and operating systems count as the mechanism.

The auditor's mental model is a two-part check. First, can the text actually get to 200 percent, or does something block it (fixed pixel fonts that ignore user settings, a viewport that disables pinch zoom)? Second, once it is there, is everything still present and working, or does text clip, overlap, truncate into uselessness, or push controls off screen or under other content? Captions and images of text are exempt here, and it is only content and functionality that must survive; the layout is allowed to get ugly.

Official wording

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Success Criterion 1.4.4 Resize Text, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, 5 October 2023 (updated 12 December 2024). Copyright © 2023-2024 World Wide Web Consortium. https://www.w3.org/copyright/document-license-2023/. Reproduced unmodified under the W3C Document License.

EN 301 549 mapping

Web pages: Clause 9.1.4.4
Software and native apps: Clause 11.1.4.4
Closed functionality (kiosks, terminals): Software that cannot access platform or assistive text enlargement must meet clause 5.1.4 (functionality closed to text enlargement).

Clause 9.1.4.4 applies this criterion to web pages unchanged and clause 11.1.4.4 applies it to software that can reach platform or assistive text enlargement. Software that cannot must instead meet clause 5.1.4 on functionality closed to text enlargement.

Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.

In practice

Web

Test two mechanisms. First, full-page zoom: press Ctrl or Cmd and plus until the browser reports 200 percent, then walk the page. Read every region for clipped or overlapping text, check that text in fixed-height containers (height in px with overflow: hidden) has not been cut off, expand menus, dialogs, tooltips, and accordions, and confirm every control is still reachable and operable. Second, text-only zoom where the browser supports it (Firefox's "Zoom Text Only" is the standard tool): this scales text without scaling containers, which is exactly the condition that exposes px-fixed boxes, and it is a legitimate way to pass or fail the criterion. A page needs to survive at least one author-supported path to 200 percent text; if full-page zoom to 200 percent works with no loss, the criterion is met even when text-only zoom breaks things.

On mobile web, inspect the viewport meta tag first. maximum-scale=1 or user-scalable=no disables pinch zoom, removing the user's scaling mechanism on the platform where they need it most: a classic, unambiguous fail that takes ten seconds to find in devtools. Also check text set in viewport units (vw) without a calc or clamp fallback, which can refuse to respond to zoom at all.

Grade what is lost, not what looks cramped. If text reaches 200 percent and every word and function is still available (even via an added scrollbar), it passes here; a layout that forces two-dimensional scrolling is a different criterion (see below).

iOS

The European standard applies this criterion to apps through the platform's own text enlargement: an app that can access Dynamic Type must respond to it, and an app that cannot must provide its own text sizing control. In practice, grade native iOS apps against Dynamic Type.

Set text size in Settings, Accessibility, Display and Text Size, Larger Text, with Larger Accessibility Sizes enabled. The standard (non-accessibility) sizes top out well short of doubling; 200 percent of the default body size is only reached around the second and third larger accessibility steps, so test at those sizes or above, then walk every screen. Text that never changes size is the primary fail: fonts created with a fixed point size (UIFont.systemFont(ofSize:) without a metrics wrapper, or hard-coded sizes in SwiftUI instead of text styles) ignore the user's setting entirely, so the text can never reach 200 percent. Labels that scale but truncate to a single ellipsised line, buttons whose enlarged titles overlap neighbouring controls, and tab bars or toolbars whose labels vanish at accessibility sizes are the loss-of-content fails.

Xcode helps: the Environment Overrides panel (or Accessibility Inspector's settings pane) changes Dynamic Type size live against a running app, which makes sweeping every screen quick. Check that adjustsFontForContentSizeCategory is doing its job by toggling sizes while the screen is open, not just at launch: text that only updates after an app restart still passes the criterion, but note it as a quality issue.

Android

The same European standard logic applies: apps must honour the platform's text enlargement. Modern Android exposes font scaling up to 200 percent in Settings, Display, Display size and text (font scale settings vary slightly by version and manufacturer skin). Set it to maximum, or set it precisely from a connected machine with adb shell settings put system font_scale 2.0, then walk every screen.

The primary fail is unit misuse. Text sized in sp scales with the user's preference; text sized in dp does not, so any dp-sized text is frozen at 100 percent and fails, because the user's mechanism has been silently disconnected. In Compose, watch for nonScaledSp-style helpers or conversions that divide by fontScale to "protect the design": these deliberately opt text out of user scaling and are the same fail dressed up as a utility function. Layout Inspector in Android Studio shows resolved text sizes and bounds, and "Show layout bounds" in developer options reveals fixed-height text containers on device.

At 200 percent scale, look for the loss-of-content patterns: single-line TextViews with ellipsize swallowing critical text, fixed-height cards clipping their contents, bottom navigation labels disappearing, and dialog buttons pushed outside the visible dialog. As on iOS, wrapping, extra scrolling, and a less elegant layout are all acceptable outcomes; missing words and unreachable controls are not.

Pass and fail examples

Passes:

A responsive web page at 200 percent browser zoom: headings wrap onto more lines and the page gets longer, but every sentence and control is still there. Ugly is fine.
A card component whose height grows with its content, so enlarged text expands the card instead of overflowing it.
An iOS app using text styles throughout: at the larger accessibility sizes every label grows past double its default size and multi-line labels wrap instead of truncating.
An Android app with all text in sp that reads correctly at font scale 2.0, with previously single-line labels now wrapping to two.
A web app where full-page zoom to 200 percent works flawlessly even though Firefox text-only zoom breaks one sidebar: one supported path to 200 percent without loss is sufficient.

Fails:

A viewport meta tag with user-scalable=no or maximum-scale=1 on a mobile site: pinch zoom is blocked, so the user's scaling mechanism is disabled.
A px-fixed banner with overflow: hidden that cuts the second half of its message at 200 percent zoom: loss of content.
Two absolutely positioned web columns whose text overlaps at 200 percent so neither is readable.
An iOS settings screen using fixed 14 pt fonts: the user raises the text size and nothing changes, so text can never reach 200 percent.
An Android summary row sized in dp, or a Compose text opted out via a nonScaledSp helper: the platform mechanism is ignored.
A submit button pushed below a fixed-height dialog's visible area at 200 percent: loss of functionality.

Not a fail under this criterion:

A horizontal scrollbar appearing at high zoom: two-dimensional scrolling is graded under SC 1.4.10 Reflow, not here, and added scrolling is not "loss of content".
A logo or hero graphic containing words that stays sharp but small: images of text are exempt here and are graded under SC 1.4.5 Images of Text.
Video captions that do not enlarge with page zoom: captions are explicitly exempt.
A layout that breaks when the user overrides line height and letter spacing: that is SC 1.4.12 Text Spacing, a different mechanism entirely.

Commonly confused with

SC 1.4.10 Reflow. The neighbouring zoom criterion, and the most common misfiling. 1.4.4 asks whether text can reach 200 percent without losing content or functionality; 1.4.10 asks whether content at high zoom reflows into one column instead of demanding two-dimensional scrolling. Clipped or vanished text files here; horizontal scrolling files under Reflow. One zoomed screenshot can legitimately produce findings under both.
SC 1.4.12 Text Spacing. Also about text adapting, but the mechanism is a user override of spacing properties (line height, letter spacing, word spacing, paragraph spacing), not size. A page that survives 200 percent zoom can still break under spacing overrides, and vice versa.
SC 1.4.5 Images of Text. Images of text are exempt from 1.4.4, so a bitmap heading that will not enlarge cleanly is not a Resize Text fail. Whether text should have been an image at all is graded under 1.4.5. File the finding there and leave 1.4.4 out of it.
SC 1.4.8 Visual Presentation. The Level AAA criterion adds presentation requirements (line width, justification, resize to 200 percent without horizontal scrolling in full-window text blocks). Citing its stricter expectations against a Level AA audit is applying the wrong level.

How AUDITSU tests this

AUDITSU's audit walkthrough covers Resize Text as a per-screen check. On web audits the walkthrough directs you to set the browser to 200 percent zoom (and to verify the viewport meta tag has not disabled scaling on mobile), then asks, screen by screen, whether any text is clipped, overlapped, truncated, or missing and whether every control still works. On native app audits the walkthrough has you raise the platform text setting (larger accessibility sizes on iOS, maximum font scale on Android) before the sweep, and flags text that fails to respond at all as its own finding. Each question records a pass, fail, or not applicable result per screen with evidence attached, so a clipped label is tied to the exact screen where it happened.

Because the criterion is graded per screen at a fixed setting, the walkthrough keeps 1.4.4 findings separate from reflow and spacing findings taken on the same screens, which keeps the report clean and the fixes correctly targeted.

For the full guided workflow, see the audit platform.