Accessibility, Usability and Inclusive Design Are Three Different Arguments

The three words name three different kinds of thing. Accessibility is measured against a published standard. Usability is measured against goals you set yourself. Inclusive design is a way of working, and it has no measure at all. So when two people in a room reach for different words, they are not disagreeing about severity. They are disagreeing about what would settle the question.

That is why the argument goes in circles. If you want the definitions side by side, accessibility and usability compared does that job. This page is about the two conversations that actually happen, which are somebody calling a barrier a usability problem, and somebody asking why a passing audit did not stop the complaints.

When Somebody Says That Is a Usability Problem, Not an Accessibility One

This is the commonest version of the argument and it usually starts with a designer who is partly right. W3C splits accessibility into two halves, and the split is the tool that ends the conversation.

The first half is the requirements that are technical and live in the code rather than in the appearance. Whether a control has a name in the accessibility tree. Whether a form field is programmatically associated with its label. W3C says outright that these are typically not a focus of usability research and practice, and it is right. No general-audience usability study finds them, because no participant in one is using the software that reads them.

The second half is the requirements about interaction and visual design. Understandable instructions. Feedback that tells somebody what went wrong and what to do about it. W3C's own position is that this half is good usability, and that without it some people with disabilities are shut out entirely.

So the honest answer to the designer is usually both, and both is not a compromise. The overlap is real, they are right that the problem would show up in usability research, and none of that changes whether a success criterion covers it. A finding does not stop being a conformance failure because it would also have annoyed everybody.

Three questions decide it in about a minute.

1. 1Is there a success criterion that covers this? If yes, it is an accessibility finding whatever else it also is. Nothing further to argue about. Our rule directory is the fastest way to check.
2. 2Who cannot finish, as opposed to who is slowed down? If somebody is blocked and the rest of your audience is merely irritated, the barrier only exists for that person, and that is the shape of an accessibility problem.
3. 3Would a general-audience usability study have found it? If no, because every participant could see the screen and use a mouse, then usability research was never going to catch it and cannot be the process you rely on.

There is a fourth possibility and it deserves a fair hearing, because W3C names it as one of the reasons somebody hits a barrier. Sometimes the page is just badly designed and it is a general usability problem for everybody, disabled or not. That happens, it is worth writing down, and it goes in your report as an observation rather than as a rule you broke.

In the Standards, Accessibility Is the Wider Word

Almost everybody carries the hierarchy the wrong way round. The folk version says usability is the big idea and accessibility is the disability-shaped corner of it. Look at how the international standard actually defines the two and the nesting reverses.

Usability is defined as the extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. Three fences, and you build all three yourself when you decide who you are designing for.

Accessibility, in the same standard, is the extent to which products, systems, services, environments and facilities can be used by people from a population with the widest range of user needs, characteristics and capabilities, to achieve identified goals in identified contexts of use. Its own note adds that the context of use covers both direct use and use through assistive technology.

Two things changed. The population went from the users you specified to the widest range there is. And the effectiveness, efficiency and satisfaction clause fell away, which is the clause carrying how pleasant the experience was. That reading is ours rather than a statement the standards body makes, and it is worth having ready the next time somebody offers you accessibility as a subset of usability.

We Passed the Audit and People Are Still Complaining

This one arrives about three months after a clean report and it feels like being cheated. It is not. WCAG says the same thing about itself three separate times, in its own text, and nobody reads that far.

• The abstract says following the guidelines will not address every user need for people with the disabilities it covers.
• The introduction says the guidelines are not able to address the needs of people with all types, degrees, and combinations of disability.
• And the section on the three levels says that even content conforming at the highest level, AAA, will not be accessible to everybody, particularly in the cognitive, language and learning areas.

The reason for the third one is given plainly and it is not evasion. The working group ran into real trouble writing criteria for cognitive, language and learning disabilities, and the trouble was testability. A success criterion has to be something two competent testers will agree on, and a great deal of what makes a page hard to think about does not survive that requirement. So it is absent from the standard, present in your users' lives, and it shows up in your inbox.

W3C also warns about the failure mode directly. Where teams treat accessibility as a checklist against the standards, it says, the human interaction part is often lost and accessibility is not achieved. Conformance is a floor and it was written as one.

The fix is not to distrust the audit. It is to run the other test as well, and W3C is careful in both directions about what that buys you. Evaluating with disabled users finds usability problems that conformance evaluation alone does not. And involving users cannot on its own tell you whether a site is accessible, because a handful of participants will never cover the standard. You need both, and each one is a poor substitute for the other. Our guide to testing with disabled users covers how the sessions differ from ordinary research.

Inclusive Design Is a Method, Not a Measurement

The clearest line anybody has written on this comes from Microsoft's inclusive design work, and it settles the question people actually mean when they ask whether inclusive design is a process or an outcome. Accessibility is an attribute. Inclusive design is a method. And practicing the method should make your products more accessible without being a process for meeting accessibility standards.

That last clause is the one to hold on to during budget season, because inclusive design is sometimes offered as a reason to skip the audit. It cannot be. There is no level, no test procedure and nobody to sign anything, by design.

What the method gives you is three habits, and they go in this order.

1. 1Recognize exclusion. Exclusion happens when we solve problems using our own biases, so the first move is noticing whose body and whose situation the design quietly assumed.
2. 2Learn from diversity. People are the real experts in adapting to what does not fit them, which makes them the source rather than the audience.
3. 3Solve for one, extend to many. Focus on what is universally important, and the fix built for one person's permanent constraint tends to serve a much wider group.

The order matters and it is usually quoted wrong. Solve for one is the famous one and it comes third, after the two habits that make it possible. The picture underneath it is the persona spectrum, which sets a permanent constraint alongside a temporary and a situational one. Somebody with one arm, somebody with a wrist injury, and a new parent holding a baby all want a device that works one-handed.

The Situational Argument, and Exactly Where It Breaks

The persona spectrum is a genuinely good argument and it gets stretched into a bad one. The stretched version says that because everybody is situationally limited sometimes, designing for those moments covers the disability case too. W3C staff have published the counter to that, and it is worth carrying word for word in your head.

Designing a device so that a driver can do some tasks without looking at it is not as robust as designing it so that somebody who is blind can reach all of its functions all of the time. Accessibility solutions do not solve every situational problem, and situational solutions do not solve every accessibility problem. The two overlap and neither one contains the other.

There is a vocabulary point tucked inside that, and W3C is deliberate about it. The phrase is situational limitations, not situational disabilities. Somebody holding a baby is limited in that moment. Calling that a disability blurs the line the standard is drawn along, and it makes the argument easier to wave away.

What the Law Asks For, and What It Does Not

Short version. No jurisdiction requires your website to be pleasant. A great many require it to be conformant, and a few require an outcome instead.

The conformance route is the common one. Section 508 requires electronic content to meet WCAG 2.0 at Levels A and AA. EN 301 549 restates each WCAG criterion as a shall. Both name a document and a level, and both are satisfied or not satisfied.

The outcome route runs alongside it and is easy to miss. Under the ADA, a public entity has to make its communications with disabled people as effective as its communications with everybody else. That test names no standard and no version. It asks about the result, which means a conformant page that leaves somebody unable to get the information is still a problem, and it is the closest any of this comes to a legal duty about the experience rather than the markup.

How to Settle It in the Room

Four moves, in order, and the argument is usually over by the third.

1. 1Describe what happens, and to whom. Not the category, the event. A screen reader user reaches the delivery step and hears nothing that identifies the field.
2. 2Look for a criterion. If one covers it, the label on the argument stops mattering.
3. 3Separate blocked from slowed. If a group cannot finish at all, that decides both the priority and the budget line it comes out of.
4. 4Write it in the right column anyway. A real barrier with no criterion behind it belongs in the report as an observation, clearly marked. Dressing it as a conformance failure costs you credibility on every finding that is one.