Inclusive Design: Make Exclusion a Product Decision

A service can meet its colour-contrast target and still require a permanent address. It can expose every control to a screen reader and still time out before someone finishes the task.

Those are not edge cases outside the product. They are exclusions created by product decisions.

Inclusive design is the practice of finding those exclusions, understanding their consequences, and changing the product, service, or delivery model deliberately. It does not promise one experience that works equally well for every person.

The product leader’s job is to make exclusion visible while choices are still open, then ensure that accepted exceptions have an owner and a route out.

Define the inclusion boundary without pretending it is universal

“Design for everyone” sounds generous and gives a team no usable scope. Products serve particular tasks through particular channels under real legal, technical, and operating constraints.

Begin with a bounded inclusion claim:

People who need to complete this task, in these contexts, must be able to enter, understand, control, complete, and recover from the service without a barrier created by our chosen channel or interaction.

Name the population using evidence, not a fictional average. Include relevant variation in disability, language, literacy, device, connectivity, assistance, time, environment, and authority.

Do not turn the list into a catalogue of special personas. The unit of analysis is the mismatch between a person, a context, and the product’s demands.

The World Health Organization’s ICF includes environmental factors because functioning and disability occur in context. ICF is a health and disability classification, not a product-design method.

The useful implication is limited but important: capability cannot be inferred from a person alone. The same interaction may be usable in one environment and excluding in another.

Keep accessibility and inclusive design connected, but distinct

Accessibility standards establish testable requirements. For web products, WCAG 2.2 provides success criteria and conformance rules across perceivable, operable, understandable, and robust content.

That baseline is non-negotiable where it applies. It is also not the whole inclusion decision.

WCAG itself says its guidance cannot address every need across all types, degrees, and combinations of disability. Even the highest conformance level does not make a product usable for every person.

A service can conform on its pages while excluding someone through identity proofing, channel policy, support, payment, documentation, or an offline handoff.

Track two claims separately:

• Conformance claim: which standard, version, level, pages, processes, technologies, and exceptions were evaluated?
• Inclusion claim: which people can complete which consequential task, in which contexts, with what remaining barriers?

Do not let a successful audit prove the second claim. Do not let positive user feedback waive the first.

Create an exclusion register before a feature list

An accessibility backlog begins with defects against known requirements. An exclusion register begins earlier, while the team is still deciding what the product will demand from people.

For each critical task, inspect six points:

1. Enter: Can the intended population discover and access the route?
2. Understand: Can people interpret the language, choices, status, and consequence?
3. Control: Can they operate it through the relevant input and assistive technologies?
4. Complete: Can they provide the required information or action under realistic constraints?
5. Recover: Can they correct errors, resume, reverse, or obtain help?
6. Continue: Does the next channel, person, document, or system preserve access?

Record the affected population and context, the product demand causing the mismatch, evidence, severity, frequency if known, consequence, and owner.

Separate observation from inference. “The focus returned to the page header after validation” is an observation. “Keyboard users cannot recover” is a claim that needs the relevant task, technology, and population.

Unknown is a valid evidence state. It should trigger investigation, not an invented estimate.

Involve people without making one person a proxy

People who live with an exclusion can reveal barriers, workarounds, priorities, and consequences that a checklist will not.

Their participation should influence problem framing, concept choice, implementation, and evaluation, not decorate a final review.

Recruit against the decision. Consider disability and assistive technology alongside domain experience, digital confidence, language, device, and the context in which the task occurs.

Ask what participation requires: accessible recruitment material, communication preferences, breaks, remote or in-person access, compatible technology, support people, transport, and fair compensation.

Do not ask one participant to represent a disability category. W3C guidance explicitly warns that one person’s input does not generalise to everyone with the same or other disabilities.

Preserve the study’s scope when reporting. A small evaluation can expose a serious barrier without estimating its prevalence.

W3C also states that evaluation with disabled users cannot by itself determine whether a website is accessible. User involvement and WCAG conformance evaluation answer different questions and should be combined.

Resolve conflicting needs instead of hiding them

Inclusive choices can create trade-offs. A dense view may help an expert compare records while increasing cognitive demand.

An automatic timeout may reduce security exposure while preventing someone from completing a slow, consequential form.

Reducing motion may protect one person while removing the only visible cue another person receives about a state change. Simplifying language may remove a distinction required for an informed choice.

Do not average these needs into a single “inclusive” design. Write the conflict:

• which people and tasks are affected;
• what each option enables and blocks;
• the consequence of failure;
• which parts can be adapted, configured, or offered through another route;
• which obligation cannot be traded away;
• what evidence would change the decision.

Prefer a shared core with adaptable presentation or interaction when that preserves meaning. Offer an equivalent route when one channel cannot carry the task responsibly.

Equivalence is about the result and burden, not visual sameness. A phone route that requires another working day, repeated explanation, or extra identity proof is not automatically equivalent to self-service.

Microsoft’s Inclusive Design site describes exclusion as a mismatch and promotes “solve for one, extend to many.” That is one company’s methodology, not a guarantee that a change designed around one exclusion benefits everyone.

Use the prompt to find transfer opportunities. Verify the transfer rather than claiming a universal spillover.

Follow the task beyond the interface

Many exclusions sit outside the screen the product team owns. A form may be accessible while the required document is not. A booking flow may work while the venue, confirmation channel, or cancellation route does not.

Map the end-to-end task with the relevant people, systems, policies, and channels.

The journey-mapping guide explains how to retain evidence, branches, and service dependencies instead of drawing one ideal path.

For every handoff, ask:

• Does the next party receive the user’s access needs with consent and only when necessary?
• Must the person repeat information or disclose a disability to continue?
• Is an offline or assisted route visible before failure?
• Can support act, or only explain that the digital route failed?
• Does recovery preserve work, authority, and privacy?

GOV.UK’s Service Standard requires UK government services to consider online and offline parts, research participants with access needs, digital skills, connectivity, and assisted digital support.

Its scope is public services. The broader lesson is that inclusion follows the service outcome, not the team’s software boundary.

Turn inclusion into an implementation contract

“Accessible by default” is an aspiration. Teams need behaviour that can be designed, built, and verified.

Attach an inclusion contract to consequential work:

• bounded task, population, contexts, and exclusion evidence;
• semantic structure, name, role, value, and reading order;
• keyboard, pointer, touch, voice, zoom, and assistive-technology behaviour where relevant;
• content, error, status, confirmation, and recovery requirements;
• responsive, translated, low-connectivity, interrupted, and partial-data states;
• timing, motion, authentication, permissions, and privacy constraints;
• service alternatives and support authority;
• evaluation methods, decision owners, and release conditions;
• known exceptions with consequence, owner, and review trigger.

Do not specify assistive technology as a cosmetic compatibility label. State which task, platform, browser, technology, and version were evaluated.

Use the visual-hierarchy guide to keep visible priority aligned with semantic structure.

Use the micro-interaction guide to define honest pending, success, failure, and recovery states.

A design system can encode reliable components, but it cannot decide whether the service asks for an unnecessary document or denies a legitimate route.

Use an evidence stack, not one accessibility score

No single method certifies inclusive quality. Combine evidence whose blind spots differ:

• automated checks for rules that tools can evaluate reliably;
• code and design review against the relevant standard;
• keyboard, zoom, reflow, content, and manual interaction checks;
• testing with representative browser and assistive-technology combinations;
• evaluation with people who experience the relevant exclusion;
• end-to-end service testing across handoffs and support;
• production signals and reported barriers after release.

Automated tools are valuable within their testable scope. Do not publish a universal percentage of issues they can find.

A conformance failure is not downgraded because a participant completed the task. One successful session is not proof that the product works for a population.

When evidence conflicts, inspect the task, environment, technology, and method. The disagreement may expose an untested state or an incorrect causal story.

Make exceptions expensive to forget

Some barriers cannot be removed in the current release. That does not make them acceptable by silence.

For each exception, record:

• the affected people, task, and consequence;
• the requirement, obligation, or inclusion claim not met;
• why available alternatives were rejected;
• the interim route and whether it creates extra burden;
• the accountable owner and decision authority;
• a deadline or event that forces review;
• the evidence required to close it.

Release authority should match consequence. A cosmetic defect and a barrier to healthcare, income, safety, or legal rights do not belong in the same approval path.

Track exception age, repeated barriers, blocked critical tasks, recovery burden, and time to accountable action. Segment outcomes only where it is lawful, ethical, statistically meaningful, and safe.

Do not infer disability from assistive-technology use merely because telemetry makes it possible. Inclusion measurement must not create a new privacy or discrimination risk.

A fictional field-expense service

Consider an explicitly fictional expense product for field technicians. Reimbursement requires a receipt photo, a one-time code sent by SMS, and uninterrupted completion within ten minutes.

The exclusion register identifies several mismatches. Some technicians have unreliable connectivity.

Some use magnification that makes the image-cropping control difficult to operate. Others work through an authorised assistant, but the identity model forbids delegation.

The team does not collapse these into “make the form accessible.” It separates upload, identity, timing, delegation, and reimbursement-policy decisions.

The proposed contract allows a saved draft, alternative document upload, explicit image guidance, accessible crop controls, and an authorised delegation route.

Security reviews the threat model for each route instead of defending the current SMS step by default.

Evaluation combines standards review, manual interaction checks, representative technology, disabled participants with relevant work experience, low-connectivity conditions, and an end-to-end support handoff.

No improved outcome is claimed. The example shows how an interface defect, operating policy, and identity constraint can create different exclusions inside one task.

The quality gate is an honest inclusion claim

Before release, ask what the team can truthfully say.

Which people can complete which task in which contexts? Which standards and technologies were evaluated? What barriers remain? What burden does the alternative route add? Who owns the exceptions? Which evidence would reopen the decision?

Inclusive design does not eliminate every constraint. It prevents constraints from becoming invisible defaults imposed on people who were absent from the room.

The product is stronger when exclusion is an explicit decision with evidence, consequence, authority, and follow-through.

Sources

• World Health Organization: International Classification of Functioning, Disability and Health (health and disability classification that includes environmental factors because functioning occurs in context)
• W3C: Web Content Accessibility Guidelines 2.2 (W3C Recommendation with testable success criteria and conformance requirements for web content)
• W3C WAI: Involving Users in Evaluating Web Accessibility (practice guidance on combining user evaluation with standards and limiting generalisation)
• GOV.UK Service Standard: Make sure everyone can use the service (official scope for UK government services, including online, offline, access-needs, connectivity, and support considerations)
• Microsoft Inclusive Design (one company’s methodology for recognising exclusion, learning from diversity, and exploring transfer from a specific need)

Read next

• User Journey Mapping: Build an Evidence Model
• Visual Hierarchy: Make Product Priority Visible
• Micro-Interactions: Design the State Change