Lighthouse 100 in accessibility gives the team confidence the site has yet to earn. The tool checks contrast and alt text but misses confusing focus order, clickable divs without labels, and modals that trap the keyboard. The WCAG 2.2 specification requires you to test ARIA patterns in code and validate with a screen reader.

Semantic HTML before ARIA

A <button> delivers visible focus, keyboard support, and screen reader announcement for free. The same interaction with <div onclick> demands tabindex, an Enter handler, and a role rebuilt by hand, each one a chance for bugs. The first rule of ARIA, documented by the W3C, says to reach for native HTML wherever it exists.

Focus management

  • A route change sends focus to the new content heading
  • A modal traps Tab inside the dialog and restores focus to the trigger element on close
  • A skip link jumps repeated navigation and lands on the main content
  • Visible focus styling gets redesigned when the brand asks; deleting it with outline: none breaks keyboard navigation

Accessible forms

Associate every label through for/id and connect error messages via aria-describedby inside an aria-live region. Mark required fields in text, beyond color alone. Correct autocomplete attributes (cc-csc, email) help people with cognitive and motor limitations.

Live regions

A success toast uses aria-live="polite". A critical payment failure calls for "assertive". Live regions in excess drown users in announcements and turn NVDA into noise. One region per context does the job.

Screen reader testing

NVDA on Windows and VoiceOver on macOS cover most of the user base. Learn two commands before trusting any walkthrough: the headings list (navigate with H) and forms mode on NVDA. Five minutes of keyboard-only navigation per release reveal problems no score shows.

4.5:1 contrast

The WCAG AA minimum passes automated checks and fails outdoors, with sunlight hitting the phone screen. Aim for 7:1 (AAA level) on body text and validate at maximum device brightness.

Team process

axe-core in CI catches regressions on every pull request. A manual keyboard-only sweep joins the release checklist. Accessibility acceptance criteria appear written into feature tickets. The checklist sets the floor; correct code and screen reader testing build the rest.