The difference is who each discipline is built to serve, not how badly the site is broken. Accessibility is what you get when you attend to disabled users, so that they can perceive, understand, navigate and interact with what you built. Usability is about making a product effective, efficient and satisfying, and usability practice as it is normally run frequently does not consider disabled users at all.
That is W3C's own way of drawing the line, and it is better than the popular one. The popular version says accessibility is about being blocked and usability is about being slowed. It falls apart on the ordinary case. A screen reader user who finishes your checkout in four minutes rather than thirty seconds was not blocked, and what they hit was still an accessibility barrier, because it only existed for them.
| Accessibility | Usability | |
|---|---|---|
| Who it attends to | People with disabilities, first and by design | A general audience, and often nobody else |
| Measured against | WCAG, a published standard | Goals and benchmarks you set yourself |
| Result | Pass or fail at a level, for a whole page | A score, a task time, a completion rate |
| Legally required | Frequently, yes | No |
| Found by | Audit and assistive technology testing | User research and analytics |
| What a failure costs | A person who cannot finish at all | A person who finishes slower, or gives up |
One row is worth being precise about. Usability is not literally unmeasured, and there is standards work on it. What usability has no version of is a conformance standard that laws point at, which is why the two disciplines end up on different sides of a budget conversation.
Where Accessibility and Usability Overlap
A great deal, which is why the terms get muddled, and the overlap is more concrete than a general claim about clear writing. Look at the guideline WCAG calls Input Assistance. Identifying errors. Providing labels or instructions. Suggesting how to fix what went wrong. Every one of those would come straight out of a usability study, and every one is a conformance requirement.
That overlap is the honest business case. Fixing accessibility problems usually improves the site for everybody, because a form field nobody can identify confuses people without disabilities too. W3C makes the same argument from the other direction, pointing out that accessibility requirements help everyone in a limiting situation. Captions in a noisy room. A high-contrast interface in bright sunlight. Same requirement, wider payoff.
Where the Two Come Apart
Two directions, and both are common.
Usable and inaccessible. A checkout a sighted mouse user completes in forty seconds, with an unlabelled submit button and no visible focus indicator. It tests beautifully in usability research, because every participant could see it. The unlabelled button is a Level A failure and the missing focus indicator is Level AA, and between them they add up to a customer who cannot buy.
Accessible and unusable. A page that passes all 55 rules, with an eleven-step form, an information architecture nobody can hold in their head, and instructions written by somebody who already knew the answer. Every element is announced correctly. Nobody can work out what to do.
The second case is worth sitting with, because it is the one that catches teams who did the work properly. Conformance is judged for a whole page at a level, and it is pass or fail. There is no score, no partial credit and no measure of how pleasant the passing page is to use. So a conformance report answers one question completely and says nothing at all about the other one.
Why the distinction matters commercially
Only one of them is a legal obligation. You can decide your usability is good enough for now. You cannot decide the same about accessibility if a law names WCAG and your site does not meet it.
What About Inclusive Design?
A third term, and W3C treats it as the broadest of the three. Inclusive design is about diversity and about involving everyone as far as it can be done, which in some regions gets called universal design or design for all. W3C's own version of the scope goes well past disability, into digital literacy, income, education, geography, language, age and the plain question of who has a good connection.
The practical difference is when the thinking happens. Accessibility is often a check applied to a finished design. Inclusive design changes what gets designed. That is our observation about how the two get practised rather than anything W3C says, and it matches what we see arriving in audit briefs.
What to Do About the Difference
- Test both, separately. Usability research with a general audience will not surface accessibility failures, because a barrier that only exists for a screen reader user cannot be found by participants who are not using one.
- Fix accessibility first where budget forces the choice, because it is the one with a legal floor underneath it.
- Include disabled participants in usability research. That is where the two disciplines actually meet, and it finds things neither one alone does. Our testing with disabled users guide covers how to run it.
- Do not let a good usability score reassure you. The two measure different things, and the accessibility answer is not hiding somewhere inside the usability one.
One honest limit
We audit accessibility. We do not run usability research, and a WCAG audit will not tell you whether your checkout is confusing. What it tells you is whether somebody using a screen reader can complete it at all, which is a different and a prior question. Where we do find a real barrier that is not a conformance failure, it goes in the report as an observation, clearly marked as one, rather than dressed up as a rule you broke.