Inclusive Design
Date: 2026-08-17
Designing for the full range of human variation rather than for an average that doesn’t exist. It differs from accessibility in scope — accessibility is a standard to meet, inclusive design is a method for finding the exclusions in the first place.
Inclusive design is a methodology recognising that any design decision includes some people and excludes others, and that the exclusions are discoverable rather than inevitable.
ACCESSIBILITY a set of requirements
for disabled users
→ measurable, testable
→ WCAG
INCLUSIVE DESIGN a process for finding
and removing exclusion
→ broader, harder to
audit
→ produces accessibility
as one output
See: WCAG
The core insight
Disability is a mismatch between a person and their environment, not a property of the person. A step excludes a wheelchair user; a ramp doesn’t. The person is unchanged.
In an interface, you built the environment, which means the exclusions are yours and are fixable.
Permanent, temporary, situational
The framing that makes the commercial case, because it multiplies the affected population enormously:
ABILITY PERMANENT TEMPORARY SITUATIONAL
touch one arm arm injury holding a child
holding shopping
see blind cataract bright sunlight
driving
hear deaf ear infection noisy train
no headphones
speak non-verbal laryngitis quiet office
cognitive learning concussion distracted
disability stressed
tired
The right-hand column is enormous. One-handed operation while holding shopping is the same interaction problem as permanent single-arm use — and it applies to a large share of mobile retail traffic.
The method
1 IDENTIFY EXCLUSION
who cannot use this, and why?
2 LEARN FROM DIVERSITY
include people at the edges in
research, not just the average
— Usability Testing
3 SOLVE FOR ONE, EXTEND TO MANY
designing for the constrained case
usually improves the general one
See: Usability Testing
Step 3 is the substance of the argument, and there are concrete examples:
curb cuts for wheelchairs
→ used by prams, trolleys,
luggage, cyclists
captions for deaf users
→ used on trains, in
offices, in noisy places
voice control for motor impairment
→ used while driving,
cooking
high contrast for low vision
→ used in sunlight
— Colour Contrast
plain language for cognitive access
→ helps everyone in a hurry
— Readability
See: Colour Contrast · Readability
Where it applies beyond disability
Inclusive design covers exclusions that accessibility standards don’t address at all:
NAME FIELDS assuming a first and
last name, or Latin
characters only
TITLE / GENDER required, with a fixed
list
ADDRESS FORMATS a UK-shaped form is
unusable elsewhere
DEVICE ASSUMPTIONS a mid-range Android on
3G is the realistic
case, not a new iPhone
— Percentiles in Performance
BANDWIDTH a heavy page excludes
people on limited data
LITERACY AND dense text excludes
LANGUAGE non-native speakers
PAYMENT METHODS card-only excludes the
unbanked
See: Percentiles in Performance
Name and address fields are the most common and most avoidable. A required “title” from a fixed list, or a name field rejecting apostrophes and accents, excludes real customers for no benefit — Form Design.
Where it goes wrong
- Treated as a compliance checklist. Inclusive design is a process; accessibility conformance is one of its outputs
- Done at the end. Retrofitted inclusion is expensive and partial. This is the cost driver — a decision made inclusively at design time is close to free
- Assumed rather than researched. Designing for an imagined disabled user without involving one produces the wrong accommodations
- Personas of disability. A “blind persona” reduces a wide range of experience to a character — better to test with actual users of assistive technology
- Confused with lowest-common-denominator design. It’s about removing barriers, not removing capability
Making it routine
IN THE DESIGN SYSTEM
components accessible by default
→ the accessible choice is the
default choice
— Design Systems
IN RESEARCH
recruit beyond the average
— User Interviews
IN QA
keyboard and screen reader on core
journeys, every release
— Keyboard Navigation
IN DEFINITION OF DONE
accessibility as a merge condition,
not a later ticket
See: Design Systems · User Interviews · Keyboard Navigation
Building it into the component library is what makes it stick. Every accessibility decision made once, correctly, and inherited by everything downstream — which is the same argument as any other design system benefit — Component Documentation.