A few months ago I ran an accessibility audit on a UK government website. Not a quick scan but a proper audit. Screen reader testing, keyboard-only navigation, colour contrast checks, reading level. What the audit surfaces is not always catastrophic. But it is always honest: journeys built perfectly for the assumed user that break, quietly and invisibly, for everyone else.
Two weeks ago I was in a government accessibility workshop — designers, developers, and service owners across UK public sector, all in the same space around the same question: are the services we are building actually usable by everyone who needs them?
That question is the one every product team should be sitting with.
I work on the National Data Library, public digital infrastructure for the United Kingdom. Every service we build is legally required to meet WCAG 2.2 AA accessibility standards before it goes live. Not optional. Not a version-two feature. The baseline. A service that excludes people based on ability is not a complete service. In UK law, it is not compliant.
That legal standard has changed how I design. Not because of the compliance requirement. Because of what you find when you take it seriously.
The broken hand problem
Here is something worth sitting with.
At some point in your life, you will experience an accessibility barrier.
Maybe you have broken a wrist. Maybe you have tried to fill in a form on your phone with one hand while holding a child with the other. Maybe you have tried to read a notification in direct sunlight, and the contrast made it impossible. Maybe you are fifty-eight, and small text is starting to be a problem.
These are not edge cases. They are normal human experiences.
The difference between a “disabled person” and an “abled person” is often not permanent. It is situational. It is temporary. It changes depending on the day.
According to the World Health Organization, 1.3 billion people, 16% of the global population, experience a significant disability. According to the UN, 80% of people with disabilities live in developing countries. In Africa, the WHO Regional Office estimates around 80 million people are living with a disability.
These are not small numbers. And the official African figures are almost certainly an undercount, i.e., data collection is inconsistent, many conditions go undiagnosed, and diagnostic infrastructure varies significantly across the continent.
What Africa needs to hear
I have built products used across twenty African countries. What that work taught me, repeatedly, is that designing for the real user in the real context is not a specialised concern. It is the job.
In Africa, there is no WCAG enforcement. No legal standard mandating accessibility compliance. That absence does not mean the need is smaller. It means the gap is larger.
When you build a product that excludes users with slower connections, older devices, or physical limitations, you are not cutting a corner on a minority use case. You are cutting off a significant portion of the market you are trying to reach.
These are not edge cases. They are your users.
What the West gets right
The UK government’s position is instructive. Every public service must be accessible. Not suggested. Required. The argument is simple: a government service that excludes citizens based on ability is not a functioning government service.
That principle has teeth. Teams audit their products. They publish accessibility statements. They address issues that are raised. It is not perfect, and accessibility remains an ongoing challenge even in well-resourced environments but the direction is right. Accessibility is treated as a first principle, not a final polish.
The lesson for African businesses is not “copy the UK framework”. The lesson is this: the organisations that get this right do not wait for a law. They do it because they understand who their users actually are.
The reframe
Accessibility is usually positioned as a cost. An extra test, an extra resource, and additional complexity that slows a team down.
Here is the more useful frame.
When you design with accessibility in mind genuinely, from the start, you make better decisions overall. You think more carefully about your actual user. You catch problems before they become patterns baked into your architecture.
Accessibility is not the price you pay for inclusion. It is the standard that makes your product work for the people who actually exist, not the idealised user you imagined when you started building.
Build for the real person. Not the hypothetical one.