Inclusive design and disability

The World Health Organization estimates that 1.3 billion people live with a significant disability, about one person in six. In a MealBox order flow drawn for this lesson, seven of its eight design decisions shut someone out, and only 3 of the lesson’s 15 people can finish an order.

Inclusive design treats those numbers as design problems with design fixes. You will see disability as a mismatch between a person and a design, widen each decision with permanent, temporary and situational cases, find which laws and standards set the target in India, the EU and the US, and plan inclusion into every phase of a project instead of checking for it at the end.

Disability is a mismatch between a person and a design

Dev has low vision and sets his phone’s text to twice its normal size. On the MealBox menu the photo captions are 12 px light grey and do not grow with his setting, so he orders by picture and guesses the price. In the next app he opens, the text follows his setting and he reads every word. Dev did not change between the two apps. The menu did.

Microsoft’s inclusive design principles start from this observation: exclusion happens because of “mismatches between people and experience”. Its guidebook sets two ways of seeing disability side by side, and only one of them gives a designer anything to do:

Accessibilityaccessibility: The degree to which people with disabilities can perceive, understand, navigate and interact with a product, and contribute to it, on equal terms with everyone else. is the result W3C’s Web Accessibility Initiative describes: people with disabilities can perceive, understand, navigate and interact with a product, and contribute to it, on equal terms. Inclusive designinclusive design: A way of designing that starts from the people a product shuts out, learns from their diversity and solves for one group in a way that extends to many. It covers disability as well as language, age, skills, devices and connection. is the way of working that gets there and goes further, because W3C counts language, age, connectivity, skills and economic situation among the things inclusion addresses as well.

The scale is not small. WHO’s figure of 1.3 billion is 16 % of the world’s population, and it counts only significant disability. Many more people spend part of their lives with a temporary injury, and everyone meets situations that take an ability away for a while, which is the subject of the next section.

Permanent, temporary, situational: one change reaches all three

Microsoft’s guidebook gives an example: a device designed for a person with one arm works just as well for someone whose wrist is injured and for a new parent holding a baby. It calls this the persona spectrumpersona spectrum: Microsoft's way of widening one design decision: a demand such as using both hands shuts out people with a permanent disability, a temporary injury and a situational limit, and one change can serve all three.. The same demand, the use of both hands, shuts out a permanent disability, a temporary one and a situational limitationsituational limitation: A limit that comes from a person's setting rather than their body, such as bright sunlight, a loud room, a busy hand or a quiet library. It ends when the situation does., and the same change removes it for all three.

The program below turns the spectrum into a count. It has 15 people cards: for each of five demands a step can make (precise touch, seeing detail, hearing, speech, and memory and time), one person who cannot meet it permanently, one for a while and one because of where they are. Each of the eight steps of a MealBox order flow lists what it demands, and a person can finish the order only if no step demands what they cannot give:

# Who can finish MealBox's order flow? Disability as a mismatch between what a step demands and what a person can do.
# The flow, its decisions and the fifteen people cards are invented for this lesson.

# Five things a step can demand, and three people who cannot meet each one: permanent (P), temporary (T), situational (S).
ROWS = {
    "precise touch": ["Meera, tremor in both hands", "Arjun, wrist in a cast", "Kavya, one hand on a bus rail"],
    "seeing detail": ["Dev, low vision", "Nisha, eyes dilated after a test", "Omar, phone in bright sun"],
    "hearing": ["Leela, Deaf since birth", "Sam, an ear infection", "Tara, in a loud kitchen"],
    "speech": ["Iqbal, does not speak", "Rohan, has laryngitis", "Zoya, in a quiet library"],
    "memory and time": ["Anil, a brain injury", "Priya, on strong painkillers", "Joe, cooking with a toddler"],
}
KINDS = "PTS"

# (step, the design decision, what it demands, the change that removes the demand)
FLOW = [
    ("pick a slot", "drag a pin along a time bar", {"precise touch"}, "a list of slot buttons"),
    ("see the status", "a green or red dot only", {"seeing detail"}, "a word and an icon beside the dot"),
    ("pay", "'tap Pay when you hear the chime'", {"hearing"}, "the instruction in words"),
    ("verify the phone", "type the 6-digit code, paste blocked", {"memory and time"}, "allow paste and autofill"),
    ("give the address", "type the address again at payment", {"memory and time"}, "carry it forward, editable"),
    ("finish in time", "the pay screen closes after 60 s", {"precise touch", "memory and time"}, "warn, offer more time"),
    ("read the menu", "12 px light grey captions", {"seeing detail"}, "16 px text at 4.5:1 or more"),
    ("choose a meal", "large buttons with words", set(), "(keep it)"),
]

def shut_out(demands):
    return [(row, i) for row in ROWS if row in demands for i in range(3)]

blocked = set()
for step, decision, demands, _ in FLOW:
    people = shut_out(demands)
    blocked.update(people)
    who = ", ".join(f"{ROWS[r][i].split(',')[0]} ({KINDS[i]})" for r, i in people) or "nobody"
    print(f"{step}: {decision}\n  shuts out {who}")

everyone = [(row, i) for row in ROWS for i in range(3)]
finish = [p for p in everyone if p not in blocked]
print(f"\nSteps that shut someone out: {sum(1 for f in FLOW if f[2])} of {len(FLOW)}")
print(f"People cards blocked at some step: {len(blocked)} of {len(everyone)}")
print("Can finish the whole order:", ", ".join(ROWS[r][i].split(',')[0] for r, i in finish), f"({len(finish)} of {len(everyone)})")

print("\nThe same flow with each demand removed:")
for step, decision, demands, change in FLOW:
    if demands:
        print(f"  {step:<17}{change}")
fixed = [(step, decision, set(), change) for step, decision, _, change in FLOW]
still = {p for f in fixed for p in shut_out(f[2])}
print(f"Can finish after the changes: {len(everyone) - len(still)} of {len(everyone)}")

pick a slot: drag a pin along a time bar
  shuts out Meera (P), Arjun (T), Kavya (S)
see the status: a green or red dot only
  shuts out Dev (P), Nisha (T), Omar (S)
pay: 'tap Pay when you hear the chime'
  shuts out Leela (P), Sam (T), Tara (S)
verify the phone: type the 6-digit code, paste blocked
  shuts out Anil (P), Priya (T), Joe (S)
give the address: type the address again at payment
  shuts out Anil (P), Priya (T), Joe (S)
finish in time: the pay screen closes after 60 s
  shuts out Meera (P), Arjun (T), Kavya (S), Anil (P), Priya (T), Joe (S)
read the menu: 12 px light grey captions
  shuts out Dev (P), Nisha (T), Omar (S)
choose a meal: large buttons with words
  shuts out nobody

Steps that shut someone out: 7 of 8
People cards blocked at some step: 12 of 15
Can finish the whole order: Iqbal, Rohan, Zoya (3 of 15)

The same flow with each demand removed:
  pick a slot      a list of slot buttons
  see the status   a word and an icon beside the dot
  pay              the instruction in words
  verify the phone allow paste and autofill
  give the address carry it forward, editable
  finish in time   warn, offer more time
  read the menu    16 px text at 4.5:1 or more
Can finish after the changes: 15 of 15

Seven of the eight steps shut someone out, and 12 of the 15 cards are blocked somewhere. Only Iqbal, Rohan and Zoya finish, and only because no step asks anyone to speak. Look at the step that shuts out six people: a pay screen that closes after 60 seconds demands both a steady hand and quick recall. After seven changes to existing steps, all 15 can finish.

Counting only the permanent column is the usual way teams talk themselves out of this work. The temporary and situational columns are larger: many people break a wrist, lose their voice or cook with a toddler at some point, and almost every phone is used in sunlight. Microsoft’s third principle names the design move: solve for one, extend to many.

Laws point to WCAG, and WCAG 2.2 AA is the target

MealBox is a private business and Ward Desk is a city service, but the laws that cover both lead to the same document. The Web Content Accessibility GuidelinesWCAG: The Web Content Accessibility Guidelines from W3C: testable success criteria at levels A, AA and AAA. WCAG 2.2 is the current version, and content that conforms to it also conforms to 2.1 and 2.0., from W3C, state each requirement as a success criterionsuccess criterion: One testable requirement of WCAG, with a number, a name and a conformance level, such as 2.5.8 Target Size (Minimum) at level AA. that can be tested, at one of three conformance levelsconformance level: One of WCAG's three levels, A, AA and AAA. Conforming at a level means meeting every success criterion at that level and at the levels below it.: A, AA and AAA. WCAG 2.2, the current version, has 86 criteria, split by level as 31 A, 24 AA and 31 AAA. The laws in this lesson ask for level AA, which means meeting every A and AA criterion.

Walk through the timeline. Each event is tagged as a standard, which a team designs to, or a law, which says whose products must meet a standard:

Two patterns stand out. The laws lag the standard: the Indian guidelines for government sites and the US rule both name WCAG 2.1 AA, while WCAG 2.2 has been out since 2023. And a page that meets WCAG 2.2 meets 2.1 and 2.0 as well, so a product designed to 2.2 AA meets every one of these references at once. That is why this track designs to WCAG 2.2 AA.

All six new A and AA criteria in WCAG 2.2 describe decisions made in a design file: where keyboard focus lands and what may cover it, how large a target is, whether a drag has an alternative, where help sits, what a form asks twice, and how people sign in. The next lesson, WCAG 2.2 for designers, works through them. This section is an overview for designers, not legal advice: a team shipping in a regulated market reads the law that applies to it.

Inclusion is planned from the first sketch, not audited at the end

A barrier costs least where it is decided. A drag-only slot picker found on a paper prototype costs a new sketch; the same picker found in an audit a week before launch costs a redesign, new code and a moved date. GOV.UK’s Service Manual turns this into work for each phase: in discovery, learn how people with impaired sight, hearing, movement or cognition would use the service; in alpha, design to WCAG 2.2 and arrange the audit early; in beta, run manual and automated checks with each new feature and draft an accessibility statementaccessibility statement: A public page that says how accessible a service is, which accessibility problems it still has and how the team plans to fix them..

Step through a plan for Ward Desk, a bilingual complaints service where residents report a broken streetlight or a blocked drain, and watch what each phase adds:

Two habits make the plan work. Recruit disabled people as part of every round of research, asking about access needs in the screener, and let them bring the assistive technologyassistive technology: Hardware or software that a disabled person uses to operate a device, such as a screen reader, a screen magnifier, a switch, voice control or a braille display. they use every day, since a borrowed device with someone else’s settings tests the wrong thing. And write the criteria into the design work itself, so a sketch is checked against them before anyone builds it.

Not every barrier is about the senses or movement. W3C’s guidance on cognitive accessibilitycognitive accessibility: Making content usable for people with cognitive and learning disabilities: clear words, content that is easy to find, processes that do not rely on memory, help when needed, and mistakes that are easy to avoid and fix. sets eight design objectives that read like a checklist for a flow:

• help people understand what things are and how to use them;
• help them find what they need;
• use clear and understandable content;
• help them avoid mistakes and know how to correct them;
• help them focus;
• make sure processes do not rely on memory;
• provide help and support;
• support adaptation and personalisation.

Practise

Twelve MealBox decisions are waiting for a barrier audit in the exercise. For each, name the demand that shuts people out, the criterion or objective that covers it, and a change that removes it; the sample tests check that your choices fit together.

"""
Twelve MealBox design decisions, drawn for this exercise. For each one, MAPPING holds
(demand, reference, change): the demand it makes, the WCAG 2.2 criterion or COGA objective
that covers it, and the change that removes the demand. D1 is done as an example.
"""

DEMANDS = ["precise touch", "seeing detail", "hearing", "speech", "memory and time", "understanding"]

# Each reference, with the demands it covers.
REFERENCES = {
    "1.2.2 Captions (Prerecorded)": {"hearing"},
    "1.3.3 Sensory Characteristics": {"hearing", "seeing detail"},
    "1.4.1 Use of Color": {"seeing detail"},
    "1.4.3 Contrast (Minimum)": {"seeing detail"},
    "1.4.4 Resize Text": {"seeing detail"},
    "2.1.1 Keyboard": {"speech", "precise touch"},
    "2.2.1 Timing Adjustable": {"memory and time", "precise touch"},
    "2.5.7 Dragging Movements": {"precise touch"},
    "2.5.8 Target Size (Minimum)": {"precise touch"},
    "3.3.7 Redundant Entry": {"memory and time"},
    "3.3.8 Accessible Authentication (Minimum)": {"memory and time"},
    "COGA 3: Use clear and understandable content": {"understanding"},
}

# Each change, with the demand it removes.
CHANGES = {
    "slot buttons instead of a drag": "precise touch",
    "close buttons of at least 24 by 24 px": "precise touch",
    "a word and an icon beside the colour": "seeing detail",
    "text at 4.5:1 or more against its background": "seeing detail",
    "text sizes that follow the text-size setting": "seeing detail",
    "captions on the video": "hearing",
    "the instruction in words, not a sound": "hearing",
    "typing and touch as well as speech": "speech",
    "a warning, with a way to get more time": "memory and time",
    "allow paste and password managers": "memory and time",
    "carry the address forward, editable": "memory and time",
    "plain plan names, such as 'Weekly veg plan'": "understanding",
}

DECISIONS = {
    "D1": "Choose a delivery slot by dragging a pin along a time bar",
    "D2": "Active and paused plans told apart only by a green or a red dot",
    "D3": "Menu captions in light grey #9CA3AF on white",
    "D4": "A how-to video about pausing a plan, with speech but no captions",
    "D5": "'Tap Pay when you hear the chime'",
    "D6": "The payment screen closes after 60 seconds",
    "D7": "The sign-in code must be typed by hand; paste is blocked",
    "D8": "The delivery address is asked for again on the payment step",
    "D9": "Close buttons of 16 by 16 px in the corners of dialogs",
    "D10": "On the tablet app, a reorder can only be spoken aloud",
    "D11": "Plan names written as puns, such as 'Dal-icious Deal'",
    "D12": "Prices set in a fixed size that ignores the text-size setting",
}

MAPPING = {
    "D1": ("precise touch", "2.5.7 Dragging Movements", "slot buttons instead of a drag"),
}

"""Sample tests for the map-mealbox-barriers exercise."""

from solution import CHANGES, DECISIONS, DEMANDS, MAPPING, REFERENCES


def test_every_decision_is_mapped():
    missing = sorted(set(DECISIONS) - set(MAPPING))
    extra = sorted(set(MAPPING) - set(DECISIONS))
    assert not missing and not extra, f"missing: {missing}; not a decision: {extra}"


def test_each_mapping_has_three_parts():
    for key, value in MAPPING.items():
        assert isinstance(value, tuple) and len(value) == 3, f"{key}: give a tuple (demand, reference, change)"


def test_names_come_from_the_lists():
    for key, (demand, reference, change) in MAPPING.items():
        assert demand in DEMANDS, f"{key}: '{demand}' is not in DEMANDS"
        assert reference in REFERENCES, f"{key}: '{reference}' is not in REFERENCES"
        assert change in CHANGES, f"{key}: '{change}' is not in CHANGES"


def test_reference_covers_the_demand():
    for key, (demand, reference, _) in MAPPING.items():
        assert demand in REFERENCES[reference], f"{key}: {reference} is not about '{demand}'"


def test_change_removes_the_demand():
    for key, (demand, _, change) in MAPPING.items():
        assert CHANGES[change] == demand, f"{key}: '{change}' removes '{CHANGES[change]}', not '{demand}'"


def test_each_change_fits_one_decision():
    used = [change for _, _, change in MAPPING.values()]
    repeated = sorted({c for c in used if used.count(c) > 1})
    assert not repeated, f"used for more than one decision: {repeated}"


def test_every_demand_appears():
    missing = sorted(set(DEMANDS) - {demand for demand, _, _ in MAPPING.values()})
    assert not missing, f"no decision makes these demands yet: {missing}"

The questions after it begin with the idea you have answered least well so far:

You can also try MealBox’s status colours in the colour blindness simulator to see why a dot alone carries no meaning for some readers.

Interview questions

Warm-up: how does seeing disability as a mismatch change a designer’s work?

It moves the problem from the person to the design, which is the part a designer controls. Instead of asking how many users have a diagnosis, you ask what each decision demands: two hands, colour vision, hearing, speech, a good memory or quick reactions. Each demand shuts out people who cannot meet it permanently, for a while or in a situation, so the question becomes whether the demand is needed. Often it is not, and removing it is a design change rather than a new feature. The mismatch view also tells you where to look first: the steps every user must pass, because a person blocked at one step cannot finish at all.

Warm-up: which accessibility standard would you design a new product to, and why?

WCAG 2.2 at level AA. It is the current version of WCAG, and a design that meets 2.2 meets 2.1 and 2.0 as well, so one target covers the Indian guidelines for government sites and the US rule for state and local governments, which both name 2.1 AA. Level AA means every A and AA criterion. I would add the criteria that matter most to the product’s users from level AAA where they are cheap, and check the specific law of each market the product ships to.

Two harder questions follow. Before you open either, decide which numbers you would want to see first:

Key takeaways

• Disability becomes a barrier where a design demands what a person cannot give, so the barrier is removed by changing the design.
• The persona spectrum adds temporary and situational limitations to permanent ones, and one change usually serves all three.
• A flow is only as open as its least open step, so every step people must pass is checked against every demand it makes.
• The laws of India, the EU and the US point to WCAG, and designing to WCAG 2.2 AA meets the 2.1 AA they name.
• Inclusion is planned into every phase: disabled people in research, criteria on sketches, checks with each feature, and an audit as the last check rather than the only one.