In a design system with compact and comfortable density modes, what may a density switch change, and what must stay fixed?

## What a density mode is A **density mode** is a named set of sizing values (padding, gaps, row heights, control heights) that a design system swaps as a unit. **Comfortable** (sometimes called default or regular) spends space on breathing room and large targets; **compact**, sometimes with an intermediate step in between, packs more rows, fields and actions into the same area. The mode is a theme dimension, like a color mode: components ask for the control height or the row padding, and the active mode answers. That is what lets a whole screen change density consistently instead of each component being tuned by hand. The interview question is really about **boundaries**: which values a mode is allowed to touch, and which are floors every mode must respect. ## What a density mode may change | Property | Comfortable | Compact | Note | |---|---|---|---| | Inner padding of controls | larger | smaller | the main lever | | Gaps between items and sections | larger | smaller | keep the rhythm proportional | | List and table row height | taller | shorter | the biggest visible gain in data views | | Control height (buttons, fields, selects) | taller | shorter | visible size only; see hit area below | | Icon size | sometimes larger | sometimes one step down | stay on the icon grid | | Secondary text (captions, table metadata) | base step | occasionally one step down | contested; see below | The ordering matters: most systems get nearly all of the gain from padding, gaps and row height, and touch text last or not at all. ## What must stay fixed - **Pointer target size.** WCAG 2.2 success criterion **2.5.8 Target Size (Minimum)**, level **AA**, asks that a target be at least **24 by 24 CSS pixels**, with five exceptions: spacing, equivalent, inline, user agent control and essential. The spacing exception lets an undersized target pass when a 24-pixel-diameter circle centred on it intersects no other target and no other undersized target's circle. WCAG defines a **target** as the region that accepts the pointer action, not the painted shape, so the usual technique is to let the *visible* control shrink while its *hit area* stays at the floor. - **Legible text.** Body text stays at a readable size in every mode, and it still grows when the user raises the platform's text-size setting; a density mode never caps that. - **Focus indicators and contrast.** Tighter padding must not clip a focus ring or push text onto a lower-contrast surface. - **Content and function.** Compact shows the same information and actions; it changes spacing, not capability. - **Semantics and order.** Reading order, labels and accessible names are identical across modes. ## Why text is the contested one Shrinking text is the tempting shortcut because it frees the most space, and it is where density modes most often go wrong. Text size is a user-controlled accessibility setting on the major platforms, and a mode that hard-codes smaller body text fights it. Common practice is to leave body text alone, allow at most one step down for secondary text such as table metadata, and never go below the system's smallest documented text style. A surface that needs more density than that usually needs a different layout (fewer columns, a summary row) rather than smaller letters. ## Where the numbers come from 1. **2.5.8 Target Size (Minimum)**: level AA, 24 by 24 CSS pixels or sufficient spacing. This is the floor for AA conformance. 2. **2.5.5 Target Size (Enhanced)**: level AAA, 44 by 44 CSS pixels. Many systems adopt it, or native platforms' larger touch-target guidance, for touch-first comfortable modes and primary actions, but it is not an AA requirement. 3. The WCAG Understanding document for 2.5.8 names a **density control** as a beneficial option: users with visual field loss may prefer a condensed layout with smaller controls, while other low-vision users may prefer large controls. Density is an accessibility feature when its floors hold. The target-size requirement is also independent of zoom: when a user zooms in, an element's size in CSS pixels does not change, so the argument that users can zoom never rescues an undersized compact control. ## A telecom example In a telecom self-service app, most customers use comfortable mode on a phone to pay a bill or change a plan. A small-business account holder managing twelve lines switches to compact on desktop to see every line's usage without scrolling. Compact shrinks row padding and row height; each row's action button keeps a 24 by 24 hit area; the data-usage figures stay at body size. Both audiences get the density they need, and neither mode is a separate, less accessible product. ## Common mistakes - Scaling the whole interface by a percentage, which shrinks targets and text along with space. - Treating the visible icon size as the target size, in either direction. - Letting each product team pick its own compact values, so a compact table sits next to comfortable form fields. - Testing only the default mode, so compact ships with targets nobody measured.