skip to content

In a design system, why publish a table of approved text and background color pairs, and what should each entry record?

level: juniorimportance: should knowfreq 40%

answer

  1. checked once, reused everywhere
  2. roles, not raw values
  3. permitted use, not pass or fail
  4. 4.5:1, 3:1, decorative only
  5. missing pair means ask

basics

~20 s

An approved-pairs table lists foreground and background roles already checked for contrast, so teams choose instead of guessing. Each entry records both roles, the unrounded ratio, the permitted use (body text, large text, non-text, decorative) and the modes verified.

solid answer

~40 s

An approved-pairs table turns contrast from a per-screen check into a lookup: the system checks each foreground role on each surface role once, and every team picks from the list. Each entry should record the foreground role, the background role, the measured ratio (unrounded), the **permitted use** and the modes it was verified in. Permitted use is the column people forget: under WCAG 2.2, 4.5:1 allows any text, 3:1 to under 4.5:1 allows only large-scale text (at least 18 point, or 14 point bold) and non-text parts, and anything lower is for decoration only. A bare pass/fail column lets a pair approved for a big step count leak into the small caption under it. A pair that is not in the table is a question for the system team, not a default.

go deeper

for a junior

Know how to use the table: find your surface, pick a foreground approved for your use, and ask when a pair is missing.

for a middle

Explain why permitted use matters more than pass/fail, tying 4.5:1, 3:1 and decorative-only to body text, large text and non-text parts.

for a senior

Keep the table trustworthy: re-check rows when a surface changes, catch pairs used for the wrong purpose in review, and handle overlays the table cannot cover.

for a principal

Decide how strictly the table gates work, balancing a closed list that slows teams against an open one that lets unchecked pairs ship.

## What the table is An **approved-pairs table** lists the foreground and background combinations a design system has already checked, and says what each one may be used for. Instead of picking a text color by eye and hoping, a designer looks up the surface they are working on and chooses from the foregrounds listed against it. Engineers use the same table in review: a pair that is not in it is a question, not a default. The table is expressed in **roles** (primary text, secondary text, brand accent, card surface, raised surface) rather than raw color values, because roles are what screens actually use. How those roles are named is the token taxonomy's business; the table only needs them to be stable. ## Why publish it - **Checked once, reused everywhere.** A fitness-tracker companion app has dozens of screens: a daily summary card, workout history, sleep charts, settings. Each one reuses the same few surfaces, so checking pairs on those surfaces once covers them all. - **Fewer late surprises.** Contrast problems found in a final accessibility review are expensive to fix; a table moves the decision to the moment a color is chosen. - **A shared vocabulary.** A reviewer can say the caption uses secondary text on the raised surface, which the table allows for large text only, instead of arguing about whether a gray looks light enough. - **Safe evolution.** When a surface value changes, the system re-checks the rows for that surface and republishes, and every team inherits the result. - **Faster onboarding.** A new designer or engineer learns which colors go together from the table far faster than from a page of swatches, because the table shows the combinations that are actually allowed rather than the raw ingredients. ## What each entry should record | Field | Why it is there | |---|---| | **Foreground role** | The text, icon or border being placed | | **Background role** | The surface it sits on | | **Measured ratio** | The computed contrast ratio, unrounded | | **Permitted use** | Body text, large text only, non-text parts only, or decorative only | | **Verified modes** | Which light, dark or high-contrast sets the ratio was checked in | The **permitted use** column is the one most often missing, and it matters most. WCAG 2.2 sets different minimums for different content: 1. **At least 4.5:1** allows any text (1.4.3 Contrast (Minimum), Level AA). 2. **At least 3:1 but under 4.5:1** allows large-scale text, meaning at least 18 point or 14 point bold, and non-text parts such as input borders, icons and state indicators (1.4.11 Non-text Contrast, Level AA). 3. **Under 3:1** is only for content with no contrast requirement: decoration, or a divider nobody needs to see to use the screen. A pass/fail column hides that distinction. A pair measuring 3.6:1 passes for a large step-count number and fails for the small caption beneath it, and the table has to say which. Ratios are recorded unrounded because WCAG's guidance treats the thresholds as hard minimums: 4.499:1 does not meet 4.5:1. ## Using it day to day For the summary card in the fitness app, a designer working on the card surface would: 1. Find the card surface in the table. 2. Choose primary text for the step count and secondary text for the caption, checking that secondary text is approved for small text on that surface, not only for large text. 3. Pick the icon color from the rows approved for non-text parts. 4. If the design needs a combination that is not listed, raise it with the system team rather than inventing one. ## Limits of a table A table covers flat colors on known surfaces. Text over a photograph, a translucent overlay or a gradient changes the effective background, and those cases need their own check. The table also cannot catch a pair used for the wrong purpose unless people read the permitted-use column, which is why reviews check use as well as color. Auditing live screens with tools is a separate discipline; the table is the design-time half that makes those audits mostly quiet, and it stays trustworthy only if every change to a surface or text role triggers a re-check of the rows it touches.

  • Why record the ratio unrounded rather than as a tidy one-decimal number?
    Because WCAG's guidance treats the thresholds as hard minimums: 4.499:1 does not meet 4.5:1. A rounded 4.5 in the table would approve a pair that fails, and nobody downstream would re-measure it.
  • Should a pair under 3:1 appear in the table at all?
    Yes, marked decorative only. Listing it with that use tells teams the combination exists and is deliberate, and stops someone from reusing a divider or illustration color for text or an icon that people need to read.

A food-allergy chart in a restaurant kitchen: it does not just say a dish is safe or unsafe, it says safe for whom. A pairs table that says only pass or fail is a chart missing that column.

saying these in an interview costs you the question

  • A pair that passes 3:1 is fine for any text on the screen.
  • A pass/fail column is enough; the permitted use is obvious.
  • Designers can eyeball contrast once they are experienced.
  • Rounding 4.46:1 up to 4.5:1 in the table is harmless.
  • Pairs not listed in the table are fine as long as they look readable.