Resize Text

In brief

Many people with low vision do not use a screen reader. They enlarge the text with the browser zoom, with the larger text setting of their phone or with a text size setting in the system. If the page breaks when they do, such as with cut-off text, overlapping boxes and missing buttons, they cannot use it.

This criterion requires that text can be resized, without assistive technology, up to 200 percent without loss of content or functionality. Captions and images of text are excepted.

What does it cover?

• Resizing: The user enlarges the text with the means the platform gives them, such as browser zoom or text-only zoom, or the larger text setting in the system.
• 200 percent: Everything still works at 200 percent. Nothing is cut off, hidden or overlapping, and every control can still be used.
• Web: Do not block zoom. Use relative units, flexible containers and do not fix the height of elements that hold text.
• Mobile: Support the system text size setting, such as Dynamic Type on iOS and font scale on Android.
• Exceptions: Captions and images of text.
• Out of scope: Reflow of content at 400 percent and 320 px width is covered by 1.4.10. Text spacing is covered by 1.4.12.

Who does it affect?

People with low vision who enlarge text without a screen reader. Older users. People who read small screens in poor conditions. People with dyslexia, who may prefer larger text. Anyone who zooms to read a small font.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Text that can be enlarged is part of "perceivable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 1.4.4 by reference and turns it into separate clauses for each kind of ICT.

Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 1.4.4 is the same in WCAG 2.1 and 2.2. It is a Level AA criterion.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. Do not block zoom

A viewport that disables zoom stops people with low vision from enlarging text on a phone.

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

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

2. Relative units

Pixel sizes for text do not follow a user's default font size. Relative units do.

body { font-size: 14px; }
h1   { font-size: 24px; }

body { font-size: 1rem; }
h1   { font-size: 1.75rem; }

3. Do not fix the height of text containers

A fixed height cuts off enlarged text. Use a minimum height and let the content grow.

.card { height: 120px; overflow: hidden; }

.card { min-height: 120px; }

4. Unitless line height

A fixed line height in pixels does not grow with the text.

p { font-size: 1rem; line-height: 20px; }

p { font-size: 1rem; line-height: 1.5; }

5. Media queries in em

Breakpoints in pixels do not move when the text is enlarged. Em-based breakpoints do.

@media (min-width: 768px) { .nav { display: flex; } }

@media (min-width: 48em) { .nav { display: flex; } }

6. Wrap, do not truncate

Let long text wrap instead of cutting it off.

.label { white-space: nowrap; overflow: hidden;
          text-overflow: ellipsis; width: 100px; }

.label { overflow-wrap: anywhere; max-width: 100%; }

Code examples for mobile

The same rule applies in native mobile apps. Use the platform's text styles and units, so that the text follows the system text size setting, and let the layout grow.

iOS (SwiftUI)

import SwiftUI

struct ArticleCard: View {
    // Spacing that grows with the text size
    @ScaledMetric private var spacing: CGFloat = 8

    var body: some View {
        VStack(alignment: .leading, spacing: spacing) {
            // Avoid: a fixed size does not follow Dynamic Type
            // Text("Title").font(.system(size: 14))

            // Use text styles, which follow Dynamic Type
            Text("Title").font(.headline)
            Text("A longer description that wraps onto several lines.")
                .font(.body)
                .fixedSize(horizontal: false, vertical: true)
        }
        .padding()
    }
}

Android (Jetpack Compose)

import androidx.compose.foundation.layout.Column
import androidx.compose.foundation.layout.heightIn
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier
import androidx.compose.ui.unit.dp

@Composable
fun ArticleCard() {
    // Use a minimum height, not a fixed one
    Column(modifier = Modifier.heightIn(min = 120.dp)) {
        // Text styles use sp, which follows the system font scale.
        // Avoid: a fixed height, or a text size that ignores the font scale
        Text("Title", style = MaterialTheme.typography.titleMedium)
        Text(
            "A longer description that wraps onto several lines.",
            style = MaterialTheme.typography.bodyMedium
        )
    }
}

How to test

• Zoom the browser to 200 percent: Use Ctrl and plus, or Command and plus. Is all content still there, and does every control still work? Is anything cut off or overlapping?
• Try text-only zoom: Set a larger minimum font size in the browser. Does the layout hold?
• Check the viewport: Is zoom blocked by user-scalable=no or maximum-scale?
• Check the code: Are text sizes in relative units? Are there fixed heights on text containers?
• Check mobile: Set the system text size to the largest setting. Does the app follow it, and does the layout adapt without cut-off text?
• Test the whole flow: Complete a task at 200 percent, such as a sign-in or a payment.
• Use a checker as a start: Automated tools can find a blocked viewport, but only a person can see whether content gets cut off.

Common mistakes

• Blocking zoom with the viewport: The most common failure on mobile.
• Text sizes in pixels everywhere: They ignore the user's default size.
• Fixed heights: Enlarged text is clipped or overflows.
• Hiding overflow: Content disappears when the text grows.
• Truncating text with ellipsis: Important text can be lost.
• Ignoring Dynamic Type and font scale: The app does not follow the system setting.
• Breakpoints in pixels only: The layout does not respond to larger text.
• Testing only the home page: Forms and dialogs break first.

Sources

• Understanding SC 1.4.4: Resize Text (W3C), opens in a new tab
• F69: Failure due to resizing text causing loss of content (W3C), opens in a new tab
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), opens in a new tab
• EN 301 549 V4.1.1 (ETSI), opens in a new tab
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), opens in a new tab

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.