skip to content

A design system's new data table for a B2B analytics dashboard passed review, then teams found truncated translated headers, invisible sort icons in high-contrast theme and tablet overflow. How do you fix the release bar?

level: seniorimportance: should knowfreq 30%

answer

  1. what did 'passed' actually test
  2. one view versus a matrix
  3. evidence per supported combination
  4. a pilot consumer before general release
  5. patch now, change the bar after

basics

~20 s

Patch the defects, then fix why the bar missed them: it verified only the default context. Make readiness a matrix of supported themes, locales, densities and widths with evidence per cell, automate repeatable checks, and pilot releases with one consuming team.

solid answer

~40 s

First I would ship a patch and tell consumers what changed. Then I would ask why three checklist items - localisation, theme support and responsive readiness - were ticked without catching anything: almost always they were verified in one context, the default theme, source language and a desktop width. I would turn those items into a **context matrix** of what the system promises (themes including high-contrast, long and right-to-left locales, densities, narrow to wide containers) and require **evidence per combination**: rendered examples, a contrast check of the sort icon against 3:1 non-text contrast, and a narrow-width review. Repeatable checks get automated; judgement checks stay with the design and engineering sign-offs. Finally, a **pilot consuming team** tries each complex component before general release, because real data finds what fixtures miss.

go deeper

for a junior

Recall that a checklist item ticked in one context proves little; themes, locales and widths each need to be checked on purpose.

for a middle

Explain which checklist items these defects escaped, why the sort icon falls under 3:1 non-text contrast, and how Reflow treats data tables.

for a senior

Lead the fix end to end: patch and communicate, run a blameless review, turn items into an evidenced context matrix, automate what repeats and add a pilot consumer.

for a principal

Decide how far to backfill the new bar across existing components and how to fund the automation, balancing release throughput against consumer trust.

## Diagnose before adding rules The scenario: a design system releases a **data table** component, requested by the team building a B2B analytics dashboard. It passes code review, tests and sign-off. Within a week other consuming teams report three problems: 1. **Translated column headers truncate**, hiding what the column means. 2. **Sort-direction icons disappear** in the high-contrast theme. 3. On **tablets** the table pushes the whole page sideways and the toolbar above it becomes unreachable. Each defect maps to a checklist item that was nominally satisfied: localisation readiness, theme support, responsive readiness. The first question is not 'what item is missing?' but **'what did passed actually mean?'** In almost every case like this the item was checked in one context - the author's theme, source language and desktop width - and ticked. The sort icon is not decorative: it shows the state of a control. Under WCAG 2.2 **1.4.11 Non-text Contrast** (AA), visual information that identifies a component's state needs at least **3:1** against adjacent colors, in every theme the system supports. The tablet problem needs care, too. WCAG **1.4.10 Reflow** (AA) exempts content that needs two-dimensional layout, and its guidance names **data tables** as an example: a wide table may scroll horizontally inside its own container. What is not acceptable is the table dragging the page and its controls off-screen with it. ## Immediate response 1. Ship a **patch release** fixing the three defects, with a clear note of symptoms and fix. 2. Tell consuming teams which workarounds they can now delete. 3. Hold a blameless review: which item should have caught each defect, and why did it not? ## From a checklist to a context matrix Replace 'supports theming' and similar single ticks with the concrete contexts the system promises: | Dimension | Values to cover | Evidence | |---|---|---| | Theme and mode | light, dark, high-contrast, each supported brand | rendered example per theme; contrast of every state-bearing token pair | | Locale | source language, a long-string locale or pseudo-localised text, a right-to-left locale | rendered examples; no truncation of meaning-bearing text | | Container width | narrow panel, tablet, wide desktop | rendered examples; table scrolls in its own container; controls stay reachable | | Density | compact and default | rendered examples; targets still meet size rules | | Input | keyboard, screen reader, touch | notes from the manual passes | The matrix is bounded by what the system has **declared** it supports. Dimensions that rarely interact can be sampled in pairs rather than as every combination, which keeps the matrix finite. ## Automate the repeatable, keep people for judgement - **Automate** rendering every example in every theme and locale, contrast checks on token pairs, and checks that the component uses semantic tokens rather than hard-coded values. - **Visual snapshots** detect change, but a snapshot proves 'unchanged since the baseline', not 'correct'. If the high-contrast baseline was approved with invisible icons, the suite will keep passing. Baselines for new contexts need human review once. - **Keep for people**: whether a truncated header still makes sense, whether the keyboard model fits, whether design intent survives in right-to-left layout. These go to the design and engineering sign-offs, which now sign against the matrix, not a summary. ## Pilot consumers and sign-offs Complex components - tables, date pickers, comboboxes - benefit from a **pilot consuming team** that integrates a release candidate with real data before general release. Fixtures are short and tidy; production data has long names, missing values and extreme numbers. The pilot's feedback becomes evidence in the checklist. Choose a pilot whose product stresses the component differently from the requesting team - here, a team with long translated labels or a narrow side-panel layout - so the trial covers the contexts the author was least likely to try, and agree in advance what the pilot must confirm before general release. ## What not to do - **Blame the consumers** for not testing first; the system promised the contexts. - **Pile on manual items** without evidence requirements; a longer list of ticks fails the same way. - **Freeze all releases** until every component passes the new matrix; apply it to new and changed components and backfill the most used ones first. - **Treat the table as exempt from responsive rules** because it may scroll; the exemption covers the table's two-dimensional content, not the page around it.

  • Would a visual snapshot test in the high-contrast theme have caught the invisible sort icons?
    Only if someone had reviewed and approved a correct baseline in that theme. A snapshot suite compares against its baseline, so it proves the output is unchanged, not that it is right. A deterministic contrast check of the icon's color against its background, at the 3:1 non-text threshold, catches it regardless of baselines.
  • How do you stop the context matrix from growing until nobody can release a component?
    Bound it to contexts the system has declared supported, sample rarely-interacting dimensions in pairs instead of every combination, and automate rendering and contrast checks so the manual part stays small. Scale depth by component complexity, and review yearly which cells ever caught a defect.
  • What does a pilot consuming team find that the system's own examples miss?
    Real data and real layouts: very long labels, empty and null values, huge numbers, unusual locales, and the component placed inside dense product screens next to sticky headers and side panels. System examples are tidy by design, so the pilot surfaces the edge cases before every consumer meets them.

saying these in an interview costs you the question

  • The failures are the consuming teams' fault for not testing the table first.
  • Adding more manual checklist items is enough to prevent a repeat.
  • Because data tables may scroll in two directions, any tablet overflow is acceptable.
  • Sort icons are decorative, so contrast rules do not apply to them.
  • Passing visual snapshot tests proves every theme renders correctly.