The social model relocates responsibility
Aliases: who is responsible · defect vs enhancement · duty to fix
What it is
Write a blocked task as “please use a device you can see” or “please go learn a screen reader,” and the duty sits with the person. Write the same event as a product defect — the primary button has no name, the flow has no keyboard path — and the duty sits with whoever shipped it. What the social model changes is not the slogan. It is attribution of disability: who owes the next cut, which budget line pays, and whether this is a defect or a “special need.”
Why it happens
Medical attribution makes adaptation the user's homework: bring your own assistive technology, train yourself, “we support mainstream browsers.” Social attribution sends the same gap into the product backlog: components need names and roles, and someone in the organisation has to maintain them. The second layer is that the label writes the priority language. Filed as a feature request, it queues with a theme reskin; filed as a defect, it can block a release. Support macros, procurement clauses, and incident reviews copy the same filing — “the user didn’t turn captions on” and “the player doesn’t offer captions” are two different invoices.
Studying it
Interview product, design, engineering, and legal, and see who they charge for the same failure: the user, an assistive-technology vendor, the browser, or their own interface. In the tracker, read type labels on accessibility tickets (bug / requirement / won't fix) and the close reasons.
Independent variables: whether the report template forces “what is missing in the environment”; who in review may retag an item as a defect. Dependent variables: label mix; named owner from report to fix; how often close reasons say “the user should use such-and-such a tool.”
Do not take an attitude score on a survey as evidence that responsibility has moved — look at who holds money and veto power in the backlog and the release gate.
Where it stops holding
People still have strategies, and assistive technology still exists; the social model does not make the product team a medical provider. Operating systems, browsers, and screen readers have their own duty surfaces. Platform bugs cannot all be charged to the app, but “wait until the system is fixed” is not a close reason either — the app still has to offer a channel on the platform as it stands. Internal tools and experiments may narrow the duty if the scope is declared, and that declaration has to be readable by the people it excludes.
Applying it
- File accessibility failures in the defect queue by default, not under “enhancement” or “special need.” A close must name the unfinished channel on the product side; it may not say only “the user should use tool X.”
- Put a veto on the release gate: who can block a ship when a critical path has no keyboard path or no name.
- Support replies lead with a product-side alternative and a fix horizon, then a user-side workaround. The first sentence does not push the problem back.
- How to check: sample closed accessibility tickets for close reason and label. Reopen any that parked duty on the user or an external tool while the product channel was unchanged. Check release records to see whether such tickets could ever have blocked a ship.