Documenting accessibility per component

WHAT THIS TESTS This assesses whether you treat accessibility as concrete, per-component guidance rather than a vague aspiration on one shared page.

A GOOD ANSWER COVERS Every component page gets its own accessibility section that lives next to the props and examples. For Tabs, document the expected keyboard model as a clear table: Tab moves focus into the active tabpanel, arrow keys move between tabs, Home and End jump to the first and last tab, and Enter or Space activates a tab if activation is manual. Document the ARIA structure: the tablist role on the container, tab role on each trigger with aria-selected and aria-controls, and tabpanel role with aria-labelledby. State which behavior the component implements automatically and which the consumer must provide, such as accessible labels. Reference the WAI-ARIA Authoring Practices Guide pattern, and embed a live, focusable example so developers can verify behavior. Pair docs with automated and manual tests so they cannot drift.

COMMON WRONG ANSWERS A single global accessibility page with no component specifics. Listing ARIA roles without keyboard behavior, or vice versa. Documenting the ideal pattern while the component does not actually implement it.

LIKELY FOLLOW-UPS How do you keep docs in sync with the implementation? How do you document the split between automatic versus manual tab activation? How do you test these interactions?

ONE CONCRETE EXAMPLE The Tabs page shows a keyboard table, an ARIA attribute list mapping tablist, tab, and tabpanel, and a note that the consumer must pass a label for the tablist. A live demo lets a developer press arrow keys and watch focus and aria-selected update in real time.