The classic example is a dropped kerb. It was fought for by wheelchair users, and it turns out to help anyone with a pram, a suitcase, a delivery trolley, or a sore knee. The same thing happens in software: the captions added for deaf viewers get switched on by everyone watching with the sound off, and the high-contrast text built for low vision is easier to read on a phone in bright sun. Design for the people at the edges and you quietly raise the floor for the middle.

The quick version

  • Accessibility is the outcome, can a disabled person actually use this? Inclusive design is the practice that gets you there by considering the full range of ability up front.
  • The shared standard is WCAG (Web Content Accessibility Guidelines), organised around four principles, content must be Perceivable, Operable, Understandable, Robust. Most laws and contracts ask for level AA.
  • Roughly 1 in 6 people worldwide lives with a significant disability (WHO, 2022), and most are temporary or situational at some point, a broken arm, bright sunlight, holding a baby.
  • It is far cheaper to build in than to bolt on. The move is to make accessibility a definition-of-done habit, not a pre-launch panic.

The idea in depth

It helps to separate two words that often get used as if they were one. Accessibility is a property of the finished thing: can a person using a screen reader, a keyboard with no mouse, a magnifier, or voice control complete the task? Inclusive design is the design practice, the choices you make along the way, that makes that outcome likely instead of accidental. You can stumble into accessibility, but you rarely stumble into it twice. Inclusive design is how you make it repeatable.

WCAG is the shared language, learn its four words

When people say a product is "accessible," what they usually mean is that it meets the Web Content Accessibility Guidelines, the W3C standard now at version 2.2 (published October 2023). The whole sprawling document hangs off four plain principles, sometimes shortened to POUR: content should be Perceivable (you can sense it, text alternatives for images, captions for audio), Operable (you can drive it, by keyboard, not just mouse), Understandable (it behaves predictably and explains its errors), and Robust (it works with assistive technology like screen readers). Each guideline comes at three conformance levels: A, AA, and AAA. AA is the practical target almost everyone aims for, and the one most procurement contracts and accessibility laws point at.

So the move is: stop treating accessibility as a vague intention and adopt WCAG 2.2 AA as your written bar. Naming a standard turns an argument ("is this accessible enough?") into a checklist a developer or designer can actually answer. Put the four POUR words on the wall and ask them of every new screen: can people perceive it, operate it, understand it, and will it survive a screen reader?

One limitation worth being blunt about: passing an automated WCAG scan is necessary but nowhere near sufficient. Tools catch missing alt text and poor colour contrast, but they cannot tell you whether a screen-reader user can actually finish checkout. The annual WebAIM Million survey found that even with automated testing, 95.9% of the top one million home pages had detectable WCAG failures (February 2026 analysis), and automated tools only ever catch a minority of real-world barriers. Conformance is the floor, not proof of a good experience.

flowchart TD
    A(["WCAG: is it usable for everyone?"]) --> P(["Perceivable
can they sense it?"])
    A --> O(["Operable
can they drive it by keyboard?"])
    A --> U(["Understandable
does it behave predictably?"])
    A --> R(["Robust
does it work with a screen reader?"])
The four POUR principles behind every WCAG guideline. Leaders Loop

The curb-cut effect, designing for one extends to many

The strongest business argument for this work is not charity, it is reach. The curb-cut effect takes its name from those dropped kerbs, which disability activists, the Berkeley "Rolling Quads" led by Ed Roberts, fought to install in the early 1970s, and which the 1990 Americans with Disabilities Act later made universal. They were built for wheelchair users and ended up serving parents, travellers, cyclists and couriers. Microsoft's Inclusive Design toolkit turned this into a working principle, "solve for one, extend to many", paired with a persona spectrum that reframes disability as something most of us pass through. A limitation can be permanent (one arm), temporary (a broken wrist), or situational (a parent holding a baby). Design a one-handed flow for the first and you have also served the other two, a far larger market than the permanent group alone.

The practical move: when you scope a feature, name the permanent, temporary and situational versions of the constraint you are designing around. "Voice control for people who can't use their hands" becomes "...also useful while driving, cooking, or carrying shopping." That reframing moves accessibility out of the compliance budget and into the growth conversation, where it competes for attention on its merits. The W3C's own business case for digital accessibility collects the evidence that this widens market reach, strengthens brand, and lowers legal risk.

Worth keeping honest, though: the curb-cut effect is a real and well-documented pattern, but it is not a guarantee. Some accommodations genuinely only help the group they were built for, and selling every accessibility fix as a universal win can quietly imply that disabled people's needs only matter when they happen to benefit everyone else. They matter regardless. Use the curb-cut argument to win budget, not to decide what's worth doing.

A worked example

The figures and team below are illustrative, used to show the method, not a real company's numbers.

Picture a mid-sized insurer whose online claims form keeps getting abandoned. A product manager, Dani, has a launch in three weeks and treats accessibility as a final-week checkbox. The team runs an automated scan two days before go-live; it flags 40 contrast and alt-text issues, the developers grind through them, the scan goes green, and everyone relaxes.

Then a colleague who is blind tries the form with a screen reader and cannot submit it. The "date of incident" picker is mouse-only. The error messages flash red but are never announced, so she has no idea why submission fails. None of this showed up on the scan, because the scan can see a missing label but cannot see a broken journey. The fix now means re-engineering the date field and the error handling, work that lands after launch, as an emergency patch.

Replay it the inclusive-design way. At kickoff, Dani writes "WCAG 2.2 AA, keyboard-only and screen-reader paths tested" into the definition of done. The team sketches the persona spectrum for a claims form: someone with a tremor (permanent), someone with a sprained wrist filing a claim about that very injury (temporary), someone filling it in one-handed on a train (situational). They build the date field as a plain typed input with a calendar option, wire errors to announce themselves, and run a fifteen-minute keyboard-only test at the end of each sprint. The launch slips by nothing. The same changes, clearer errors, a faster date field, fewer fiddly controls, measurably cut abandonment for everyone, not only the screen-reader users. That is the curb-cut effect paying rent.

The difference between the two runs was not budget or talent. It was when the question got asked.

Accessibility you bolt on at the end is a patch. Accessibility you build in from the start is just good design.

flowchart LR
    K(["Kickoff:
set WCAG AA as
definition of done"]) --> D(["Design:
sketch the
persona spectrum"])
    D --> B(["Build:
keyboard + screen-reader
paths, not just mouse"])
    B --> T(["Each sprint:
15-min keyboard test
+ automated scan"])
    T --> S(["Ship:
and test with
real disabled users"])
    S -.-> D
Accessibility as a repeating habit across the build, not a pre-launch scramble. Leaders Loop

Frequently asked questions

Isn't accessibility only relevant for a small minority of users?

No. The WHO estimates that about 1.3 billion people, roughly 1 in 6 worldwide, live with a significant disability (Global report on health equity for persons with disabilities, 2022). Add temporary and situational limitations and the share of users who benefit at some point is closer to "most of us." Designing for the edges is designing for a large, often overlooked slice of your actual market.

Can't we just run an automated checker and call it done?

Automated tools are useful and you should run them, but they only catch a fraction of barriers, mostly code-level issues like missing labels or weak contrast. They cannot tell you whether someone can complete a task. The reliable signal is a human one: test the key journeys with a keyboard only, with a screen reader, and ideally with disabled users themselves.

What's the difference between accessibility and inclusive design?

Accessibility is the measurable outcome, does it work for disabled people, usually judged against WCAG. Inclusive design is the broader practice of considering the full spectrum of human ability, identity and circumstance while you design, so accessibility (and a better experience generally) is the natural result rather than a last-minute fix.

Is this a legal obligation or just good practice?

Both, and it varies by jurisdiction. Many countries tie public-sector and commercial websites to a WCAG level (commonly 2.1 or 2.2, level AA) through laws and standards, and the European Accessibility Act has widened these duties. Treat WCAG AA as your baseline, but check the specific rules for your market and sector with a qualified professional rather than relying on a general guide.

We're a small team with no budget, where do we even start?

Start with three free habits: test every screen with the keyboard alone (if you can't reach it without a mouse, neither can many users), check colour contrast, and write meaningful alt text and form labels. Those three cover a large share of common failures and cost nothing but attention.

Related in the Toolkit

Where to go next