a11ylisted

# Accessibility ## Coverage - Semantic HTML: choosing the right primitive elements so structure is meaningful to assistive technology - Keyboard access: making every interaction reachable and operable without a pointing device - Focus management: keeping focus visible, predictable, and correctly placed after navigation and state changes - Labeling and naming: ensuring every interactive element has a programmatic name that matches its visible label - State and change announcement: communicating dynamic updates (loading, errors, success) to assistive technology - Reduced-motion and high-contrast preferences: respecting user settings that affect interaction perception ## Philosophy Accessible interaction is structural, not cosmetic. It is decided by the primitive you picked, the focus order you wrote, and the label that ships or doesn't — not by the audit that runs after. Teams that treat accessibility as a finishing pass pay for it twice: once in remediation work that was cheaper to avoid, and again when assistive-technology users hit the failure and bounce. The correct default is to build with those users in scope from the first commit, not after the first lawsuit. ## Primitive Selection The single highest-leverage accessibility decision is picking the right HTML primitive before styling. A wrong primitive cannot be rescued by ARIA; the right primitive usually needs no ARIA at all. | User intent | Correct primitive