skip to content

In a veterinary clinic booking app's design system, users on the largest text size see time-slot chips clipped and pet names cut off; how do you diagnose and fix it?

level: seniorimportance: should knowfreq 38%

answer

  1. reproduce at the extremes first
  2. one component or one screen?
  3. fixed heights around growing text
  4. wrap first, reveal if truncated
  5. fewer chips per row when large

basics

~20 s

Reproduce at the largest setting and at double size, then trace breaks to components whose heights or widths are fixed while text grows. Switch specs to minimum heights, let labels wrap or reveal truncated text, reflow crowded rows, and test large text.

solid answer

~50 s

First reproduce at the platform's largest text size and at 200 percent, and check whether each break repeats across screens; if it does, the defect is in the component spec. Here the time-slot chip has a fixed height and width in logical units, so its label grows while the box does not, and the pet-name row is forced to one line with a silent ellipsis. Fix it once in the system: **minimum** heights from line height plus inner spacing, labels allowed to wrap, truncation only with a way to reveal the full text, and the slot grid dropping from four chips per row to two, or a list, at large sizes. Do not cap the setting or shrink text to fit. WCAG 2.2 **1.4.4 Resize Text** (AA) is the usual benchmark. Then add large-text renders to visual tests.

go deeper

for a junior

Recall that text containers need minimum heights rather than fixed ones, and that truncated text must be reachable somewhere.

for a middle

Explain why fixed logical sizes around scalable text clip, and what 1.4.4 Resize Text asks for at Level AA.

for a senior

Demonstrate the whole loop: reproduce at the extremes, trace symptoms to component specs, fix once in the system, and guard with large-text visual tests.

for a principal

Discuss making large-text behaviour a release criterion for every component, and how to fund alternative layouts for the densest screens.

## Reproduce and classify before fixing A report of clipped slots and cut-off names is a symptom. The fix belongs in the design system only once you know which components cause it. 1. Set the platform's largest text size, then repeat at double the default, the level WCAG uses as its benchmark. 2. Walk the booking flow: choose a clinic, choose a pet, choose a time slot, confirm. 3. For each break, record the component, the text style and the dimension that failed to grow. 4. Check whether the same component breaks on other screens. If it does, the defect is in the component's spec, not the screen, and fixing it there fixes every team's screens at once. ## Tracing symptoms to causes | Symptom | Likely cause in the system | Fix in the system | |---|---|---| | Time label clipped inside its chip | chip specified with a fixed height in logical units | minimum height derived from line height plus padding | | Evening slot label spills past the chip | chip specified with a fixed width, four per row | width from content, fewer chips per row at large sizes | | Pet name cut to its first few letters | row forced to one line with a silent ellipsis | allow two lines, or reveal the full name elsewhere | | Icon drifts away from its bigger label | icon fixed while its label grows | inline icons follow the text family, or align to the first line | | Row text overlaps the next row | fixed row height in a list template | rows size to content with a minimum height | ## Fixing the components - **Minimum, not fixed, heights.** Every text-bearing component's height becomes a floor: line height plus padding at the default setting, growing with its label. - **Wrap before truncating.** A pet's name may wrap to two lines in a list row; a time label may wrap if its chip is allowed to grow. - **Truncation needs a reveal.** Where a single line is unavoidable, the full text must stay reachable: on the pet's detail screen, on focus or activation, or in the accessible name. The WCAG Understanding document for 1.4.12 Text Spacing accepts ellipses on exactly that condition, and says truncated text with no mechanism to reveal it fails. - **Do not shrink text to fit.** Auto-shrinking labels back to the chip's size silently undoes the user's setting. - **Do not cap the setting.** Locking the app to a maximum text scale hides the defect and removes an accommodation that low-vision users depend on. ## Adapting the layout at large text sizes Dense arrangements cannot simply grow in place. The slot grid of four chips per row becomes two per row, and at the largest sizes a vertical list of slots. Items shown side by side, such as a pet avatar beside a name and breed, stack vertically. The switch is keyed to whether the content still fits, measured with the longest realistic label, not to a list of devices. Write it into the component's spec so every team inherits the behaviour instead of re-solving it screen by screen. ## The benchmark WCAG 2.2 **1.4.4 Resize Text** (Level AA) requires that text, except captions and images of text, can be resized up to **200 percent** without loss of content or functionality. Clipped time labels and unreachable pet names are exactly that loss. WCAG is written for web content; native teams commonly adopt the same benchmark, and some native platforms let users go well beyond 200 percent, which is why the largest platform setting belongs in the test matrix as well. ## Preventing regression - Add renders of every text-bearing component at default, double and largest text size to the library's visual tests. - Make large-text behaviour a required part of every component's spec: what wraps, what stacks, what truncates and how it is revealed. - Include one large-text pass of the booking flow in the release checklist. - Track clipped-text reports as their own defect category, so components that keep breaking surface quickly. The outcome to aim for is that a product team building a new screen from these components gets correct large-text behaviour without thinking about it.

  • Why not cap the app's text scale so the slot grid stops breaking?
    A cap discards the accommodation low-vision users rely on, and where WCAG applies it fails Resize Text. It also treats the symptom: the real defect is fixed-size components around scalable text. The default must be that text grows and layouts adapt; any surface with a genuine physical constraint needs another way to show the full text.
  • Truncating a pet's name with an ellipsis is sometimes unavoidable; when is it acceptable?
    When the full text stays reachable: shown in full on the detail screen the row opens, revealed on focus or activation, or exposed through the accessible name. WCAG's Understanding document for Text Spacing accepts ellipses on that condition. Silent truncation, where the whole name can never be read, is the failure.
  • How do you decide when the slot grid should switch to fewer chips per row?
    Base it on whether content fits rather than on a device list: find the text size at which the longest realistic label, such as an evening slot in the most verbose locale format, stops fitting a chip, and switch there. Write the rule into the component spec so every team inherits it.

saying these in an interview costs you the question

  • Cap the app's text scale so the original layout keeps working.
  • Auto-shrinking labels to fit their chips is an acceptable fix.
  • An ellipsis is fine even if the full pet name is never reachable.
  • It is a screen bug; patch the booking screen and move on.
  • WCAG has no requirement about resizing text, so this is optional polish.