A11.08.6Situational accommodations can reuse permanent-disability solutionsdesign

A ramp built for wheelchairs ends up serving strollers, luggage, and cyclists too

Aliases: curb-cut effect · accessibility ROI · accessibility investment case

What it is

Curb ramps were built for wheelchair users, but the people who use them every single day are parents pushing strollers, travelers pulling luggage, and cyclists — this is the pattern usually called the curb-cut effect. The same logic holds in interface design: an accommodation built for permanent-disability users, once shipped, ends up benefiting a much larger number of ordinary users who happen to be in a situational or temporary restricted state — a population far bigger than the permanent-disability group it was built for. This isn't a restatement of "the spectrum is functionally equivalent"; it draws the reverse practical implication from that fact: investing in permanent-disability accommodation is not a cost that serves only a small group — its actual reach scales up with the size of the situational population it also covers.

Why it happens

This amplification happens because a solution designed for permanent disability is typically required to be robust and fully reliable — it has to work every time, under every condition, with no exceptions, because the user has no fallback. That high bar happens to fully cover everything a situational restriction needs, since a situational restriction is just a brief time-slice of the same functional bottleneck, with a shorter duration and a lower reliability requirement. A complete solution built for the permanent case therefore automatically satisfies the "easier" situational subset, and because the situational population is an order of magnitude larger than the permanent-disability population, actual usage and the number of people who benefit end up far exceeding what was originally estimated from the permanent-disability population alone.

Where it stops holding

This reuse relationship is asymmetric and only runs from permanent solution to situational benefit, not the other way. A quick fix built just to make things convenient for situational users — a voice-control entry point added only to "free up a hand," with mediocre recognition and limited coverage — falls short of the reliability and completeness a permanent-disability user needs when relying on it as their only path to complete the operation, because a situational user always has the fallback of switching back to the normal input method while a permanent user does not. So a lightweight accommodation built for situational convenience should never be counted as having already covered permanent-disability needs.

Applying it

  • The specific accommodation techniques and assistive-technology compatibility work belong to accessibility implementation and are out of scope here; the point to apply is how to use this logic in decision-making: when evaluating whether an accessibility investment is worthwhile, in addition to counting the target permanent-disability population, estimate how many users in situational or temporary restricted states would also benefit incidentally, and fold that larger number into the return calculation;
  • When prioritizing, favor a complete solution that "naturally covers situational needs once the permanent-disability need is solved" over building separate lightweight stopgaps for permanent users and situational users respectively;
  • Verification: analyze usage data for an accessibility feature already shipped, and count what fraction of the accounts activating or using it show no record of the corresponding permanent-disability need — the higher that fraction, the more the feature's actual reach was underestimated at investment time.

Related

  • Same group: A11.08.1 the situational, temporary, and permanent spectrum · A11.08.2 one-handed contexts: holding, carrying, gripping
  • Nearby: A8.16 pathological and intention tremor
  • Search terms: curb-cut effect · situational impairment · accessibility ROI

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/A11.08.6