skip to content

In a design system for web and native apps, why must text follow the user's text-size setting, and how must layouts adapt?

level: juniorimportance: must knowfreq 50%

answer

  1. set once, expected everywhere
  2. styles relative to the reader's base
  3. text grows, boxes may not
  4. rows stack at large sizes
  5. test the largest setting too

basics

~20 s

Many readers raise the system or browser text size because they need it, and fixed sizes ignore them. A system defines text styles relative to that setting, and layouts let text wrap, containers grow and horizontal rows stack at large sizes.

solid answer

~50 s

Low-vision and older readers often raise text size once, in the operating system or the browser, and expect every product to respect it. If a design system hard-codes text sizes, those readers get small text or must zoom every page. So the system defines each text style relative to the reader's base size, which makes the whole type scale grow together. Growth then stresses layouts, because a text-size setting enlarges text but not necessarily the boxes around it: components need containers that grow, labels that wrap instead of truncating, and horizontal groups, such as a row of preset donation amounts, that stack at large sizes. On some platforms the largest settings go well past double the default, so the system documents and tests layouts at the extremes, not just at the default. Capping growth is a narrow trade-off for already-large display text, not a tool for body text.

go deeper

for a junior

Recall that readers set text size once in the system or browser, that text styles must be relative to that setting, and that layouts must wrap and grow instead of clipping.

for a middle

Explain why a text-size setting and page zoom expose different defects, and how components encode large-text rules such as stacking a row or moving secondary text below.

for a senior

Show how you would audit a component set at 200 percent and the largest platform setting, fix fixed-height and single-line assumptions, and document each component's large-text layout.

for a principal

Weigh a cap on display-text growth against reader needs and parity between web and native, and decide what the system allows teams to opt out of, if anything.

## Who changes the text size, and where Readers enlarge text in several places, and each stresses a layout differently: | Mechanism | What grows | What it tends to expose | |---|---|---| | Page zoom in a browser | Everything; the layout behaves as if the window were narrower | Layouts that cannot reflow to a narrow width | | The browser's default text-size setting | Text sized relative to that default | Text sized in fixed values, containers of fixed size | | The operating system's text-size setting in a native app | Text in styles that opt in to scaling | Fixed-height rows, clipped labels, rows that cannot wrap | The people who use these settings are not a niche. They include readers with low vision, many older readers, and people reading on a small phone at arm's length. They set the size once and expect every product to honour it; a product that ignores it forces them to zoom every screen or give up. ## What the design system encodes 1. **Text styles are defined relative to the reader's base size**, not as fixed values, so raising the setting grows the whole type scale in proportion. How that is spelled on each platform is the platform's business; the system's decision is that no text style opts out. 2. **Line heights scale with the text** they belong to, so enlarged lines do not collide. 3. **Containers are sized by their content**: a button, a card or a list row gets padding around its text rather than a fixed height, so it grows when the text does. 4. **Components carry large-text layout rules**: which horizontal arrangements wrap or stack, which secondary text moves below the primary text, and where an icon sits when its label wraps. 5. **The system decides what else follows the text**, such as the icons that sit inline with labels. Whether spacing follows too is a unit decision made at the system level, but text always grows. ## Designing for the extremes The default size is the easy case. The hard cases are 150 percent, 200 percent and, on platforms whose largest accessibility settings go well past double, the very top of the range. On a charity donation page: - A **row of preset amount buttons** that fits four across at the default size must wrap into two rows, or stack into a column, at large sizes, not squeeze its labels or overflow the screen. - A **label-and-value summary** (amount, frequency, the cause it goes to) switches from side-by-side to stacked, so neither the label nor the value is cut off. - **Campaign titles** wrap onto more lines instead of truncating, so a reader who needed large text still gets the whole title. - The **primary action label** wraps inside a button that grows, rather than shrinking or hiding. ## Capping growth: when it is defensible Some systems stop very large display text from growing as fast as body text, because a headline that is already four times body size would otherwise fill the screen on its own. That is a defensible, documented trade-off for display styles only, and on the web the page must still reach 200 percent enlargement some other way, such as zoom, to meet WCAG 2.2 SC 1.4.4 Resize Text. What is not defensible: - Turning off scaling for body text, labels or error messages to protect a pixel-exact design. - Capping all text at a small multiple of the default so a layout never has to adapt. - Hiding or abbreviating content at large sizes, which removes it from exactly the readers who needed the larger text. ## Testing it - Check every component at the default size, at 200 percent and at the largest platform setting, with the longest real strings, such as the longest campaign title and a supporter's long name. - On the web, test the text-size setting and page zoom separately, because they expose different defects. - Record the large-text layout of each component in its documentation, so product teams do not invent their own. - Include at least one real reader who uses a large setting in usability sessions where possible; the defects they hit first are rarely the ones a checklist predicts. The principle underneath all of this is that the reader's setting is an input to the layout, not a threat to it. A system that treats large text as a supported state, with its own documented layouts, ships products that keep working for the readers most likely to give up on them.

  • Why test the browser's text-size setting and page zoom separately?
    They fail differently. Zoom enlarges everything and narrows the effective layout, so it exposes layouts that cannot reflow. The text-size setting enlarges text inside boxes that may stay the same size, so it exposes fixed-height containers and clipped labels. A layout can pass one and fail the other.
  • A designer asks to cap text scaling in the donation panel so the layout stays tidy. How do you respond?
    Decline for labels, amounts and body text: those readers chose the size because they need it. Offer the layout alternative instead, such as stacking the amount buttons and the summary rows at large sizes. A cap is only defensible on very large display styles, documented as a trade-off, and on the web page zoom must still reach 200 percent.

saying these in an interview costs you the question

  • Users who need bigger text can simply zoom, so the text setting can be ignored.
  • Disabling text scaling protects the design and is an acceptable trade-off for body text.
  • If the text grows, the containers around it will always grow with it.
  • Abbreviating labels at large text sizes is a good way to keep rows on one line.
  • Testing at the default size and at 125 percent covers the realistic range.