Frontend Architecture
Accessible forms: ship a keyboard-complete form
Reading about accessible forms is not the same as operating one with the mouse unplugged. Build a real multi-field form, then drive it with only the keyboard and a screen reader until every field, error, and submit path works — with evidence at each step.
Turn the unit’s mental model into a reproducible build: associate every label, announce every error through a pre-existing live region, move focus to the first invalid field on submit, prefer native controls, and verify the whole keyboard-and-AT path against WCAG 2.2 AA.
Build (or remediate) a multi-field checkout/signup form — at least name, email, a select, and a submit button — so it is fully usable with the keyboard alone and with a screen reader, passing WCAG 2.2 AA for labels, error identification, status messages, and focus management. Prove it with an assistive-technology walkthrough, not a visual check.
- A keyboard-only walkthrough recording or step list: tab through every field, trigger a validation failure, and confirm focus lands on the first invalid field with no mouse use.
- A screen-reader walkthrough (NVDA, VoiceOver, or JAWS) confirming each field announces its name, each error is announced when it appears, and aria-invalid + aria-describedby read together when the field is focused.
- A WCAG checklist mapping your implementation to 1.3.1, 3.3.1, 3.3.3, 4.1.2, and 4.1.3 — one line of evidence per criterion.
- An automated scan (axe DevTools or Lighthouse) showing zero label/ARIA violations, plus a note on at least one issue the automated tool missed that the manual AT walkthrough caught.
- Add a one-page form-a11y review checklist for your team: label association, live-region-exists-first, aria-invalid + aria-describedby, focus-on-first-invalid, native-control-first, visible focus, logical tab order.
- Add an error summary at the top of the form (a focusable region listing all errors, each linking to its field) and move focus to it on submit — the GOV.UK pattern — and compare the AT experience against focus-on-first-field.
- Replace one native select with a fully-conformant ARIA combobox (filtering) following the APG pattern, then prove with the screen reader it matches the native control's keyboard behavior.
- Wire the keyboard + axe walkthrough into CI so a regression that drops a label or breaks focus order fails the build.
This is the loop you run on every real form: associate every label, render error live regions before writing to them, set aria-invalid + aria-describedby, move focus to the first invalid field on submit, and prefer native controls — then verify by operating the form with the keyboard alone and a screen reader, because the mouse path will always look fine. Doing it once on a real form makes the keyboard-and-AT discipline muscle memory, and turns the form that ‘works with a mouse’ into one that works for everyone.