Accessibility Is a Reliability Problem, Not a Design Preference
A product can have excellent uptime and still be unavailable to the person trying to use it.
That sounds obvious when written down. Yet accessibility is still routinely treated as a finishing layer: a bit of polish after the proper engineering has happened, perhaps somewhere between choosing border radii and arguing about whether a button should be teal. It is often described as a design preference, or worse, a compliance chore with the emotional pull of a fire-door inspection.
I think that framing is fundamentally wrong.
Accessibility is a reliability problem. If a customer cannot complete a key task because a form will not work with their keyboard, a screen reader cannot identify its controls, or a timeout expires before they can respond, the service has failed. It does not much matter that the underlying servers were healthy, the CSS was fashionable, and every dashboard was glowing a reassuring shade of green.
For disabled people, this is not an abstract distinction. It is the difference between independently getting something done and needing to find a workaround, ask for help, abandon the task, or spend the rest of the afternoon crossly negotiating with an interface that has mistaken friction for sophistication.
Reliability means completing the task
Engineering teams tend to define reliability in operational terms: availability, error rates, latency, recovery time, data integrity. Those matter. A system that returns HTTP 200 while quietly corrupting data is plainly not reliable, however cheerful its monitoring may be.
The same logic applies at the interface.
A useful question is: can a person reliably complete the intended task using the way they need to interact with the product?
That includes, among other things:
- navigating without a mouse
- understanding controls through a screen reader
- reading content at high zoom or with altered text spacing
- operating controls through voice input, switch devices, or other alternative input
- receiving and correcting useful form errors
- having enough time to complete a session or transaction
- coping when movement, concentration, vision, hearing, pain, fatigue, or dexterity varies from one day to the next
These are not edge cases parked in a distant annex of the user base. Human capability is variable. It varies between people, certainly, but also within one person over time. Someone may use a keyboard because of a permanent mobility impairment, a broken wrist, a temporary injury, a laptop trackpad that has chosen industrial action, or simply because keyboards are quicker.
A reliable product accommodates meaningful variation without making the user perform a small ritual of technical archaeology first.
The interface is part of the system boundary
In embedded and IoT work, it is tempting to draw a neat boundary around the device, firmware, network, and cloud service. Then a sensor loses connectivity because it has been installed behind enough metalwork to make a Faraday cage blush, and the boundary turns out to have been rather optimistic.
Software interfaces have the same problem. The system boundary does not end at the API response. It ends when the person has achieved the thing they came to do.
Consider an online booking form. The backend might correctly reserve a slot, validate availability, and send a confirmation. But if the date picker cannot be operated from a keyboard, a user who does not use a mouse cannot make the booking. From their perspective, the booking service is unavailable.
Or consider a form that displays validation errors as red text beside fields. A screen reader user may not be told that the error message has appeared. The server has returned a perfectly sensible validation response; the interface has failed to communicate the changed state. The user may submit the same invalid form repeatedly, which is less a user error than a design that has hidden the answer while demanding it.
There are concrete technical mechanisms behind these failures. Semantic HTML gives assistive technologies useful information about headings, buttons, labels, lists, and form relationships. When developers replace a native <button> with a clickable <div>, they often lose keyboard behaviour, focus handling, and the expected role unless they rebuild them deliberately. Rebuilding them is possible, but it is rather like deciding to manufacture your own wheel because the supplied one looked insufficiently bespoke.
Native controls are not glamorous. Neither are working brakes.
Failure modes are usually predictable
Accessibility failures are often presented as mysterious compatibility problems, as though assistive technology is an unpredictable weather system. There can be complex interactions, particularly in large applications, but many failures are straightforward and foreseeable.
Focus disappears after a modal opens. Keyboard users cannot tell where they are.
A menu is visually hidden but remains reachable by tabbing. People move through controls they cannot see.
A custom checkbox responds to clicks but not Space. One input method works; another has been quietly excluded.
An error summary appears at the top of a long form, but focus stays at the submit button. The user is not taken to the information needed to recover.
A live update announces every small change and turns a screen reader into an excitable sports commentator. Or nothing is announced at all. Both are failures of state communication, merely at opposite ends of the volume control.
These are reliability defects because they interrupt, misdirect, or prevent task completion. They deserve the same disciplined treatment as any other defect: clear reproduction steps, severity based on user impact, ownership, regression tests, and a route to production that does not depend on someone remembering to care on a Thursday afternoon.
Test the journeys that matter
Automated accessibility checks are useful. They can identify missing labels, invalid attributes, poor colour contrast in many cases, and other detectable problems. They are a sensible part of a delivery pipeline.
They are also nowhere near enough.
Automation cannot reliably determine whether focus order makes sense, whether a form’s instructions are comprehensible, whether a modal traps focus appropriately, or whether a user can recover from an error without becoming lost. It cannot tell you whether the interaction model respects the way people actually work. A clean automated report can be comforting in the same way as a smoke alarm with no battery: technically present, strategically disappointing.
Teams should test critical user journeys manually with a keyboard, at minimum. Start at the top of the page, use Tab, Shift+Tab, Enter, Space, arrow keys where appropriate, and Escape. Watch where focus goes. Check whether every control has a visible focus indicator. Complete the task without reaching for a mouse.
Then test with representative assistive technologies where possible, and involve disabled users in research and usability testing. This is not because disabled people are a specialist quality-assurance department. It is because the people most affected by a failure are often best placed to reveal it. Pay them properly for that expertise and make sure their findings lead to decisions, rather than a warmly worded slide deck that vanishes into a shared drive.
Design choices have operational consequences
Treating accessibility as reliability changes how teams make decisions.
A product owner sees an inaccessible checkout as lost completed transactions, not merely an imperfect experience. An engineering manager sees keyboard and screen-reader testing as coverage for critical paths. A designer sees clear focus states and error recovery as interaction requirements, not visual compromises. Support teams see repeated reports of “the site will not let me” as incident signals worth investigating.
It also improves the product for plenty of people who do not identify as disabled. Clear labels reduce uncertainty. Sensible headings make scanning easier. Keyboard operation helps power users. Captions help in noisy environments. Generous time limits help anyone interrupted by life, which has a habit of ignoring sprint plans.
The aim is not to make every interface identical, nor to reduce design to a grey puddle of lowest-common-denominator controls. Good accessibility leaves room for character, brand, and invention. It simply requires that the inventive part still works when a person navigates differently, reads differently, hears differently, or has less energy to spend wrestling the controls.
When a service prevents someone from doing what it promised, we should call that what it is: a reliability problem. Once we do, accessibility stops being optional decoration and becomes part of the engineering standard it should have been all along.