Design decisions determine who is excluded
Aliases: who gets excluded · default-body hypothesis · exclusion by default
What it is
A checkout that confirms payment only by dragging to a target has already written its guest list: people who can point finely, see the hot zone, and have a pointing device. Switch to keyboard, switch scanning, or a screen reader, and the same money cannot be paid. Design-produced exclusion is not a claim about malice. It is the product's defaults issuing tickets — colour as the only state, actions that appear only on hover, a thirty-second timeout, a graphic CAPTCHA. Each line on that list is a cut.
Why it happens
Every default encodes a body treated as the ordinary user. While that path is being optimised, the people squeezed out never appear in the funnel: they never became users, so analytics records “did not arrive.” The second layer is that exclusion is often residue from the majority path, not a missing “accessibility feature.” An icon-only search control with an empty accessible name can raise click-through for sighted users — the metric rewards the design, and the excluded channel has no counter. Exclusion is therefore a product of design choices, not a natural fact about who the users are.
Studying it
Run an exclusion audit: complete the same critical task with keyboard, switch control, screen reader, magnification, and voice control. Note the first failing step and which default caused it. Compare the visible design of each control with name, role, and state in the accessibility tree.
Independent variables: input channel; whether timeouts can be turned off; whether state is carried by hue alone. Dependent variables: first-failure step; whether the failure disappears when that default is removed; how much of the funnel's “natural” drop-off at that step is actually a closed channel.
Do not treat automated pass rates as a measure of exclusion — scanners cannot see whom the design has written out of the product.
Where it stops holding
Age gates, geo-blocking, and content ratings required by law are not design exclusion in this sense. Hardware ceilings (no haptics on a given device) cannot all be charged to the mockup. Exclusion in user-generated content sits between authors and platform rules, not on a single screen's widgets. Exclusion audits are clearest on scripted tasks; “who never arrived” in open browsing needs abandoned sessions and support logs, and cannot be inferred from a sample of successful users.
Applying it
- On critical paths (sign-up, search, pay, publish), list the defaults: must see, must use a pointer, must finish inside a timer, must pass a graphic challenge. Beside each assumption, write how the people it cuts out are supposed to finish.
- For a new interaction, ask whether the path still works with pointer off, sound off, hue off. If not, the design is not done.
- Do not move the excluded into a separate “accessibility mode”; that institutionalises the cut.
- How to check: complete checkout with the display off, keyboard only; listen with a screen reader to the name of every control that changes the outcome. Any step that can only be done by dragging, hovering, or colour is that step writing the guest list.