Accessibility

Automatic WCAG 2.1 contrast checking on the element you’re inspecting. Real luminance math, real alpha blending, real large-text thresholds, not a colour-difference approximation.

WCAG Contrast Detection

When you select an element with the ruler active, Screen Ruler scans every text node and icon inside it for WCAG colour-contrast failures. Each failing element is listed in the side panel with the offending foreground/background colour pair, the actual contrast ratio, and the threshold that was missed (AA or AAA, normal or large text).

Side panel showing a list of WCAG contrast failures with foreground and background swatches — Each failing element shows the colour pair, actual contrast ratio, and the WCAG threshold that wasn’t met. Hover an issue to highlight it on the page.

The check uses the WCAG 2.1 relative-luminance formula (L = 0.2126R + 0.7152G + 0.0722B, with the standard sRGB gamma correction applied per channel) and the standard ratio formula (L1 + 0.05) / (L2 + 0.05). The numbers reported are the same numbers an auditor would calculate by hand, not a heuristic.

What Gets Checked

Two WCAG success criteria are evaluated automatically:

1.4.3 Contrast (Minimum): text against its background. The threshold depends on size: text ≥18 px, or ≥14 px when bold (font-weight ≥ 700), counts as “large” and only needs 3:1 (AA) or 4.5:1 (AAA). Normal text needs 4.5:1 (AA) or 7:1 (AAA).
1.4.11 Non-text Contrast: SVG icons against their background, evaluated at the 3:1 threshold. Multi-coloured icons are skipped (the criterion only applies to monochrome UI graphics).

Transparency & Blending

Most contrast checkers fail when colours involve alpha. Screen Ruler does the proper compositing math: semi-transparent text and backgrounds are blended onto whatever sits behind them, with both the colour’s own alpha channel and the element’s opacity property applied. The resulting effective colour is what gets fed into the luminance calculation.

For elements with no explicit background, the checker walks up the DOM and probes the actual rendered background using elementFromPoint(). If the surface behind your text is a parent’s background colour, that’s what gets compared against. Off-screen issues are re-evaluated when they enter the viewport via an IntersectionObserver, so backgrounds that change with scroll position get the correct ratio when they become visible.

Backgrounds drawn by ::before and ::after pseudo-elements are included in the walk, and blending stops at the first opaque layer. When the surface behind the text is a gradient or an image, no ratio is reported rather than a guessed one.