Lighthouse Accessibility: understand contrast findings and fix them

Lighthouse loads the page in a controlled browser environment, evaluates a set of automated accessibility audits, and calculates a weighted score. Accessibility audits are pass or fail; a page does not receive partial points within a single audit when only some elements pass.

The report focuses on the desktop low-contrast audit and includes the score, number of affected elements, selectors or paths, snippets, and the explanation returned by Lighthouse. The result is a time-specific observation of the rendered page, not a permanent property of the site.

• Score A summary for the audited run. Use it to track regressions, not to hide individual failures.
• Issue count The number of elements surfaced by the color-contrast audit in that rendered state.
• Selector and snippet Starting points for locating the element in DevTools and tracing the winning CSS declaration.

WCAG 2.2 Success Criterion 1.4.3 requires at least 4.5:1 contrast for normal text and 3:1 for large-scale text at Level AA, with defined exceptions such as logos and incidental text. Large text is not simply any heading; size and weight determine whether the lower threshold applies.

Non-text interface components and graphical objects needed to understand the content generally require at least 3:1 contrast against adjacent colors under Success Criterion 1.4.11. Focus visibility and the use of color introduce additional requirements that a text-only contrast audit may not fully evaluate.

Open the final URL in Chrome at a desktop viewport and locate the selector from the report. Inspect the Computed panel rather than only the authored rule: inherited color, custom properties, opacity, blend modes, filters, and pseudo-elements can all change the rendered result.

Check whether the element exists only after JavaScript, inside a cookie banner, modal, carousel, error state, or third-party widget. If the selector is generated, use the HTML snippet and surrounding component to find a stable source rule.

• Foreground Identify the final computed text, icon, border, or focus-indicator color.
• Background Find the actual adjacent rendered color, including transparency and layered backgrounds.
• State Reproduce the exact hover, focus, disabled, open, or consent state that produced the finding.
• Ownership Fix the design token or component rule when the same weak pair appears across the site.

Prefer changing shared semantic tokens—such as muted text on a light surface—over adding a one-off selector override. This reduces repeated failures and keeps future components inside the same contrast budget.

Keep the intended visual hierarchy by adjusting both sides of the pair when necessary. Darkening faint text is not the only option; you may also lighten or simplify the background, remove opacity, strengthen the font weight, or use a non-color cue for states and links.

:root {
  --surface-subtle: #f7f7f4;
  --text-muted: #5f5f59;
}

.help-text {
  color: var(--text-muted);
  background: var(--surface-subtle);
}

.help-link {
  color: #a83200;
  text-decoration: underline;
}

Chrome documentation explicitly positions failed Lighthouse audits as indicators for improvement. Automated tools cannot reliably judge every label, reading order, keyboard flow, focus behavior, announcement, alternative text, or task outcome.

After resolving automated failures, navigate the page with a keyboard, test visible focus and zoom/reflow, inspect accessible names and roles, and use a screen reader on critical journeys. Include real users with disabilities when the product and risk level call for it.