Accessibility statement

• the components this system publishes - every package flagged Ready for Dev, as installed from npm and rendered in a consumer's own page;
• this documentation site - every page under this domain.

It does not cover a product built with root. A component that meets WCAG in isolation can be composed into a page that does not, and only that page's own team can test that page.

• axe-core runs over each Ready-for-Dev component's live example, over overlays in their open state (a dialog scanned closed is a dialog nobody scanned), and over the shell's own surfaces: the footer on four page types, the showcase's four compositions, and the roadmap's assessment form;
• keyboard and focus tests run per component, in a real browser, as part of the unit suite: focus order, roving tabindex, escape handling, and what a control does on Enter and Space;
• contrast is measured palette by palette, in both color schemes, for the two components whose whole surface is a color pair - Tag and Badge - and by axe everywhere else it renders. That gate is what caught root-badge at 4.1:1 in neutral and 4.12:1 in alternate, which are fixed: where a ramp's mid step leaves no readable label, the ground moves a step rather than the text.

Every one of those gates blocks a merge. The commands are on the quality page, beside where they run.

• The automated scan reaches one example per component page, the first one. A violation in a component's third example is not caught.
• Components that are not flagged Ready for Dev are not scanned at all. They are on this site with a warning on every page and are not published to npm.
• Every heading on a documentation page is a tab stop. The heading is wrapped in a link to itself so a reader can copy a section's URL by aiming at its title; the cost is a stop in the tab order for each one.
• Automated testing finds a fraction of what a person finds. Nothing on this site has been through a formal audit with screen-reader users. axe checks contrast, names, roles and structure; it cannot tell you whether a flow makes sense.
• Compatibility is stated only where it is tested. The gates run in Chromium. The components use native elements and platform behavior rather than re-implemented widgets, which is what makes them likely to work with whatever a reader uses - but "likely" is the accurate word, and no combination of browser and assistive technology has been formally certified here.

Accessibility defects are treated as defects: they are not a separate backlog, and a component that fails one does not pass the gate that publishes it.