Accessibility Baseline

Accessibility is a correctness requirement, not a polish pass — build it in from the first component, not retrofitted before launch.

Semantic HTML first

• Use the native HTML element that matches the behavior you need (<button> for actions, <a> for navigation, <label> for form fields) before reaching for a <div> with an ARIA role and a click handler — native elements come with keyboard support, focus handling, and screen-reader semantics for free.
• Never use a non-interactive element (<div>, <span>) as a click target without also making it keyboard-operable (tabindex="0", role, Enter/Space key handling) — if you find yourself doing this, use a real <button> instead.

Keyboard operability

• Every interactive element must be reachable and operable via keyboard alone — Tab to focus, Enter/Space to activate, Escape to dismiss overlays. Test your own UI with the mouse unplugged.
• Never trap keyboard focus outside of an intentional, dismissible modal — and when you do trap it in a modal, always return focus to the triggering element on close.
• Maintain a visible focus indicator on every focusable element. Never set outline: none without providing an equally visible custom replacement.

Color and contrast

• Text must meet WCAG AA contrast ratios against its background: 4.5:1 for normal text, 3:1 for large text (≥18pt or ≥14pt bold).
• Never use color as the only signal for meaning (error states, required fields, status) — pair it with an icon, text label, or pattern so colorblind users get the same information.

Images and media

• Every meaningful <img> needs descriptive alt text; every purely decorative image needs alt="" so screen readers skip it instead of announcing a meaningless filename.
• Provide captions or transcripts for video/audio content that carries information.

Forms

• Every form input needs a programmatically associated <label> (via for/id, or wrapping) — a placeholder is not a label; it disappears the moment the user starts typing.
• Announce validation errors to assistive tech (aria-describedby linking the error message to the field, aria-invalid on the field) — a red border alone communicates nothing to a screen reader.

Dynamic content

• Use aria-live regions for content that updates without a page navigation (toast notifications, live search results) so screen-reader users are notified of changes they can't see.
• Manage focus explicitly after route changes and modal open/close — don't leave focus stranded on a now-invisible element.

Testing

• Run an automated checker (axe, Lighthouse) as a baseline, but never rely on it alone — it catches roughly a third of real issues. Manually test with keyboard-only navigation and at least one screen reader (VoiceOver, NVDA) before shipping anything user-facing.