Accessibility — abbreviated a11y (eleven letters between the first and last) — is the practice of making digital products usable by everyone, including people with disabilities. Roughly one in six people in the world has a disability significant enough to affect how they use the web. If you test software for a living, accessibility is a core part of your job, not an optional polish task.
The disabilities that matter for web testing
Accessibility covers a wide range of conditions, but for testers four broad categories cover most of the work:
- Visual — total blindness, low vision, and colour-blindness. Affects roughly 4–5% of the global population. Users may rely on screen readers, magnifiers, or extreme zoom levels.
- Auditory — deafness or significant hearing loss. Affects roughly 5%. Users need captions on any audio or video content.
- Motor — limited use of hands, tremors, single-hand interaction, or use of switches and assistive devices. Affects roughly 2–3%. Users may rely on keyboards, voice control, or specialised hardware in place of a mouse.
- Cognitive — dyslexia, ADHD, autism spectrum, learning differences, memory loss. Affects up to 10% in some form. Users benefit from clear language, predictable interfaces, and reduced sensory overload.
These categories overlap heavily — a single user may have low vision and a tremor — and the design choices that help one group typically help every other group too.
The numbers
Approximate share of population with disabilities affecting web use
The headline figure is 1.3 billion people worldwide. For any product with paying users, ignoring 16% of the market is the kind of business decision a board would not knowingly approve — and yet it is exactly what an inaccessible website does.
The legal pressure is real and growing
Accessibility used to be a moral argument; in the last decade it has become a legal one. The ADA (US) has been used to sue thousands of websites — a 2019 Supreme Court ruling (Robles v. Domino's) held that a blind user could sue a major retailer because its site was unusable with a screen reader. The EAA (EU) requires private-sector products to meet accessibility standards by June 2025. The Equality Act 2010 (UK) makes it unlawful to discriminate digitally against disabled users. The trend is consistent: digital accessibility is now a compliance requirement, not an optional kindness.
The business case nobody tells you
Even setting aside legality, accessible products tend to win commercially:
- Better SEO. Search engines parse the same DOM that screen readers do. Proper headings, alt text, and semantic markup help search ranking the same way they help blind users.
- Wider reach. Accessibility opens your product to the 16% directly affected — and to the much larger group of older users, users in noisy or sunlit environments, users on slow connections, and users with temporary impairments (a broken arm, a cold).
- Lower churn. Users who can't complete a flow leave silently. They rarely report the bug; they simply switch to a competitor whose product worked.
- Engineering quality. The code patterns that produce accessible UI — semantic HTML, predictable focus order, clear state changes — also produce more maintainable, more testable code overall.
The curb-cut effect
The strongest argument for accessibility is that it benefits everyone, not just disabled users. The classic example is the curb cut — the small ramp where the pavement meets the road, originally added for wheelchair users, now used daily by anyone with a stroller, a suitcase, a delivery trolley, or a bike. The same effect runs through digital design: video captions help users in noisy cafés, keyboard navigation helps power users, high colour contrast helps anyone in direct sunlight, and clear language helps non-native speakers. Accessible design is good design.
A real example: the inaccessible checkout
A UK retailer reviewed its analytics and noticed an unusually high cart-abandonment rate from users on iOS Safari with VoiceOver enabled. A volunteer test with VoiceOver revealed why: the "Place order" button was a styled <div> with a click handler — visually a button, semantically invisible to screen readers. Customers who could not see the screen could fill the cart, enter their address, and reach the final step — and then could not check out, because the action button literally did not exist for them. The fix took an hour. It restored an estimated 15% of the company's blind and low-vision customers, who had been silently turning away for months.
That single bug is a microcosm of why accessibility testing matters: invisible to sighted users, devastating for affected users, cheap to fix once caught.
⚠️ Common mistakes
- Treating accessibility as a final-sprint polish task. Retrofitting accessibility into a finished product is hard and expensive. Designing and testing for it from the start is cheap. The sooner a tester raises a11y concerns in refinement, the lower the cost.
- Assuming you have no disabled users. They are there. They simply do not show up in your analytics, because they cannot complete the flows that fire your "purchase complete" event. Absence of data is not data of absence.
- Confusing automated tools with full coverage. Automated scanners catch about 30–40% of accessibility issues. The rest — including most of the worst ones, like keyboard traps and ambiguous labels — require manual testing with real assistive technology.
🎯 Practice task
Spend 25 minutes building empathy for accessibility before learning the techniques.
- Pick a website you use regularly. With a stopwatch, complete one common task using only the keyboard — no mouse. Note where you got stuck.
- Use a colour-blindness simulator (built into Chrome DevTools — Rendering tab → Emulate vision deficiencies). Switch to "Protanopia" and reload the same page. Are status colours still distinguishable?
- Open Chrome DevTools, drop the zoom level to 50% and then back up to 200%. Does the layout remain usable at 200%? Where does it break?
- Write a one-paragraph note to your team summarising what you found and the single highest-impact change that would improve accessibility for the most users. This becomes the input for the next three lessons in this chapter.