Accessibility in clinical software
Accessibility in clinical systems is often treated as a compliance exercise aimed at a small group of users. In practice, the changes it asks for are the same changes that make a dense screen usable at three in the morning on a monitor nobody has cleaned.
Density is the reason, not the excuse
The standard objection is that these screens are too information-dense to accommodate larger text, clearer focus states and generous targets. The density is real. It is also exactly why the margins are thin: on a sparse page a reader can recover from a poor contrast ratio by context, and on a dense one they cannot.
Nearly every accessibility requirement has a plain operational reading. Contrast is legibility under bad lighting. Focus visibility is knowing where a keystroke will land. Target size is accuracy for someone standing rather than seated. Reflow is a screen that survives being shared on half a monitor.
Contrast and the grey-on-grey habit
Secondary text drifts pale because pale reads as calm in a design review conducted on a good monitor in a lit room. Metadata, timestamps, units and disabled controls are the usual casualties, and they are frequently the exact strings a reader needs.
The workable discipline is to fix a small set of ink values with measured ratios and use only those, rather than choosing a grey per component. Quietness should come from size, weight and position, not from fading text toward the background.
Keyboard order and focus
Anyone entering a lot of structured data works from the keyboard, so tab order is not an accessibility accommodation but the primary interaction model for a large share of the actual use. Where it follows the visual order it is invisible; where it does not, people learn a sequence of keystrokes by rote and enter data into whatever the sequence lands on.
Focus must be visible at all times and must be moved deliberately when content changes. A dialog that opens without taking focus, or closes without returning it, strands keyboard users in a place they cannot see.
Zoom, reflow and colour
Screens should survive being enlarged. A layout that only works at one width will be used at other widths anyway, on split screens, projected displays and small panels, and its failure there is a general defect rather than a special case.
Nothing should be encoded in colour alone. A row distinguished only by tint is invisible in monochrome printing, at low contrast, and to a substantial share of readers. Adding a symbol or a word beside the colour costs a few pixels and removes the dependency entirely.
Tables, dialogs and assistive technology
Dense applications lean on tables and modals, which are the two structures most often built in a way that is opaque to assistive technology. A table needs real header cells associated with their rows and columns, or a screen reader announces a field of numbers with no way to say what any of them is.
A dialog needs a name, a defined boundary, and focus behaviour that keeps the reader inside it while it is open. These are not exotic requirements; they are the difference between a screen that can be operated without sight and one that cannot be operated at all.