Lighthouse 100 in accessibility gives the team confidence the site has yet to earn. The tool checks contrast and alt text while missing confusing focus order, clickable divs without labels, and modals that trap the keyboard. Real accessibility combines WCAG patterns applied in code with manual screen reader testing; the examples below cover both.

Why does semantic HTML come 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 says to reach for native HTML wherever it exists; save ARIA for custom widgets.

How do you manage focus in routes, modals, and skip links?

  • 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

How do you build 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, and the browser fills fields better too.

When do live regions apply?

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.

How do you test with screen readers?

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.

Does 4.5:1 contrast cut it?

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.

Which practices fit the team process?

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