Auditing a Low-Contrast Analytics Dashboard
A stakeholder pushes back on your accessibility review of an analytics dashboard: "The light-gray text on white background looks clean and modern — I don't see the problem, and nobody's complained." The body text is #999999 on a #FFFFFF background at 14px regular weight. A row of small status icons (no visible border, just a subtle fill color shift) indicates pass/fail state for each metric.
- Is the body text likely to pass WCAG 2.1 AA, and how would you determine this definitively rather than arguing about how it looks?
- Does the icon-based status indicator raise a separate contrast concern from the body text, and if so, which WCAG requirement applies to it?
- How would you respond to "nobody's complained" as a justification for leaving it as-is?
- Propose a concrete fix for both the text and the icons.
1. Checking the body text definitively
#999999 on #FFFFFF is a well-known borderline case — its actual contrast ratio is approximately 2.85:1, well under the 4.5:1 minimum WCAG 2.1 AA requires for normal text (14px regular is normal text, not large text, since large text requires 18pt/24px+ regular or 14pt/18.67px+ bold). Rather than debating whether it "looks" fine, run the two hex values through a contrast checker tool, which returns an objective ratio and a pass/fail against the cited threshold — this is exactly the point of a numeric standard: it converts a subjective design argument into a testable one either side can verify independently.
2. The icon status indicators
Yes — this is a separate requirement from body text contrast. WCAG 2.1 AA requires a 3:1 minimum contrast ratio for UI components and graphical objects that convey information, which explicitly covers status icons a user needs to perceive to understand the interface. A subtle fill-color shift with no border and low contrast against its background fails this even if the body text elsewhere on the page were fixed — it's a distinct check that needs to be run separately, not automatically covered by fixing the text.
3. Responding to "nobody's complained"
Absence of complaints is not evidence of accessibility, for two reasons: users who can't read the dashboard due to low contrast often don't file a support ticket, they just quietly stop using the feature or work around it, so the signal never reaches the team; and the population affected — low-vision users, older users, anyone viewing the screen in bright ambient light — may not be well-represented among whoever currently uses the product, which itself can be a symptom of the barrier rather than evidence it doesn't exist. The correct evidence standard is the WCAG check itself, not the absence of a complaint inbox signal.
4. Concrete fixes
For the text: darken it to at least #767676 on white (roughly 4.54:1, clearing the 4.5:1 threshold) or darker for a safety margin, verified with a contrast checker rather than eyeballed. For the icons: add either a stronger fill-color contrast against the background that clears 3:1, or don't rely on color alone at all — pair the fill-color shift with a distinct shape (a checkmark for pass, an X or exclamation mark for fail) so the status is perceivable even for a color-blind user for whom a subtle color shift alone may not register as a difference regardless of contrast ratio.
Share this question