In a consumer app, an inaccessible interface costs a user a convenience. In a banking or healthcare product, it can prevent someone from managing their money or their care. The consequences of exclusion scale with the consequences of the product.
This is a working checklist rather than a standards summary. It covers what teams most often get wrong in practice.
Structure and semantics
- One clear h1 per page, with a heading hierarchy that reflects real structure
- Native elements before ARIA — a button element beats a div with a role
- Landmarks (header, nav, main, footer) so assistive technology can skip around
- A skip link that actually moves focus to the main content
- Language declared on the html element
Keyboard operability
Everything achievable with a mouse must be achievable with a keyboard. This is where custom components most often fail — menus, comboboxes, date pickers, modals, drag-and-drop and data grids.
- Logical tab order that matches the visual order
- No keyboard traps; Escape closes overlays and returns focus to the trigger
- Focus moved deliberately when content appears, and restored when it disappears
- Visible focus indication with sufficient contrast against every background it appears on
- Custom controls implement the expected key interactions for their pattern
Colour, contrast and visual presentation
- Text contrast meets the level you have committed to, including placeholder and disabled-adjacent text
- Interface components and meaningful graphics meet non-text contrast requirements
- Colour never the sole carrier of meaning — pair status colour with text or an icon
- Layout survives 200% zoom and 400% reflow without loss of content or function
- Respect prefers-reduced-motion for non-essential animation
Forms and errors
Financial and healthcare products are largely forms, and forms are where accessibility failures have the most direct cost.
- Every input has a persistent, programmatically associated label — placeholders are not labels
- Errors identified in text, associated with their field, and announced to assistive technology
- Error summaries at the top of long forms, linking to the fields that need attention
- Required fields indicated in text as well as visually
- Inputs accept the formats people naturally use, especially for amounts, dates and reference numbers
- Sessions do not expire without warning and a way to extend
Dynamic content
- Status messages announced without stealing focus
- Loading and empty states conveyed non-visually
- Modals trap focus while open and return it on close
- Toasts remain long enough to read, and are reachable
Verify continuously
Automated tooling reliably catches perhaps a third of real issues — contrast, missing names, structural problems. It cannot tell you whether focus order makes sense or whether an error message is understandable. Combine automated checks in the pipeline with periodic manual testing using a screen reader, keyboard-only navigation and zoom.
Most importantly, test with people who use assistive technology daily. Nothing else surfaces the difference between technically conformant and genuinely usable.