rgoussu.dev
rgoussu@goussu: ~/library/frontend
❯ ~/library/frontend cat accessibility.md

Accessibility

# Building interfaces that work for everyone — semantic HTML first, ARIA as the escape hatch, keyboard and focus discipline, and testing that catches what tools miss.

Conceptsaved 2026-08-08 #frontend#accessibility#a11y#html#ux

Overview

Accessibility (a11y) is making interfaces usable with a screen reader, a keyboard alone, low vision, motor or cognitive constraints — a population far larger than intuition suggests, plus every user temporarily (bright sun, broken trackpad, one-handed). Practically, most of it is not extra work but using the platform as designed: semantic HTML carries accessibility for free, and the majority of real-world failures come from rebuilding native behavior in divs and JavaScript. WCAG is the standard (and, increasingly, the law — ADA case law, the European Accessibility Act).

Key points

  • Semantic HTML is 80% of it: <button>, <a>, <label>, headings in order, landmarks (<nav>, <main>), <ul> for lists — each carries role, state, keyboard behavior, and focusability natively. A div onclick has none of that, and now you owe all of it by hand.
  • The accessibility tree is what assistive tech consumes — DOM + roles/names/states. Every interactive element needs an accessible name (visible label, aria-label as fallback); icon-only buttons are the classic silent failure.
  • ARIA is a contract, not a sprinkle: first rule — don't use it when HTML suffices; when you do build custom widgets, the WAI-ARIA Authoring Practices patterns (combobox, dialog, tabs) specify the complete keyboard + attribute contract; ARIA claims behavior, JS must deliver it — wrong ARIA is worse than none.
  • Keyboard & focus discipline: everything operable by keyboard, visible focus indicator (:focus-visible), logical order, no positive tabindex; modals trap and restore focus; skip links; SPA route changes move focus and announce — the DOM changed but nobody heard it (aria-live for dynamic updates).
  • The visual floor: contrast ratios (4.5:1 text), never color as the only signal, text resizable to 200%, prefers-reduced-motion honored, touch targets big enough.
  • Testing reality: automated tools (axe) catch ~30-40% — the mechanical failures; the rest needs a keyboard-only pass and a screen-reader session (VoiceOver/NVDA) on your critical flows. Bake axe into CI, put a11y criteria in the definition of done, and fix the design system components once — every consumer inherits it.
  • To explore: WCAG 2.2 AA as the working target, accessible names computation (labelling edge cases), forms & error-message patterns, cognitive-load guidelines.

Practice

  • Audit a page you own (source) — run axe, then a keyboard-only pass, then a VoiceOver/NVDA session against WCAG 2.2 AA and fix every finding; teaches exactly what automated tools miss.
  • Frontend Mentor (source) — build challenges semantic-HTML-first and screen-reader-test each one; drills landmarks, labels, and focus order on realistic designs.
  • APG widget build (source) — implement a combobox, dialog, and tabs to the complete WAI-ARIA Authoring Practices contract — keyboard behavior and attributes both, no library.
  • Design system from scratch (source) — bake the a11y contracts into components once and watch every consumer inherit them.

Related