How this was checked
Accessibility claims are worth exactly as much as the method behind them, so the method is published - including its limits. Automated tooling does not prove conformance; neither does this page.
What is checked automatically
Section titled “What is checked automatically”| Check | Where | What it covers |
|---|---|---|
axe, wcag2a / wcag2aa / wcag21a / wcag21aa | packages/ui/tests/accessibility/ | The gallery, the compatibility harness and each overlay open, in light and dark |
| axe, the same tags | apps/catalogue/tests/a11y.spec.ts | Every catalogue page, in light and dark |
| Keyboard specs | packages/ui/tests/keyboard/ and the component specs | Each component’s documented key set, not a sample |
| Focus specs | packages/ui/tests/focus/ and the overlay specs | Entry, trapping where applicable, and restoration |
| Contrast | packages/ui/scripts/measure-contrast.mjs | Every required foreground pair, measured from the shipped sheet |
| Visual baselines | packages/ui/tests/visual/ | Each group rendered, reviewed by eye, in Chromium |
All of the above run in Chromium, Firefox and WebKit.
What it does not cover
Section titled “What it does not cover”No screen reader has been driven against this library. Where this catalogue describes screen-reader behaviour - the accessible name a control computes, the live region a toast uses - it is describing the markup and the ARIA that is emitted, not the output of a tested screen reader. Treat it as the intended behaviour until a manual pass says otherwise. A manual pass with keyboard only, the accessibility tree and at least one screen reader remains required by the solution specification.
Two axe rules are worked around:
| Rule | Where | Why | Compensating check |
|---|---|---|---|
color-contrast | The open popover and tooltip scans | axe cannot resolve a shadow-root background for slotted content, so it cannot compute a ratio for it | measure-contrast.mjs measures the same token pairs directly from the shipped sheet, and fails on a miss |
| Page-wide scans of an open modal dialog | tests/accessibility/dialog.a11y.spec.ts | The backdrop dims the page, so a page-wide scan measures dimmed content | The dialog scan is scoped to the panel |
The visual baselines run in Chromium only. Baselines are platform-specific and no Linux set exists yet, so the suite is skipped in CI (TASK-029). The accessibility scans are not affected.
It is not perfect, and the suite does not catch everything
Section titled “It is not perfect, and the suite does not catch everything”Writing the component pages turned up three defects the automated checks had passed over, recorded in the issues catalogue:
ISS-009-hui-tooltip’srichanddelayattributes do nothing.ISS-010-hui-radio-group’sorientationreaches the layout but notaria-orientation.ISS-011-hui-dialogrenders its title but gives the dialog no accessible name. axe tags the dialog-name rule as best-practice, so the WCAG-tagged suite does not run it.
They are listed here rather than hidden because the honest number is not “zero findings”; it is “what the method can and cannot see”. See the Gotchas page and the component pages for the current state of each.
Checking your own application
Section titled “Checking your own application”Run axe against the host’s rendered pages, not just the components:
pnpm dlx @axe-core/cli http://localhost:8080/race-entryThe three things that most often fail on a host page built from Home-UI are the three the host owns: missing names, the current item, and the error text - plus colour used alone to convey meaning.