The contrast matrix problem
Tables stack color decisions in ways no other component does. A row in a data table may simultaneously carry a default background, a hover state, a selected state, and a status indicator — and the text, icons, and badges inside that row must maintain accessible contrast against whichever background state is active. A status badge with 4.5:1 contrast on a default white row may drop below 3:1 when the same row is selected and carries a pale blue background. The correct approach is to enumerate every possible row background state (default, hover, selected, flagged, error) and verify all foreground colors against each one — a verification matrix rather than a single contrast check. Most WCAG auditing tools check against the page background, not component-specific backgrounds; the matrix must be checked manually or with specialized tooling.
Row encoding beyond color
Color-based row encoding — using background tints to distinguish data categories, stripe alternating rows for readability — is accessible only when color carries a structural rather than semantic signal. Zebra striping that communicates 'rows are visually separated' is acceptable as a color-only technique because the underlying data meaning (these are separate rows) can be inferred without color. Category encoding that communicates 'this row belongs to category A and this one to category B' requires a non-color redundant signal: a category icon in a leading column, a bold category header row, or visible group dividers. The WCAG success criterion 1.4.1 (Use of Color) applies directly: information that is communicated by color alone must also be communicated by another means.
Status color conventions and icons
Red, yellow, and green for error, warning, and success are the most cross-culturally consistent color conventions in enterprise UI. They work — and should not be reinvented. The accessibility requirement is that these colors cannot stand alone: an icon (✕, ⚠, ✓), a text label ('Error', 'Warning', 'OK'), or a pattern must accompany any status color signal. In dense tables where cell background coloring would reduce text legibility, a dedicated status column with icon-plus-color is the standard solution: it adds no semantic complexity, preserves foreground text contrast, and satisfies WCAG 1.4.1 simultaneously. For very dense tables where a status column would consume too much horizontal space, a narrow colored left-border stripe (4px) paired with a tooltip on focus provides the color indicator without background coloring.
Managing color density at scale
Large tables with heavy color encoding suffer visual fatigue — when every row carries multiple colors simultaneously, the eye has no resting point and nothing stands out. The remedy is a strong default state: most cells white or near-white, dark text, no background color. Color is then reserved for states and exceptions, ensuring that any colored row is immediately noticeable against the uncolored baseline. A table that applies row tints, hover highlights, status badges, and selection colors simultaneously on every row has no contrast hierarchy — everything is equally emphasized, meaning nothing is. Audit tables for color density by switching to grayscale: if the table still communicates clearly in grayscale, the information architecture is sound and color is playing a reinforcement role. If the table is illegible in grayscale, color is carrying too much semantic weight.
