Estimated reading time: 4-5 minutes
I’ve lost count of the times I’ve seen a project stall as soon accessibility compliance is brought up, or tested something that’s already live to find it littered with non-compliance. It’s often accompanied by a collective sigh and the assumption that we’re about to navigate an endless list of unique, unpredictable, expensive requests.
This fear of the unknown is one of the biggest barriers to inclusion – and it’s built on a misunderstanding.
Accessibility needs fall into predictable categories because they arise from the interaction between a limited set of human needs and a limited set of digital or physical barriers. The specific assistive technology or exact diagnosis might vary, but the underlying need rarely does.
The constants of human interaction
Every customer needs to perceive information to be able to act on it. This creates 4 fundamental areas of need:
- Visual
- Auditory
- Motor
- Cognitive
Your customers needs to be able to see or hear the information, make sense of it and interact with it (click buttons, complete tasks).
Users with impairments aren’t fundamentally different in this basic need, they just adapt their approach to suit their circumstances.
Visual need examples
- Example need: I need to get information without relying on my sight.
- Example barriers: An image without a text alternative, a link that says “click here” or a button that announces as “button”
- Example solutions: Provide text equivalents, ensure your code is compatible with screen readers, use descriptive link and button text
Auditory need examples
- Example need: I need to get information without relying on my hearing.
- Example barriers: A video without captions or transcript, sound only notifications
- Example solutions: Provide captions, transcripts and visual alerts
Motor need examples
- Example need: I need to act without precise mouse or touch gestures, I need step-free access to buildings
- Example barriers: Small links and buttons, steps, steep ramps
- Example solutions: Keyboard accessibility, large targets, support for voice controlled technology, appropriately angled ramps
Cognitive need examples
- Example need: I need to process information without relying on memory, speed or complicated language
- Example barriers: A timed task, dense jargon, high reading age content
- Example solutions: Plain language, clear structure, extended or no time limits, consistent navigation
While someone might use a screen reader, a braille display, or a voice assistant, the underpinning need is still to perceive and interact with the content. The solutions are constant and predictable.
That is not to say there aren’t also more complex needs to solve for, but if you solve for these from the start your development time can be dedicated to the genuinely complex challenges rather than the simple ones.
Multifunctional tools
Captions were created originally created to allow D/deaf and hard-of-hearing people to follow video content. But they also help someone with auditory processing disorder, someone in a noisy environment, someone whose language isn’t the one being spoken, and someone who simply prefers reading to listening.
Many assistive technologies provide solutions that serve multiple scenarios and impairments. Including support for them prevents access issues for a wide range of customers before any specifics have been considered.
What’s getting in the way?
Often project teams are:
- Confusing the tool with the need. A request for “JAWS compatibility” sounds specific and daunting. The underlying customer need is for a screen reader to read text for them, which is a basic visual requirement. If your code is built to web standards, a large portion of the work to become screen reader compatible is covered.
- Tackle needs one at a time, in crisis mode. Every request feels novel because there’s no organisational memory and it often isn’t addressed until projects are live and customers are feeding back problems. If teams had seen the same need five times before across different projects, they would have recognised it as a pattern and adjusted for it during the build.
- Working without guidance. No one has shown them the four-domain model above, and they likely have never had accessibility training. They’re trying to memorise a complex list of conditions rather than understanding the system as a whole.
What this means in practice
So if all this is true, and needs are predictable, then:
- You can plan. You know that any video will need captions and a transcript, you know interactive elements need keyboard support, and so on.
- You can budget. Predictable needs mean predictable costs, and building support in from the start is always more cost effective than trying to retrofit it later.
- You can test proactively. You don’t need to wait for a disabled person to struggle. You can test against the known domains yourself: can I do everything by keyboard? Do the instructions make sense using a screen reader? Is there a text equivalent for every non-text element?
- You can stop starting from scratch. The patterns are known. They can be built into your design system, your templates, your acceptance criteria. This is the whole point of the Certainty Principles.
A final thought
When I’m auditing sites and digital tools, the problems I encounter are rarely unique. When I myself am excluded from events it’s always for the same reasons.
These issues are almost always problems that have been created before, solved before and been missed because the knowledge wasn’t captured.
The predictability of accessibility needs is liberating, not constraining. It means we don’t have to wait for someone to tell us they were excluded to know what to action, we can be proactive and accommodate for the known, constant range of human interaction needs.
Next: We explore why the concept of certainty is such an important aspect of creating inclusive experiences.
