skip to content

In a design system, which dimensions should scale with the user's text-size setting and which should stay fixed, and why?

level: middleimportance: should knowfreq 45%

answer

  1. the element's job decides
  2. anything holding text must grow
  3. structure and decoration stay put
  4. minimum heights, never fixed boxes
  5. zoom and text size differ

basics

~20 s

Text and whatever holds it should scale: type sizes, line heights, the minimum heights of text-bearing components and icons inline with labels. Structural and decorative values such as borders, dividers, corner radii and focus-ring thickness usually stay fixed.

solid answer

~40 s

The element's job decides. **Text-relative:** font sizes, line heights, paragraph spacing, the **minimum** height of anything holding text (list rows, chips, buttons, fields), and icons that read as part of a label. **Fixed** in logical units: border and divider widths, corner radii, focus-ring thickness, and the touch-target floor, which may grow but never shrink. Inner spacing is a genuine trade-off either way. The classic failure is a fixed box around scalable text: the words grow, the box does not, and content clips. WCAG 2.2 **1.4.4 Resize Text** (Level AA) asks for text resizable to 200 percent without loss of content or functionality, so text containers must grow by default. And zoom is a different request: it enlarges every logical unit, while a text-size setting enlarges only the text-relative ones.

go deeper

for a junior

Recall the rule: text and anything holding text grows, while borders, dividers, radii and focus rings stay fixed.

for a middle

Explain why a fixed box around scalable text clips, and how zoom differs from a text-size setting.

for a senior

Show how you would audit a component set for fixed heights and missing reveal mechanisms, and settle the inner-spacing trade-off deliberately.

for a principal

Weigh how the system should mark each value as fixed or text-relative so consuming teams cannot pick the wrong family by accident.

## The rule: the element's job decides A user who raises the system or browser text-size setting is asking for **bigger text**, not a bigger everything. A design system therefore sorts every dimension by what it does: - **Text, and whatever holds text**, grows with the setting. - **Structure and decoration** keep their size in fixed logical units. The most damaging defect in this area is a **fixed-size box holding scalable text**: the words grow, the box does not, and the content is clipped, overlaps a neighbour, or is truncated with no way to read it. ## Which family each dimension belongs to | Dimension | Usually | Why | |---|---|---| | Font size of every text style | text-relative | it is what the user asked to enlarge | | Line height and paragraph spacing | text-relative | fixed leading makes enlarged lines collide | | Minimum height of rows, chips, buttons, fields | text-relative, as a floor | the container must grow with its label | | Icons sitting inline with a label | often text-relative | keeps icon and word visually matched | | Padding inside text-bearing components | either | a genuine trade-off, see below | | Border and divider widths | fixed | a thicker line adds nothing to legibility | | Corner radii | fixed | shape, not content | | Focus-ring thickness | fixed | it must stay visible, not proportional | | Touch-target minimum | fixed floor | a target may grow, never shrink below the floor | | Page margins and grid gutters | fixed or width-driven | set by available space, not by text | Two cells carry a judgement: - **Padding** that scales keeps proportions but consumes space quickly at the largest sizes; fixed padding stays compact but can look cramped around large labels. Both are defensible as long as the component's height is a minimum that grows. - **Stand-alone icons** in a toolbar, with no label, are often kept fixed, but the control around them must never drop below the system's target-size floor. ## Zoom and text size are different requests Users enlarge content in two ways, and a system has to survive both: 1. **Zoom**, whether page zoom or a display-size setting, enlarges every logical unit. Proportions survive; the risk is that the layout runs out of width and must **reflow**. 2. **A text-size setting** enlarges only text-relative values. Proportions change; the risk is fixed containers that cannot hold their text. Passing one test says little about the other, so both belong in the component test matrix. ## What WCAG asks WCAG 2.2 Success Criterion **1.4.4 Resize Text** (Level AA) requires that, except for captions and images of text, text can be resized without assistive technology up to **200 percent** without loss of content or functionality. Two neighbours matter here: - **1.4.10 Reflow** (Level AA) covers zoomed content fitting a narrow viewport without scrolling in two directions. - **1.4.12 Text Spacing** (Level AA) requires that content survive user overrides of line height and of letter, word and paragraph spacing. WCAG is written for web content, but native teams commonly adopt it as their benchmark too. ## Encoding the split in the system 1. Give each size value an explicit **family**, fixed or text-relative, so its behaviour is obvious to the engineer consuming it. 2. Write component specs with **minimum** heights, never fixed ones, for anything holding text. 3. Specify what happens at large sizes: wrap to a second line, stack side-by-side parts, or truncate with a way to reveal the full text. 4. Render every text-bearing component at the default size, at double size and at the platform's largest size in visual tests. Each platform spells the text-relative family differently: the web usually uses the root-relative `rem`, one native mobile platform uses a scale-independent pixel (`sp`) alongside its layout unit, and another scales named text styles that follow the system setting. The design decision underneath is the same everywhere. ## An example In a veterinary clinic booking app, the list row showing a pet's name and next appointment grows taller at large sizes because its height is a floor, not a value. Its divider stays a hairline, its pet avatar can stay a fixed size, its chevron grows a little because it reads with the text, and the whole row never shrinks below the touch-target floor.

  • Why is zoom different from a text-size setting for this decision?
    Zoom enlarges every logical unit, including borders, spacing and images, so proportions survive and the layout mainly needs to reflow. A text-size setting enlarges only text-relative values, so fixed-size boxes that contain text are where breakage appears. A system has to be tested under both, because passing one says little about the other.
  • Should the inner spacing of a button grow with the text size?
    Either answer is defensible. Scaling the inner spacing keeps proportions but spends space fast at the largest sizes; fixed inner spacing keeps layouts compact but can look cramped. What is not negotiable is that the button's height is a minimum that grows with its label, never a fixed value that clips it.
  • How would you verify the split across a component library?
    Render every text-bearing component at the default setting, at double size and at the platform's largest size, and compare. Look for clipped or overlapping text, truncation with no way to reveal it, and icons drifting out of alignment with their labels. Automating those renders in visual tests catches regressions before release.

saying these in an interview costs you the question

  • Zoom and the text-size setting are the same thing, so one test covers both.
  • A fixed-height container is fine as long as the text inside it scales.
  • Text sized in a fixed logical unit still follows the user's text setting.
  • Resizing text only matters to people who use screen readers.
  • Icon-only controls may shrink below the target minimum to make room for text.