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.