J1.07.1social model of disabilitydesignresearch

Barriers arise in the environment, not the individual

Aliases: social model · medical model · UPIAS · impairment vs disability

What it is

A wheelchair user stopped by a flight of stairs is not blocked by a pair of legs; they are blocked by the stairs. Automatic doors and a ramp let the same body through. The social model of disability locates disablement in the mismatch between a body and an environment built for a default body. Impairment is a bodily fact; disability is the exclusion that appears when the environment treats that default as the ticket in. The medical model writes “this person cannot walk.” The social model writes “this entrance only serves people who use stairs.”

Why it happens

An interface never sees a diagnosis. It enforces a default-body hypothesis: can see, can hear, can point precisely, can finish reading inside a timer. When the hypothesis holds, the channel is invisible. When it fails, the failure is filed on the person — “the user couldn’t do it.” The second layer is that “environment” is not only ramps and lifts. It includes information structure, time budget, input modality, and whether assistive technology is allowed to attach. A button with no accessible name, a payment that can only be completed by dragging, and a stair with no ramp are the same kind of object: a particular body written in as an admission ticket.

Studying it

Code defect reports by attribution: is the barrier written onto the person (“blind user cannot complete checkout”) or onto the product (“the pay button has no accessible name”)? Rerun the same task under a changed environment — assistive technology on, pointing device off, time limit removed — and see whether the failure disappears with the environment.

Independent variables: whether an alternative channel exists; whether the task brief uses a diagnostic label or a functional description. Dependent variables: attribution code (person vs product); whether the failure vanishes after the environment changes; whom recruitment copy treats as “the disabled participant.”

Participatory evaluation should pay disabled people using their own devices. Briefly blindfolding non-disabled participants does not test the social model; it tests acute channel loss, not an environment long built around a default body.

Where it stops holding

The social model does not deny pain, fatigue, or progressive illness as limits in their own right; some impairments do not vanish when the interface changes. It also does not explain every exclusion: language, poverty, and digital skill sit outside this frame. One environment can rarely be pixel-optimal for every body at once — the demand is that a channel exists, not that a single visual design pleases everyone. A lab demo in which “the barrier disappears” after one control is fixed does not transfer to a legacy site.

Applying it

  • Write defect titles as environment facts: “the primary checkout button has no name in the accessibility tree,” not “blind users cannot pay.”
  • Record which channel is missing in requirements, not which disability category is being served.
  • In review, ask: if this failure is taken off the person, what is still unfinished in the product.
  • How to check: sample the last 20 accessibility-related defects and count how many locate the cause in a user diagnosis. Rewrite those titles and replay with keyboard or a screen reader until the failure sits on a control, a string, or a time limit.

Related

  • Same group: J1.07.2 Design decisions determine who is excluded · J1.07.3 The social model relocates responsibility
  • Nearby: J1.05 Inclusive Design Principles · J5.14 Testing with Disabled Users
  • Search terms: social model of disability · impairment vs disability · medical model

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/J1.07.1