Accessibility checklist
One page, run against one screen, before it ships. Accessibility argues the position; this is the list you actually work through, with the item that fails pointing at the page that explains why.
This is a design and build checklist, not a conformance audit and not a substitute for testing with disabled users. Passing every line here is consistent with a screen that is still unusable, which is why the last section is the only one that measures anything. An accessibility conformance report is a separate exercise with a separate method.
How to run it
Against one screen in one state, not an application. Most of these fail per-state rather than per-screen: the empty variant, the error variant and the alarm-active variant of the same page fail differently, and a checklist run against the happy path finds almost nothing.
Four passes, in this order, because each one is cheapest before the next: keyboard only, then 400 % zoom at 320 px, then greyscale, then a screen reader.
1 · Keyboard only — unplug the mouse
| Check | Specified in |
|---|---|
| Every control is reachable and operable by keyboard, including anything revealed by hover — SC 2.1.1 | Interaction states |
| Focus is always visible, at 2 px with 2 px offset, and never removed for aesthetics — SC 2.4.7, 2.4.11 | Interaction states |
| Focus order follows reading order; a dialog does not focus its affirmative control | Dialog |
| No keyboard trap; Escape leaves every overlay — SC 2.1.2 | Menu · Dialog |
| Nothing is lost by tabbing away mid-entry; paste is never blocked in any field | Sign in |
| Every gesture has a visible single-pointer equivalent — SC 2.5.1 | Touch & gestures |
| Dragging is never the only means of setting a value — SC 2.5.7 | Touch & gestures |
| Actions fire on release over the target, not on touch-down — SC 2.5.2 | Touch & gestures |
2 · 400 % zoom, 320 px wide
| Check | Specified in |
|---|---|
| No loss of content or function; no two-dimensional scrolling except for genuinely two-dimensional content — SC 1.4.10 | Grid & layout |
| Wide content — tables, charts, timelines — scrolls inside its own container; the page body never scrolls horizontally | Grid & layout |
| Text spacing can be overridden without clipping — SC 1.4.12 | Typography |
| Nothing that must not be missed is clipped, truncated or wrapped away — check the patient identity strip specifically | Patient header |
| Targets are at least 44 px, 56 px where gloved or destructive, with dead space between — SC 2.5.8 | Touch & gestures |
| Text is at or above the floor size; nothing carrying a decision is below the decision size | Scaling & density |
| Sticky headers and alarm regions do not eat the viewport at 400 % | Elevation |
3 · Greyscale and contrast
| Check | Specified in |
|---|---|
| Every state is still distinguishable with colour removed — alarm priority, selection, validity, changed-vs-unchanged — SC 1.4.1 | Colour |
| Text meets 4.5:1, large text 3:1 — SC 1.4.3 | Tokens |
| Control boundaries and state indicators meet 3:1 — SC 1.4.11. Measure them; this is the check most often assumed rather than run, and this system has failed it twice on its own pages | Colour |
| Alarm colours are unchanged between light and dark themes | Tokens — enforced by
check-tokens.mjs |
| Run it in dark mode as a separate pass. Every colour defect this system has shipped was theme-specific | Colour |
| No information carried by position alone in a chart; series are directly labelled | Data visualisation |
4 · Screen reader
| Check | Specified in |
|---|---|
Landmarks, one h1, headings in order, and the page is navigable by
heading |
Accessibility |
| Tables are real tables with scoped headers; lists are real lists, so announced counts are right | Data grid · List |
| Every control has an accessible name that says what it does; no set of identical link names | Button |
| Alarm conditions are assertive live regions; everything else is polite | Messaging |
| Errors are associated with their field and state a remedy — SC 3.3.1, 3.3.3 | Text field |
| An absent value is announced as absent, distinctly from zero | Key–value pair |
| Charts and image fields carry a description stating quantity, direction and magnitude — a name alone is not a description | Data visualisation |
| Machine-composed text announces its status before the text, not after | Authorship |
| Nothing is announced only in a tooltip; tooltips describe, never label | Tooltip |
5 · The clinical additions
Not in WCAG. They come from the same place the rest of this system does — a clinician, in a hurry, on a device that was not chosen for them.
| Check | Specified in |
|---|---|
| No time limit anywhere a user can fail one — SC 2.2.1, and treated as a hard rule rather than a with-exceptions one | Lockout & recovery |
| Motion is suppressed under reduced-motion, not merely slowed; nothing animates routinely | Motion |
| Nothing that must not be missed sits behind a collapse, a hover, a filter or a non-first tab | Messaging |
| Every count has its denominator; nothing is capped | Badge |
| Units are on the surface, never hover-only, never inferred | Key–value pair |
| The screen is legible at the longest sightline it will actually be read from | Scaling & density |
| It works one-handed, in gloves, on a moving cart | Touch & gestures |
6 · The only part that measures anything
Everything above is inspection, and inspection finds the defects you already know how to look for. The list has a ceiling and this is where it is.
- Test with disabled users, including disabled clinicians. A screen reader user who works on a ward will find things in ten minutes that this page cannot describe.
- Formative evaluation under IEC 62366-1 covers accessibility failures as use errors, and the two exercises should not be run separately when they are looking at the same screens.
- Record what you could not test, in the same spirit as Known gaps. An untested assistive technology is a gap, not an absence of findings — and this system's own honest position is that it has done none of this.
Accessibility failures are use errors. They belong in the usability engineering file (IEC 62366-1) and, where they can lead to harm, in the risk file (ISO 14971) — not in a separate accessibility document nobody reads alongside them. In the EU, EN 301 549 is the harmonised standard that points at WCAG; the accessibility requirements of the European Accessibility Act may also apply depending on your product and users. Paraphrase, not legal advice.
Do's and don'ts
Run it against the error state and the alarm-active state of the screen, separately.
These fail differently from the happy path, and they are the states a clinician is in when the stakes are highest.
Run it once, on the populated, everything-working view.
The version of the screen nobody has trouble with. It will pass, and it will have told you nothing.
Measure the 3:1 on control boundaries.
This system asserted it twice and was wrong twice — 1.71:1 on a pill border, 1.29:1 on a citation control. Both looked fine to the person who drew them.
Tick 1.4.11 because the border is visible to you on your monitor.
Your monitor, your lighting, your eyes. None of the three is the specified context of use.
Record what you could not test, and treat it as a gap.
An untested assistive technology produced no findings, which is not the same as no defects — the distinction this whole system is built on.
Report "no accessibility issues found".
A checklist finds the defects it was written to look for. Saying so costs nothing; not saying so misleads whoever reads the file next.
Related
- Accessibility — the argument, the spectrum of ability, and why the floor is where it is.
- Touch & gestures — the success criteria that turn into physical requirements on a cart.
- Messaging — which vehicle, and what each one must announce.
- Status & limitations — including that none of the testing in section 6 has been done for this system.
- Contributing — the prohibitions, several of which exist because of a line in this list.