One accommodation can serve all three groups
Aliases: one path · no three products · single robust path
What it is
Do not ship a “disabled mode,” a “broken-arm mode,” and a “commute mode.” Keyboard access, a caption track, pause, and resize go out as one shared accommodation that all three triggers use. The cost of forking is not a few extra mockups: three implementations drift, the situational one stays shallow, the permanent one is never regressed, and none of them is trustworthy. The unit of delivery is one robust functional path, not three parallel products filed under user types.
Why it happens
Once needs overlap, forking by biography multiplies maintenance, and acceptance tests cannot be shared. The second layer is that reliability is set by the permanent floor: the path has to hold with no pointer, no sound, and no steady gaze; a situational trigger is a shorter interval on that same path. A “quick voice entry for commuters” that does not cover every action lays half a bridge for occasional use and still leaves no road for people who depend on it. Shared accommodation is not a single visual skin. It is the same names, focus, timing, and alternative channels reused by every entry point.
Studying it
Count how many parallel accommodations exist for the same function (separate skins, separate gestures, a separate “simple version”) and whether they share a test suite. Measure how often complete solutions — captions, keyboard operation, system text size — are used by accounts with no disability flag. That checks whether “one path” is actually being met by all three groups; it is not a rerun of the investment case.
Independent variables: one shared path versus a fork by audience. Dependent variables: number of parallel implementations; behavioural drift between them; whether critical tasks walk the same control tree under all three triggers.
Automated pass rates will not show a fork. Open the “ordinary flow” and the “accessibility flow” side by side and see whether they are two trees.
Where it stops holding
Screen-reader verbosity, braille contractions, and switch dwell time are assistive-technology settings. They do not need a third UI in the product, and “one path” should not swallow them. Forcing everyone into the same visual density is not a shared accommodation. Mandated alternative media (a specified sign-language video, for example) may be an extra format, but it should hang off the same function rather than open another product. For a bind that lasts seconds, the main path may run first and the same accommodation open on demand; a second, incomplete shortcut must not be allowed to count as delivered.
Applying it
- Maintain one keyboard path, one text alternative, and one pause-and-resize path per critical function. Sign-up, search, and payment all walk that tree.
- Kill “accessibility skins” and “senior editions” whose behaviour diverges from the main product. The only differences worth keeping are display density or the assistive technology’s own settings.
- Design new interactions so they can be finished without a pointer, then treat the pointer as an accelerator — not the other way around, with a stub entry bolted on later.
- How to check: list the entry points for one function. If there is more than one, walk them side by side and record whether name, focus order, and result match. If any of the three trigger stories walks a different tree, the accommodation has not yet been made one.