Accessible Color in Data Tables: Contrast, State, and Row Encoding

Data tables accumulate color decisions in ways that single-purpose components do not. A table must simultaneously communicate: which row is selected (state), which rows are flagged or have warnings (status), which values are highest or lowest (encoding), which row the cursor is over (hover), and which cells are editable (affordance). When each of these is handled independently, the table ends up with 6-8 distinct colors applied in competing contexts — often exceeding the accessible contrast requirements of at least one of them. **The contrast hierarchy problem** Every color in a table must meet contrast requirements not against the page background, but against the specific cell or row background it appears on. A status badge with 4.5:1 contrast on white may fall below 3:1 when placed on a selected-row background that is a pale blue. The correct approach is to specify state backgrounds first, then verify that all foreground colors (text, icons, badges, status indicators) meet contrast requirements against every possible background state they might appear on. For a table with 3 row states (default, hover, selected), each foreground color needs to be verified against 3 backgrounds — this creates a verification matrix, not a single contrast check. **Row encoding without color dependence** Row encoding — communicating that one row represents a different data category than another — is frequently implemented with color alone (alternating row tints, category color stripes). This approach fails for colorblind users and low-vision users. The accessible approach uses color as a secondary reinforcement, not the sole signal: different row categories should also differ in typography (category headers in a heavier weight), iconography (a category icon in a leading column), or structural grouping (expanded row headers). The alternating row tint for visual separation (zebra striping) is acceptable as a color-only indicator because it communicates 'rows are separate' rather than 'this row means something different' — a structural signal, not a semantic one. **Status color in tables** Red, yellow, and green for error, warning, and success are nearly universal conventions in data tables. The accessibility requirement is that these colors cannot be the sole differentiator — an icon, a word, or a pattern must accompany any color-only status indicator. In dense tables this often means a small status icon in a dedicated column rather than cell background coloring, which preserves both text legibility and color-blind accessibility. For tables where row density prohibits icons, a text label in the status column ('Error', 'Warning', 'OK') satisfies the requirement with zero visual complexity cost. **Managing color density in large tables** Large data tables with heavy color encoding suffer from visual fatigue — the eye has no resting point. The most reliable countermeasure is a strong default state: most cells should be white or near-white with dark text, with no background color. Color is then reserved for states and exceptions, so that any colored cell is immediately noticeable against the uncolored majority. A table where every row has a background tint, hover highlights, and status badges all simultaneously active has no contrast hierarchy — everything is equally emphasized, which means nothing is emphasized. Restraint in the default state makes exceptions visible.