Accessibility

The problem

Accessibility usually gets audited once, right before a launch or a sales deal needs it. By then there are hundreds of screens to fix, and nothing stops the next pull request from breaking them again.

What Bones does

Bones checks accessibility on every pull request, against WCAG 2.2 AA.

• Every surface. The sweep covers the blog, the docs, the marketing site, and every Storybook story. Stories cover every web-app page, so the app is checked without signing in.
• Both color schemes. Each page and story is checked in light and in dark.
• Roles and names. Each page lists the landmarks, headings, and labeled controls it must expose. The sweep reads them from the browser's accessibility tree, the same one a screen reader uses. 137 checks pass today.
• axe rules. axe checks each page against WCAG 2.2 AA. No violations are known, and the check fails on a new one.
• Contrast is reported. Each contrast failure is listed by text and background token, so one token change clears a whole row.

The design system backs it up. Focus is always visible, and every control has a name.

What isn't done yet

• Contrast. The smallest gray text, used for captions and metadata, is under AA. It's reported, not failing, until a design pass picks the fix.
• The desktop app isn't swept.
• The chatbot doesn't announce replies to screen readers yet.
• Keyboard and screen-reader testing is manual. axe can't judge either.

How it compares

Option	Trade-off
A one-off audit	Thorough, but out of date after the next release
An overlay widget	Quick to add, but doesn't fix the underlying markup
Accessible primitives (Radix, Mantine)	Good components, but nothing checks the pages you build

Bones starts from Mantine's accessible components and checks every page built from them.

Go deeper

• axe and Playwright — the tools behind the sweep.
• Accessibility — running the sweep and adding a page.