Status first, this is a work in progress. The foundation is accessible and the starter follows a few sensible conventions on top of it, but none of it has been through a formal audit yet. More support is coming. Treat what is here as a solid base to build on rather than a compliance guarantee, and lean on it accordingly.
Most of the real accessibility work is already done, because the ui/ primitives are reka-ui. Keyboard navigation, focus management, ARIA wiring, and focus traps come baked into the primitives, so a dialog traps focus, a menu is arrow-key navigable, and controls announce themselves without you writing any of it.
The practical upshot is a warning as much as a feature. The moment you hand-edit a primitive you are one careless change away from breaking behavior you did not know was there. This is the same reason the component layering keeps ui/ untouched, and accessibility is a big part of why. Anything app-specific belongs in a common/ wrapper, so the accessible primitive underneath keeps working.
On top of the primitives the starter follows a couple of habits worth keeping as you add to it.
Icon-only controls get a visually hidden text label, so a button that shows only an X still announces "Close" to a screen reader. Sheets and dialogs get an accessible name through a hidden title, so they are announced as what they are on open even when the visible design is just a logo. And the button primitive keeps a visible focus ring, so keyboard users can always see where they are.
None of these are exotic. They are just the small things that are easy to forget and annoying to retrofit, so the starter does them from the start and you copy the pattern.
The gaps are worth being honest about.
There is no automated accessibility audit in the pipeline yet, so nothing is catching regressions for you. Color contrast is your responsibility whenever you pick or adjust theme token colors, since the tokens are hand-set values and nothing verifies them. And any new feature is only as accessible as you make it, so keyboard and screen-reader flows are worth an actual pass rather than an assumption, especially on anything interactive you build outside the primitives.
Component Architecture for why the accessible primitives stay untouched. Mobile for the slide-out menus, where most of the hand-written accessibility work currently lives.