In a design system's compact density mode, what goes wrong when a user raises the platform text size, and how should components cope?

## The failure A compact density mode is usually described in terms of **heights**: a compact row is shorter, a compact field is shorter. If those heights are fixed values, the mode only works at the text size the designer tested. When a user raises the platform's text-size setting, as many people with low vision and many older users do, the text grows and the container does not. The result is clipped labels, cut-off descenders, two-line content overlapping the next row, or truncated values where every value matters, such as the remaining data balance in a telecom self-service app. On the web, WCAG 2.2 criterion **1.4.4 Resize Text**, level **AA**, asks that text can be resized without assistive technology up to **200 percent** without loss of content or functionality. A compact mode that clips at 150 percent fails it. Native apps have the same user setting and show the same failure, and teams that audit native apps against WCAG apply the same intent. ## Build with minimums, not fixed sizes The fix is to express density as **padding and minimum sizes** and let content decide the final size: - A control's height is its **minimum height** or its padding plus its content, whichever is larger. Compact lowers padding and the minimum; it never pins the height. - Rows and cells **grow** when text wraps or enlarges. - Text sizes stay in the platform's **user-scalable** unit, so the user's setting always wins; spacing stays in the unit the system uses for layout. - Truncation is a deliberate, documented choice for specific content, never the side effect of a fixed height. ## Web and native express it differently | Concern | Web | Native mobile | |---|---|---| | User text preference | browser text-size setting and page zoom | operating-system text-size setting | | How text follows it | sizes relative to the user's root text size | a scale-independent text unit or text styles that scale | | Layout spacing | CSS pixels or root-relative sizes | density-independent units | | Typical failure | fixed-height rows clip at 200 percent | fixed-height cells clip at the largest text sizes | On the web that means text sized in a root-relative unit such as `rem`; on one native platform, a scale-independent unit such as `sp`. They are two spellings of the same idea: text follows the user, spacing follows the density mode. ## What else changes at large text sizes 1. **Layouts reflow.** A dense four-column row may need to wrap values or stack into a card when text is very large. On the web, criterion **1.4.10 Reflow**, level AA, already asks content to work at a width equivalent to 320 CSS pixels without scrolling in two dimensions, with exceptions for content that needs a two-dimensional layout, such as data tables. 2. **Density may relax automatically.** Some systems switch a surface from compact to comfortable when the user's text size passes a threshold, because tight spacing around very large text reads worse. This is a product choice, not a requirement. 3. **Targets grow with content.** Because height is content-driven, larger text enlarges controls, which helps the users who asked for larger text. 4. **Text spacing overrides.** Criterion **1.4.12 Text Spacing**, level AA, expects no loss of content when a user sets line height to at least 1.5 times the font size, paragraph spacing to 2 times, letter spacing to 0.12 times and word spacing to 0.16 times. Fixed-height compact rows tend to fail this as well. ## How to test it - Test each density mode at the largest text size you support, not only at the default. - Include the combination of compact plus large text in visual regression checks; that pairing is where defects hide. - Check that no density value caps, overrides or scales a text size. ## The rule to remember Density decides how much **space** surrounds content; the user decides how large the **text** is. When the two collide, text wins and space gives way.