Accessibility
An outcome of use, not a checklist. WCAG is the testable floor this system enforces mechanically — the actual requirement is that the widest range of clinicians can do their job, including on the night they are least able to.
Overview
Accessibility is one of the four outcomes that make up human-centred quality: the extent to which a system can be used by people with the widest range of needs, characteristics and capabilities to achieve their goals in their context. That definition is broader than conformance, and the gap between the two is where most clinical software fails.
The gap matters more here than in consumer software for one structural reason: the user population is not self-selecting. A shopper who cannot use a website leaves. A registrar with a red–green deficiency, a consultant with presbyopia and a nurse with a hand injury are all on the rota tonight, and the software is what they have.
Redundant
Every piece of meaning is carried by at least two channels. Anything encoded once — in colour, in position, in sound — is meaning somebody will not receive.
Situational
Capability is a state, not a category. Gloves, glare, one free hand and the twelfth hour of a shift produce the same demands as permanent impairment, in everybody.
Verified
Claims are measured and reproducible. A conformance statement nobody can re-run is an opinion with a version number.
Permanent, temporary, situational
Designing only for permanent impairment underestimates the affected population by an order of magnitude. Each row below has the same interface consequence, so the system does not distinguish them.
| Capability | Permanent | Temporary | Situational — in this context |
|---|---|---|---|
| Vision | Low vision, presbyopia | Eye infection, dilated pupils | Reading a wall display at 4 m; glare in a bright bay; a darkened reading room |
| Colour vision | Deuteranopia, protanopia | — | Greyscale print in the patient record; a miscalibrated bedside panel |
| Hearing | Hearing loss | Ear infection | A noisy resuscitation bay; ear protection; alarms competing across four bays |
| Motor | Tremor, arthritis, single-handed use | Fracture, splint | Double-gloved; holding an ultrasound probe; a monitor in a moving ambulance |
| Cognitive / attention | ADHD, dyslexia | Concussion, illness | Twelfth hour of a night shift; interrupted every ninety seconds; a running arrest |
| Language | — | — | Reading a second or third language under time pressure; agency and locum staff |
Every rule in this system that looks like an accessibility accommodation is also a night-shift accommodation. Priority words alongside colour help a clinician with a colour vision deficiency and a clinician reading a greyscale printout and a clinician who is simply too tired to discriminate a hue at 3 a.m. That is why they are governed rather than optional.
The testable floor
WCAG 2.2 Level AA is the conformance target, with selected AAA criteria adopted where the clinical case is strong. It is a floor, not the definition — but it is the part that can be measured, so it is the part this system enforces mechanically.
| Requirement | Level | How this system meets it |
|---|---|---|
| Non-text contrast — controls and state | AA · 1.4.11 | --input and --ring gated at ≥ 3:1 against background,
card and muted. This is the criterion stock shadcn fails. |
| Contrast (minimum) | AA · 1.4.3 | 40 token pairs computed in CI, both themes. See Colour. |
| Use of colour | A · 1.4.1 | Every alarm priority pairs hue with a distinct glyph and a distinct word. Verified by rendering greyscale. |
| Focus visible / appearance | AA · 2.4.7, 2.4.13 | Governed token. outline: none without replacement fails review. |
| Target size (minimum) | AA · 2.5.8 | Exceeded — this system's floor is physical (10 mm, 12 mm gloved), not the 24 px CSS minimum. See Scaling. |
| Reflow · text spacing | AA · 1.4.10, 1.4.12 | Operable at 320 px and 200 % zoom with no horizontal scrolling; sticky headers disabled at high zoom. |
| Status messages | AA · 4.1.3 | Alarm priority determines role="alert" versus role="status"
inside the component, not at the call site. |
| Three flashes | A · 2.3.1 | Flashing is prohibited outright as an urgency signal, not merely rate-limited. |
| Contrast (enhanced) | AAA · 1.4.6 | Adopted for body text where achievable; alarm fills sit at AA by necessity and the trade is documented. |
| Three flashes (no exception) | AAA · 2.3.2 | Adopted. No exception is available in a clinical display. |
The IEC 60601-1-8 alarm hues cannot reach 7:1 without ceasing to read as alarm colours. Critical measures 5.64:1 and confirmation 6.07:1 — both AA. This is a deliberate, documented trade between two safety requirements, and it belongs in your accessibility conformance report as such rather than being quietly omitted. See Colour.
Beyond conformance
The criteria above are necessary and nowhere near sufficient. A screen can pass every automated check and still be unusable at 3 a.m. These are the requirements this system adds:
- Legibility at the real viewing distance, not at the designer's. A 12 px label passing contrast at 60 cm is invisible on a handover board at 4 m. Automated tools cannot see this; the scale factor exists because of it.
- Operable one-handed. The other hand is holding a probe, a phone or a patient. Nothing critical requires two-handed interaction or a modifier chord.
- Operable gloved. Double-gloved capacitive touch is less precise and sometimes fails outright. Physical target floors, not pixel minimums.
- Readable under interruption. A clinician returning after ninety seconds must be able to re-orient without re-reading the screen — which is what the persistent patient header and the idle re-confirmation are for.
- Survives greyscale. Patient records get printed. Any screen whose meaning collapses in monochrome has encoded something in colour alone.
- Plain, translatable language. Short sentences, no idiom, no negation stacks. Helps non-native readers, cognitive load, and translation quality simultaneously.
Assistive technology in clinical settings
The mix differs from consumer software and the difference changes priorities.
| Technology | Prevalence here | Implication |
|---|---|---|
| OS zoom and magnification | Very common | Reflow at 200 % is a daily requirement, not an edge case. Test it first. |
| OS high-contrast / forced-colours modes | Common | Alarm hues must survive forced-colours; never rely on a background image or gradient to carry priority. |
| Keyboard-only operation | Common | Gloved or occupied hands make the pointer slow. Every workflow completes on keyboard. |
| Screen readers | Less common, never zero | Still fully supported — and the discipline it imposes (real labels, real tables, live regions) improves the interface for everyone. |
| Switch access, voice | Rare | Supported via standard semantics. Never build a custom control where a native one exists. |
How it is tested
- Automated, every commit. Contrast, token governance, markup integrity, label association, ARIA reference validity. Fast, reproducible — and it finds only the minority of real problems.
- Manual, every component. Keyboard traversal, focus order and visibility, greyscale render, 200 % zoom, 320 px reflow, forced-colours mode.
- With users, every release. The only method that finds the problems that matter. Recruit for the range in the table above rather than for convenience — and see the validation roadmap for what is not yet done.
Hue, glyph and the word "Urgent". Remove any two and the priority still arrives.
Priority carried by the fill alone. Gone in greyscale, gone in forced-colours, gone for a colour-vision deficiency, gone when printed.
Outcomes of use
What accessibility contributes to, in the terms of Usability & context of use. Accessibility is its own outcome of use, and it also widens the population for whom the other three hold at all.
- Effectiveness — the same accuracy and completeness for a clinician with a colour vision deficiency, at 200 % zoom, or on keyboard only, as for anyone else.
- Efficiency — no additional time or effort tax for using an alternative input or an assistive technology. A workflow that is technically possible but three times slower has not been made accessible.
- Satisfaction — not having to work around the tool in front of colleagues. Perceived competence is part of satisfaction, and interfaces that force visible workarounds erode it.
Do's and don'ts
Checked in greyscale as routine. The words carry the meaning when the hue cannot.
Fill only. In greyscale the two priorities are two similar greys, and the printout in the notes carries nothing.
At 200 % the dialog scrolls inside itself and the actions remain reachable.
Fixed height with the actions clipped out of view. The clinician can neither cancel nor confirm.
Clinical safety notes
Trace these in your risk file (ISO 14971) and usability engineering file (IEC 62366-1). Accessibility failures in clinical software present as use error, not as inconvenience.
- Meaning never carried by one channel. Mitigates: missed priority in greyscale, forced-colours, or with a colour vision deficiency.
- Focus indicator governed and never removable. Mitigates: a keyboard or switch user activating the wrong control.
- Physical target floors, not pixel minimums. Mitigates: mis-selection when gloved, in motion, or with tremor.
- Reflow to 320 px and 200 % zoom. Mitigates: content lost off-screen for the many clinicians who run magnified displays.
- Flashing prohibited outright. Mitigates: photosensitive seizure, and the attentional cost of flicker in a busy bay.
- Keyboard completion of every workflow. Mitigates: a clinician with one free hand being unable to act.
- Recruit testing for the full capability range. Mitigates: conformance that passes automation and fails people.
Related
- Usability & context of use — accessibility as one of four outcomes.
- Colour — contrast evidence and the alarm-hue trade.
- Typography — the 12 px floor and reading at distance.
- Scaling & displays — physical target sizes.
- Validation roadmap — what has not yet been tested with users.