Open the home page of almost any site and an automated scan will find something wrong with it. WebAIM’s February 2026 analysis of the top one million home pages found WCAG 2 failures on 95.9% of them, up from 94.8% in 2025, which puts full conformance below 4.1%.

Inclusive design goes after that gap from a different direction. Instead of designing for an average user and adapting the result afterward, teams build the product with the people it usually excludes. Product teams, public agencies and hardware makers apply it, and they check the outcome against accessibility standards such as WCAG.

What Is Inclusive Design?

The Inclusive Design Research Centre (IDRC) at OCAD University defines it as design that accounts for the full range of human diversity in ability, language, culture, gender and age.

Accessibility comes out of the process as one result. It isn’t the whole of it.

Where the discipline came from

Jutta Treviranus founded the Adaptive Technology Resource Centre at the University of Toronto in 1993 (IDRC history page). That lab later became the IDRC.

Four years on, in 1997, a working group led by Ronald Mace at North Carolina State University published the seven principles of universal design. The lab moved to OCAD University on 1 August 2010 and took the IDRC name. In 2018, Treviranus documented her three-dimension framework in a doctoral thesis at University College Dublin.

So there are two lineages. Universal design grew out of architecture and product design. Inclusive design came out of computing and disability research, which is why digital teams reach for it.

Mismatch, not impairment

The framing here treats disability as a mismatch between a person and a designed environment, not a defect in the person.

Microsoft’s Inclusive 101 guide ties this to a definition issued in 2001 that describes disability as an interaction between people and society.

That moves the fix. If the mismatch sits in the product, the product team owns it.

Kat Holmes adds a limit, which is that exclusion is built into design itself. The work becomes spotting one point of exclusion after another and involving the affected people in the repair.

What is shaping UX design today?

Uncover the newest UX design statistics: user behavior, design trends, ROI data, and insights driving better digital experiences.

Check Them Out →

Permanent, Temporary and Situational Exclusion

Permanent disability sits at one end of a spectrum, not the whole of it. Microsoft’s Persona Spectrum takes a single limitation and follows it from permanent to temporary to situational.

One limitation, many situations

Touch is the easiest to picture. A person with one arm and someone with an arm injury are limited in the same way, and so is a new parent holding a baby.

Sight runs from blindness to a cataract, and at the far end there’s the distracted driver. Hearing goes from deafness to an ear infection to a bartender in a loud room. Speech starts with non-verbal people, takes in laryngitis, and also covers a heavy accent.

A device built for a person with one arm works just as well for a wrist injury or a parent carrying an infant, according to Microsoft’s Inclusive 101 guide.

Vision shows the same overlap. Strong color contrast helps a person with low vision and anyone squinting at a phone in direct sun.

For scale, WHO’s 2023 disability fact sheet estimates that 1.3 billion people, 16% of the world’s population, live with a significant disability.

That count leaves out temporary and situational limits. The real audience for any product is bigger than the disability statistics suggest.

Beyond disability

Some exclusion has no medical label at all, and it still locks people out.

Forms are a common culprit, especially ones that assume a surname, a street address or one phone format. Then there are reading levels above the audience’s, slow or metered connections, and payment or ID requirements that shut out anyone without a particular card or document.

Cognitive load and neurodiversity belong here too. Microsoft’s Inclusive Design for Cognition guidebook, highlighted at its 2023 Ability Summit, applies the spectrum to cognitive disabilities.

Which Principles Guide Inclusive Design?

Microsoft wrote its principles for product teams. The IDRC’s cover research and process, and a third set was written specifically for web interfaces.

Microsoft’s principles for product teams

Microsoft starts with the idea of recognizing exclusion, which happens when designers solve problems from their own abilities and biases.

Under its principle of learning from human diversity, the people who are excluded are the real experts at adapting, so they join the process. And “solve for one, extend to many” holds up because a fix for a permanent limitation often serves temporary and situational ones too.

Holmes has said the toolkit built on them aims at creative opportunity rather than legal compliance. That framing explains why product teams adopted it.

The Inclusive Design Principles for the web

Henny Swan, Ian Pouncey, Heydon Pickering and Leonie Watson wrote a separate set for websites and applications.

Their set runs provide comparable experience, consider situation, be consistent, give control, offer choice, prioritise content and add value.

These read more like interface rules than strategy. They’re aimed at designers, developers and product owners, and they start from permanent, temporary, situational or changing disabilities.

The IDRC’s dimensions

Treviranus laid out the framework in her 2018 thesis. It asks teams to recognize, respect and design for human uniqueness and variability.

It also calls for inclusive, open and transparent processes, with co-design involving people who have a diversity of perspectives, including people who can’t use or struggle with current designs. And you’re expected to realize that you are designing inside a complex adaptive system.

Why the principle sets get mixed up

Some explainers list the universal design principles under inclusive design.

Those are equitable use, flexibility in use, simple and intuitive use, perceptible information, tolerance for error, low physical effort, and size and space for approach and use. Mace’s group published them in 1997 for environments, products and communications, not for digital teams.

In practice, I’d reach for Microsoft’s set when setting team strategy and the IDRC’s for research and process design. The web set suits interface review, and the universal design set belongs with physical products and spaces.

Examples of Inclusive Design in Products and Public Services

A few documented cases show the method working, and they aren’t all digital.

Microsoft released the Xbox Adaptive Controller on 4 September 2018 after co-designing it with gamers who have limited mobility and partners including The AbleGamers Charity, The Cerebral Palsy Foundation, Craig Hospital, SpecialEffect and Warfighter Engaged.

Even the packaging was redesigned with input from those gamers, per Microsoft’s launch post.

Captions started as a feature for people who are deaf or hard of hearing, and now everyone else uses them too. Extreme Reach’s 2026 survey of more than 3,000 consumers across five markets found that 81% of respondents use subtitles at least sometimes despite reporting no hearing difficulty.

Waiting rooms, noisy bars and airline safety videos are the situational cases.

Curb cuts are the classic story. Disability activists in Berkeley poured a crude ramp at a curb in the early 1970s, and hundreds of curb cuts followed (Angela Glover Blackwell, Stanford Social Innovation Review, 2017).

In a Sarasota, Florida mall study cited by Blackwell, nine in ten pedestrians carrying or pushing nothing still went out of their way to use a curb cut. That’s “solve for one, extend to many” in concrete form.

The UK government builds inclusion into a shared design system, so services inherit tested components instead of rebuilding them. The GOV.UK Design System launched in June 2018 and is tested against the most common assistive technology and browser pairings.

An audit of more than 40 elements and components in GOV.UK Elements, the Design System’s predecessor, turned up 19 vendor bugs in browsers and assistive technologies in early 2018, and the team reported most of them (GOV.UK accessibility blog).

How Does Inclusive Design Differ From Accessibility and Universal Design?

Of the three, accessibility is the one you can measure on a finished product. Universal design names a target outcome, while inclusive design describes a process of involving the people a product excludes.

Checks for web accessibility run against published standards, WCAG above all. Passing one shows conformance. It does not show that anyone excluded had a say in the design.

DimensionAccessibilityUniversal designInclusive design
GoalRemove barriers for disabled peopleOne design usable by allInclude people the design excludes
MethodMeet published standardsApply seven principlesCo-design with excluded people
OriginDisability rights and standards bodiesRonald Mace, NC State, 1997IDRC, Microsoft
Success measureConformance to a standardUsable without adaptationFewer person-product mismatches

One solution or several?

The primary sources disagree.

The Center for Universal Design (1997) defines its goal as products usable by all people without adaptation or specialized design. Microsoft’s Inclusive 101 guide says designing inclusively does not mean making one thing for all people, and the IDRC favors one-size-fits-one configurations.

The split follows the medium. Microsoft’s hardware guide notes that software is malleable and can be tailored to an individual, while physical products have form. The IDRC itself says its design constraints differ from the domain where universal design began.

Explainers that call inclusive design a single solution for everyone are reading universal design into it.

Which approach to apply when

For fixed physical spaces and objects, aim for universal design outcomes, since a building cannot reconfigure itself per visitor. Configurable software calls for the inclusive process and room for personalization.

Before anything ships, verify it against accessibility standards.

Treat the three as layers, not rivals.

How to Practice Inclusive Design Step by Step

It works as a loop, and the steps below are one pass through it.

  1. Pick one task, not a screen. Sign-in, checkout and booking all work. Cambridge’s Inclusive Design Toolkit starts in the same spot, with what the need is, how it can be met and how well it is being met (Engineering Design Centre, 2010).
  2. Map who the task excludes. Run it through the Persona Spectrum for touch, sight, hearing and speech. Microsoft’s Inclusive Activities cards give you a ready format if the team wants one.
  3. Recruit people who hit the mismatch today. Colleagues and friends of the team don’t count.
  4. Co-design options with them. The IDRC’s Inclusive Design Guide describes the process as an expanding spiral, not a march toward one answer.
  5. Build from tested components, so correct behavior is inherited instead of rebuilt on every screen.
  6. Test with assistive technology. The UK government service manual says to do it throughout development, especially when a significant feature arrives or a major change ships.
  7. Review after release, because every redesign, new feature and third-party widget can reintroduce exclusion.

All of this fits inside the Cambridge Design Wheel, which runs through manage, explore, create and evaluate.

Two things tend to go wrong. Teams recruit only the people who are easy to reach, and they treat step six as a one-time audit before launch.

Building inclusion into a design system

A component library is where correct behavior gets inherited. The NSW Digital Design System publishes components tested against WCAG 2.2 AA, so services built from its accessible UI components work for a wide range of users without specialised adaptations (Digital NSW).

A tested library covers behavior, not judgment. It cannot tell a team whether a flow suits someone stressed, one-handed or reading in a second language.

Research and Testing Methods That Surface Exclusion

Each method catches a different class of problem, and none of them replaces the others.

Research with people who are excluded

Co-design sessions bring affected people in during concept work, before anything is built, so they shape the options. In task-based sessions, participants who use assistive technology attempt real tasks on a prototype or a live build.

Persona Spectrum workshops are for the team itself. They frame who a feature excludes, ahead of recruiting.

The Persona Spectrum frames the question. Only participants answer it.

Testing with assistive technology

The UK government service manual wants coverage of a desktop screen reader, a mobile screen reader, a screen magnifier and speech recognition software.

ToolPlatformCost model
NVDAWindows desktopFree, open source
JAWSWindows desktopCommercial license
VoiceOvermacOS and iOSBuilt into Apple devices
TalkBackAndroidBuilt into Android

Usage isn’t spread evenly, which matters when you pick what to test. JAWS leads desktop use as a primary screen reader (55% of respondents, against 33% for NVDA), and VoiceOver leads on mobile, commonly used by 72% of respondents against 30% for TalkBack (WebAIM Screen Reader User Survey #11, 2026).

Automated checks and their ceiling

Automated scans find a fraction of the problems, and published estimates of that fraction disagree.

A 2017 Government Digital Service audit found the best tools caught around 30 to 40 percent of 142 known issues on a deliberately broken test page. Deque’s 2021 study had its axe tools covering 57 percent of issues by volume across real audit data.

DOJ’s 2024 regulatory analysis looked at repair effort instead. SortSite captured 50.6 percent of the remediation time that manual review found on 14 government pages.

The figures differ because the denominators do. One is a purpose-built test page, another is issue counts across real audits, and the last is repair effort on real pages. Read together, they put automated coverage between 30 and 57 percent.

That is why axe DevTools, WAVE and Lighthouse all need a human pass behind them. Run a manual web accessibility checklist alongside, which means keyboard-only navigation, magnification to at least four times and a screen reader walkthrough. I’d start with the keyboard pass, since it costs nothing.

Laws and Standards That Apply to Inclusive Design

As of October 2026, the legal floor comes from the ADA Title II web rule and Section 508 in the US, plus the European Accessibility Act in the EU. WCAG supplies the technical test behind them, and the versions do not match.

InstrumentTechnical standardKey datesCovers
ADA Title II web rule (US)WCAG 2.1 AAFinal rule April 2024; now 26 April 2027 (population 50,000 or more) and 26 April 2028 (smaller entities and special district governments)State and local government, including public schools and colleges
European Accessibility Act (EU)EN 301 549 (V3.2.1 currently cited; V4.1.1 pending citation)Applies from 28 June 2025 to products placed on the market and services provided after that date; transitional period to 28 June 2030 for service providers’ existing products and service contractsConsumer products and services; microenterprise services exempt
Section 508 (US)WCAG 2.0 A and AACompliance required from 18 January 2018Federal agency technology
WCAG 2.2 (W3C)The standard itselfRecommendation 5 October 2023Voluntary, cited by regulators

DOJ moved the Title II dates by one year in an interim final rule published in the Federal Register on 20 April 2026. The rule covers apps as well as sites, which puts mobile app accessibility inside the same deadlines.

DOJ may still propose further revisions, so recheck the dates before planning around them (Reed Smith, 2026).

EN 301 549 V4.1.1 was published on 2 September 2026 by ETSI, CEN and CENELEC, and it moves the EU from WCAG 2.1 AA to WCAG 2.2 AA.

It carries legal weight only once cited in the EU Official Journal. Deque expects that around 30 November 2026, while other practitioners have pointed to October or mid-December.

The two regions therefore name different WCAG versions. A team selling in both can build to WCAG 2.2 AA, which carries every WCAG 2.1 criterion forward except 4.1.1 Parsing.

Deque cautions that meeting WCAG 2.2 AA is still not the same as meeting EN 301 549 V4.1.1, which adds requirements beyond WCAG.

WCAG 2.2 added nine success criteria and retired one, and four of the new ones change design work the most (W3C, 2023).

Focus Not Obscured (Minimum) sits at level AA, and it means sticky headers and cookie banners cannot completely hide keyboard focus. Target Size (Minimum) is AA as well and wants most interactive targets to reach 24 by 24 CSS pixels.

Accessible Authentication (Minimum), also AA, rules out sign-in that relies on memorizing or transcribing without an alternative. Every drag under Dragging Movements, another AA criterion, needs a single-pointer alternative.

What Does Inclusive Design Return, and What Does It Cost?

The best numbers come from government cost-benefit work, and they favor acting. DOJ’s own analysis of its Title II web rule puts annual benefits above annualized costs.

DOJ’s final regulatory impact analysis (2024) puts annualized costs at $3.3 billion and annualized benefits at $5.2 billion, a net $1.9 billion a year at a 3% discount rate.

Of the $5.28 billion in annual monetized benefits, $2.97 billion goes to people without a relevant disability (DOJ, 2024). On the retail side, 69% of disabled online shoppers click away from sites they find hard to use, costing UK retailers an estimated GBP 17.1 billion (Click-Away Pound Survey 2019, Freeney Williams).

The $2.97 billion figure is the one I’d pay attention to. Most of the monetized benefit lands with users the rule was not written for.

The cost side is front-loaded. DOJ’s analysis counts most of it as testing and remediation of existing content, and it notes that accessibility is far less expensive when done at the creation stage.

There’s one limit on all of this. DOJ measured WCAG remediation on government sites, not the full inclusive design process, and the Click-Away data is a UK shopper survey. Neither isolates the return on co-design itself.

When Inclusive Design Falls Short

It has documented failure modes, and trying harder doesn’t fix any of them.

Microsoft’s own hardware guide warns that adding adjustments for diverse disabilities can overwhelm people with too many settings. Personalization needs a default that works before anyone touches a switch.

Conflicting needs show up most visibly at CAPTCHA, which WebAIM’s 2024 survey of screen reader users ranks as the most problematic barrier by a wide margin.

A team that adds a CAPTCHA has traded one group’s access for the company’s fraud protection. No single design satisfies both, so the call belongs to the team, with affected users in the room.

Shortcut tooling has its own record. The FTC finalized an order in April 2025 requiring accessiBe to pay $1 million over claims that its AI plug-in made any website WCAG-compliant. The order bars such claims unless the company has evidence.

Then there’s token participation. The IDRC rejects casting people with disabilities as research subjects or token participants in design exercises, in line with “nothing about us without us.” One recruited participant per category does not meet that bar.

Inclusive Design FAQ

Is inclusive design the same as human-centered design?

No. Human-centered design builds around users but gives little guidance on bringing diversity into the process, a shortcoming Microsoft’s toolkit team named when it published its own method.

Inclusive design fills that gap by recruiting the people currently excluded and designing with them.

How can a team measure whether a design is inclusive?

Combine a conformance check with task results. WCAG conformance sets the floor, while task completion among participants who face permanent, temporary and situational limits shows whether people can finish the job.

A gap between those groups marks the mismatch to fix first.

What does product inclusion mean?

It means bringing an inclusive lens throughout product development and design. Most sources treat it as a further iteration of the method, not a separate discipline.

Where can a team learn inclusive design?

Plenty of it is free to download. Microsoft publishes its Inclusive toolkit manual and Inclusive Activities cards, the IDRC has its open Inclusive Design Guide, and the Inclusive Design Principles site is worth a read.

For a book, Regine Gilbert’s Inclusive Design for a Digital World covers the digital side. OCAD University also runs a Master of Design in the field.

Where to Start Reviewing a Product for Exclusion

Start with sign-in and payment. A person who cannot authenticate or pay never reaches the rest of the product.

WebAIM’s own datasets point to the same place. CAPTCHA tops screen reader users’ list of barriers (2024 survey), and 33.1% of home page form inputs lack proper labels (2026 crawl).

Test both flows with assistive technology users first. Forms, labels and error messages come next, and everything gets re-tested with every release that touches either.

The trade-off is coverage. Search, content pages and settings stay unreviewed while the first two flows get full attention. I still think depth on the highest-stakes tasks beats one shallow sweep of everything.

Teams ready for the second pass can start with accessible forms.

Bogdan Sandu
Latest posts by Bogdan Sandu (see all)