A smart-home app's users with a large text-size setting see labels grow while icons stay tiny, breaking the pairing. How should a design system scale icons with text?

## The symptom Most platforms let users choose a larger text size in their system settings. Apps that honour it enlarge their text, sometimes to well over twice the default. If the design system sizes icons in fixed units while text scales, the **pairing breaks**: in a smart-home control app, a room name grows to a large label while the lightbulb beside it stays at its small default size, the icon looks like a speck, and alignment between icon and first line of text is lost. The opposite failure is also common: everything scales without limit, and a bottom navigation bar overflows or truncates. ## Classify icons by what they pair with Not every icon should respond the same way. A design system's scaling rule is clearer when icons are grouped: | Icon role | Example | Scaling rule | |---|---|---| | Paired with text | Lightbulb beside a room name, icon inside a labelled button | Scale with the text, stepping through the size set | | Fixed-space chrome | Bottom navigation, a compact toolbar | Grow up to a limit, then change layout or labelling | | Standalone status | Signal or battery indicator in a device row | Scale with the row's text, since it is read alongside it | | Illustrative | Large picture on an empty state | Usually unchanged; it is not paired with text | ## Scale in steps, not continuously When an icon scales with text, the design system should map each text size to an **icon size from the set** rather than computing arbitrary values. Set sizes are the ones the drawings are tuned for, and where the system has optical size variants, stepping means the enlarged icon also gets the right drawing. A continuous multiplier produces sizes like 27.5 units that render soft and fall outside every review. Mechanically, each platform expresses this in its own terms: on the web by sizing icons in a text-relative unit, on native mobile by tying the icon to a scaled metric derived from the paired text style. The design-system rule is the same on both: *the icon follows its text style's size mapping*. ## Fixed bars need a limit A navigation bar has room for a fixed number of items. If each item's icon and label grow without bound, the bar either truncates labels or pushes items off screen. Common practice: - Let bar icons grow **modestly**, then cap them. - Provide the label another way at the largest sizes, for example a layout that shows it larger elsewhere, rather than letting it truncate. - Keep the bar's targets at least as large as before; capping the glyph never shrinks the target. ## Layout must adapt Scaling icons and text is only half of the work; layouts built for default sizes break under it: 1. **Targets grow** with their content, so hit areas stay comfortable around larger glyphs and labels. 2. **Side-by-side rows become stacked** when an icon, a label and a value no longer fit on one line, for example a thermostat tile that puts the reading below its label at large sizes. 3. **Labels wrap instead of truncating**, and icons stay aligned with the first line of wrapped text. ## Where the standards stand 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. It is about **text**; it does not require icons to scale. But a screen where enlarged text overlaps, clips or pushes icons out of view can lose content or functionality, which is exactly what the criterion forbids. Keeping paired icons in step with text is how design systems avoid that, and it preserves the visual pairing users rely on. ## Verifying it The rule is only as good as its testing. Review each template at the default size and at the platform's **largest** text setting, looking specifically for: - icons that stayed small beside large labels, - bars that truncate or overflow, - rows where icon and text lost alignment, - targets that stayed small around enlarged content.