What is the difference between inclusive design and accessibility?

Accessibility is a measurable property of the result, checked against a standard. Inclusive design is a method for getting there, and it covers ground no standard measures — language, literacy, connection speed, cost, situation. A product can pass WCAG and still be unusable for the people it was meant to serve.

Is inclusive design only about disability?

No. Permanent disability is part of it, alongside temporary and situational constraints — a broken arm, bright sunlight, one hand on a phone, a slow connection, a second language. Microsoft's inclusive design work popularised that framing, and it is useful because it turns a minority concern into something affecting everybody at some point.

Does inclusive design cost more?

Early, no. It is mostly a set of decisions rather than extra work: which fields exist, what the error says, whether the control is reachable by keyboard. Late, yes, and substantially — retrofitting is where the cost lives, which is an argument for the timing rather than against the practice.

What is the curb-cut effect?

Dropped kerbs were built for wheelchair users and turned out to help anyone with a pushchair, a suitcase or a delivery trolley. The pattern repeats in software: captions serve people in noisy rooms, keyboard shortcuts serve power users, and clear error messages serve everyone who is in a hurry.

Inclusive Design

Designing for the full range of human variation, treating exclusion as a design outcome rather than an edge case.

Design Disciplines

Inclusive design treats exclusion as something a design decision produces, rather than as an edge case to handle later.

It is not the same thing as accessibility, and the difference is practical. Accessibility is a property of the result, measurable against WCAG. Inclusive design is a method, and it covers ground no standard measures.

A product can pass level AA and still be unusable by the people it was built for.

The range is wider than disability

The framing popularised by Microsoft's work is permanent, temporary, situational.

Someone with one arm. Someone with a broken arm. Someone holding a baby.

Someone blind. Someone with cataracts. Someone outside in bright sun.

The value of this framing is that it moves the conversation from a minority to a majority. Everybody is situationally impaired regularly, and a product designed only for the ideal case fails all three groups at once.

What no standard measures

Language and reading level. A form that passes every criterion and is written in policy language excludes people more effectively than a contrast failure.

Connection and device. A product tested on a fast laptop and used on a mid-range phone on hotel wifi is a different product.

Cost of error. Who pays when this goes wrong, and can they recover? The people least able to absorb a mistake are the ones a design should protect hardest.

Assumptions in the data model. Name fields, gender fields, address formats, phone formats. These are design decisions with real exclusion attached and no success criterion covering them.

Who is in the research. The most consequential inclusion decision is who gets asked. Six interviews with people who all resemble the team produces a confident answer about a narrow group.

The curb-cut effect

Dropped kerbs were built for wheelchair users. They turned out to serve pushchairs, suitcases, delivery trolleys and anybody tired.

The pattern repeats in software reliably enough to plan around. Captions serve people in noisy rooms and people watching without sound. Keyboard operability serves power users who never touch a mouse. A clear error message serves everybody in a hurry.

This is the argument that works internally, because it is not a moral one. Designing for the constraint usually produces a better product for the unconstrained case too.

In B2B, where it is a commercial constraint

The audience is captive. Nobody chooses the software their employer bought, so an exclusion is not a lost sale — it is somebody unable to do their job.

And the buyer increasingly asks. A VPAT request in procurement is an inclusive design question arriving in the form of a document, usually after the product is built and the decisions are expensive to revisit.

Where teams get it wrong

Treating it as accessibility with better branding. One is a method, the other a measurable property.
Doing it at the end. The decisions that exclude are made early and cheaply.
Research with people like the team. A confident answer about a narrow group.
Personas that are all capable. If none of them has a constraint, none of the designs will.
Waiting for the standard to require it. Most of what matters here is not in any standard.

Learn more

UI/UX design for B2B SaaS →Accessibility as a B2B SaaS deal blocker →