v1.28.0

Accessibility: the widget now meets WCAG 2.2 AA, and it is verified on every CI run.

Fixed

The widget did not meet the WCAG 2.2 AA it is described as meeting. An audit against the applicable criteria found seven contrast failures:

checkbox border   light  #c1c1c1 on #fafafa   1.72:1   needs 3:1
checkbox border   dark   #555555 on #1e1e1e   2.24:1   needs 3:1
brand text        light  #ff2a6d on #fafafa   3.47:1   needs 4.5:1
logo text         light  #999999 on #fafafa   2.73:1   needs 4.5:1
logo text         dark   #808080 on #1e1e1e   4.22:1   needs 4.5:1
verified fill            #4caf50 on surface   2.66:1   needs 3:1
check glyph              white on #4caf50     2.78:1   needs 4.5:1

The worst was the checkbox border — the visual boundary of the control a person has to find and click. Replacement colours were computed from contrast ratios rather than chosen by eye, and each is annotated with its measured ratio.

The control had no focus indicator of its own, relying on the user agent's. Since the widget renders inside someone else's page, a host stylesheet resetting outlines removed it entirely. It now draws both an outline and a box-shadow: an outline reset removes one, forced-colors modes remove the other, and neither alone covers both.

Decorative glyphs and the spinner are now hidden from assistive technology rather than announced as stray characters, and the spinner stops under prefers-reduced-motion.

Added

Nine WCAG 2.2 AA criteria verified in CI against the rendered widget — contrast (1.4.3), non-text contrast (1.4.11), use of colour (1.4.1), reflow (1.4.10), keyboard (2.1.1), focus visible (2.4.7), target size (2.5.8), name/role/value (4.1.2) and status messages (4.1.3). Values are computed from what the browser paints rather than from the source, and the focus test deliberately applies a host stylesheet that suppresses outlines globally.

COMPLIANCE.md documents the conformance position, each criterion and how it is checked — and its boundary: these are the criteria applying to a control of this size, verified automatically. They are not a full audit of an embedding page, and no automated suite substitutes for testing with real assistive technology.

Note

This complements rather than replaces the existing measurement, which asks a different question: not "can a screen reader operate the control" but "does the bot detector decide the screen-reader user is a bot". That panel — keyboard-only, screen-reader, touch, motor-tremor, elderly, high-latency — continues to fail the build when any signal exceeds its false-positive budget. It remains at 0.00%.