Accessibility addresses a wider range of abilities; usability addresses achievement for a specified user group

What it is

The two concepts define "the user" differently: usability fixes a specific user group in its definition and measures how well that group achieves goals; accessibility (a11y) asks whether the product works across the widest range of abilities—including screen-reader users, one-handed users, and users with different cognitive-load tolerance. Usability is "how well for these people"; accessibility is "how many people it opens to."

Why it happens

The split comes from how constraints are set: usability research may narrow the problem by fixing the user group (design for experts); accessibility refuses that narrowing—it demands the interface stay usable across ability differences in perception (visible/audible), operation (clickable/keyboard-reachable), and cognition (understandable). Assistive technology makes the constraints concrete: a screen reader translates the visual interface into a linear audio stream, and any information conveyed only through visual-spatial relations is lost in translation. Accessibility measures "coverage and compatibility of ability channels," not "performance of some group."

Studying it

Accessibility research has two layers: conformance audits (checking against WCAG-style criteria across the four principles—perceivable, operable, understandable, robust) and testing with real users of assistive technology performing tasks. The layers complement: audits are broad but shallow; user testing is deep but small-sample. The right posture for usability research toward disabled users is to define them as a target user group by ability profile ("screen-reader users who are blind") and reuse the same task-measurement framework—never as a stand-in for conformance checks.

Where it stops holding

The two neither imply nor exhaust each other: passing usability tests says nothing about accessibility (the sample may include no disabled users), and passing accessibility checks says nothing about usability (see the next card in this group). The "wide" range also has limits—every product has a floor of required ability (a purely visual product is inaccessible to blind users); accessibility practice declares such floors rather than promising infinite openness.

Applying it

• State both user calibers in project definitions: the target user group (usability) and the ability-range declaration (accessibility), each with its own acceptance.
• Run accessibility acceptance in two layers: conformance checks first, then task testing with assistive-technology users; both must pass.
• Bake accessibility checks into the development flow (automated scans plus manual audit) and schedule disabled-user testing into the research calendar.

Related

• Same group: B5.13.2 Passing accessibility checks is not the same as being usable by disabled users · B5.13.3 Improvements made for extreme ability conditions usually raise usability for ordinary users too · B5.13.4 Accessibility is usually legally constrained while usability is not, which changes how each is driven
• Nearby: J1 Accessibility and Inclusion · B5.08 Standard Definitions of Usability
• Search terms: accessibility vs usability · wcag · assistive technology