Affordance & perceivability
This page exists because the same objection had to be made six times on six component pages before anyone noticed it was one objection. It is written here once so the components can cite it instead of re-deriving it.
A control exists only if every reader who can operate it can perceive that it is there. An affordance available to some readers and not others is not a subtle accessibility shortfall — it is a function that, for those readers, does not exist.
Why it keeps happening
Six component pages in this system independently rejected a recommendation for the same reason: hover-revealed navigation labels, accordion content hidden from find-in-page, hover-revealed grid controls and drag-only reordering, a calendar behind an unlabelled icon, icon-only filters and truncated tags, and locked options whose reason lives in a tooltip.
They recur because each one is genuinely good design for a particular reader — the one using a mouse, on a large screen, who has used the product before. Two properties then let them through review:
- They work perfectly for the person who built them. A designer with a pointer, checking their own work, will find every hover affordance instantly, because they know where it is and their input device reveals it.
- They fail silently. No error, no log, no complaint. The reader does not find the control, concludes the function is absent, and works around it — and the workaround is what gets reported, if anything does.
Neither property is present for most defects. A crash is loud, a wrong number is arguable, a slow query is measurable. This class produces nothing but a clinician quietly doing something the longer way, and nobody ever hears about it.
Who loses what
The abstraction "some users" is too vague to design against. These are the readers this system already commits to, and what each affordance costs them.
| Reader | Loses |
|---|---|
| Anyone on a touch cart or tablet — roughly half the surfaces here | Every hover affordance, in full. Not degraded: absent. |
| A keyboard user | Hover affordances until focus happens to land on them, double-click, drag, and any modifier-key combination they were never told about. |
| A screen-reader user | Anything conveyed by appearance alone, plus the content of a tooltip that carries meaning rather than repeating it. |
| A clinician in gloves | Precision drag, small targets, and anything requiring a steady pointer on a moving cart. |
| Someone who has never used this product | Every undiscoverable affordance — right-click, double-click, long-press, and the icon whose meaning they were expected to already know. |
| Someone returning after ninety seconds away | Nothing, if the interface is honest. Everything, if the state they need is only visible while something is hovered. |
The last row is the one this system weighs most heavily, because re-orientation after an interruption is the normal condition of clinical work rather than an edge case.
The seven, and what replaces them
| Pattern | Why it is tempting | What replaces it |
|---|---|---|
| Hover reveals a label or control | Keeps the interface clean until the reader shows intent | The control is always present. If the screen is too busy with everything visible, the screen has too much on it — that is a layout problem, not a labelling opportunity. |
| Icon with no text | Saves horizontal space; looks tidy in a rail or a toolbar | Text. This system has no icon set at all, and a symbol carrying meaning on a medical device owes a comprehension study — see Contributing. |
| Truncation with the rest in a tooltip | Guarantees the layout never breaks | Wrapping, or a wider container. The tooltip becomes the only copy of the text, and Tooltip forbids a tooltip carrying anything load-bearing. |
| Drag as the only way | Direct and satisfying with a mouse | A single-pointer equivalent alongside it — SC 2.5.7. Move-up and move-down controls, or a value that can be typed. |
| Modifier-key combinations | Powerful for practised users; costs no screen space | Visible controls for the same outcome. An accelerator is fine; an accelerator that is the only route is a secret. |
| Double-click | Familiar from desktop file managers | A single, labelled action. Double-click has no touch equivalent and produces a large action from an ambiguous gesture. |
| Right-click or long-press menus | Keeps common actions close to the object | A labelled menu control. Nothing advertises a context menu, and its touch equivalent competes with scroll — see Touch & gestures. |
When they are fine
None of these is forbidden as an accelerator. The rule is about the primary route, not about every route.
- An accelerator sits on top of a visible path to the same outcome. Ctrl+click to add to a selection is fine when checkboxes are on screen; drag to reorder is fine when move controls exist; a hover preview is fine when the value is already rendered.
- It never carries anything the visible path does not. The moment an accelerator produces something no visible control can, it has stopped being an accelerator and become the only route for the people who know it.
- Hover may add emphasis, never information. Highlighting the row under the pointer helps; revealing the row's actions there does not — the distinction is whether anything is knowable only while hovering.
- A tooltip may repeat or elaborate. Never define, never disambiguate, never carry a unit or an identifier.
Finding it
This class is invisible to every automated check in this system, and to the person who built the screen. It is found by changing who is looking.
- Unplug the mouse. The first pass of the accessibility checklist. Most hover affordances disappear in the first minute.
- Ask what a finger would find. Not "does it work on touch" — assume the pointer does not exist and ask what is discoverable. Hover affordances score zero rather than badly.
- Have someone who has not seen the screen use it. The single most effective test, and the one that catches double-click, right-click and icon-only. Formative evaluation under IEC 62366-1 is where this belongs, and a use error caused by an imperceptible control is a use error like any other.
- Read the implementation for
:hover,dblclick,contextmenuand drag handlers. Each is a candidate, and grepping for them takes a minute.
Outcomes of use
What this contributes to, in the terms of Usability & context of use. These are attributes believed to contribute to an outcome; the outcome itself is settled by observing real use in a specified context, not by this page.
- Effectiveness — a clinician can do the thing the software can do. The failure being prevented is not difficulty but absence: a function that exists in the code and not for the reader.
- Efficiency — worse for the expert with a mouse, who loses a shortcut's exclusivity, and better for everyone who was doing it the long way without knowing there was a short one.
- Satisfaction — mostly invisible. Nobody praises an interface for having controls they can see; they simply stop working around it.
Do's and don'ts
Row actions rendered in the row, always.
Costs a little density and works for every reader on every surface. The density was never the scarce resource.
Row actions that appear on hover.
Absent on a cart, invisible to a keyboard user until focus lands, and perfect for the person who built it.
Move up · Move down
— and dragging also
works
The accelerator sits on top of a visible path. Both readers get the outcome; one gets it faster.
Drag to reorder. No handle, no alternative.
Undiscoverable and drag-only — two failures, and SC 2.5.7 for the second.
The pointer highlights the row it is over.
Emphasis, not information. Nothing is knowable only while hovering.
The pointer reveals the patient's MRN.
The identifier now exists only for readers with a pointer. On a cart the row cannot be checked at all.
Clinical safety notes
Trace these in your usability engineering file (IEC 62366-1). A use error caused by a control the user could not perceive is a use error, and belongs in the file alongside the others rather than in a separate accessibility document.
- Every control is perceivable on every supported surface. Mitigates: a function that exists in the software and not for the clinician using it.
- Nothing is knowable only while hovering. Mitigates: an identifier, unit or state that is simply absent on a touch cart.
- Accelerators sit on top of a visible path, never replace one. Mitigates: capability divided between clinicians who were told and clinicians who were not.
- No text is reachable only through a tooltip. Mitigates: a truncated name, identifier or result with no other copy on screen.
- Drag, double-click, right-click and modifier keys are never the only route. Mitigates: work done the long way, silently, by everyone who did not discover the short one.
Related
- Touch & gestures — how a finger acts on a control, once it has found it. This page is about whether it can be found.
- Interaction & states — hover carries nothing, and what focus does instead.
- Tooltip — the component this rule most often constrains.
- Accessibility checklist — the unplug-the-mouse pass, where most of these surface.
- Accessibility — the success criteria underneath, and why conformance is a floor rather than the goal.
- Contributing — the prohibitions this foundation generalises.