Accessibility · Inclusive Design

Designing for the Tails of an Ability Distribution, Not the Mean

Why a design calibrated to an average body or an average user excludes most people, and how percentile bands and requirement envelopes replace the average as a design input.

Every interface encodes a body. A button sized for a thumb assumes a thumb of a certain width. A form that fits on one screen assumes an eye that can scan it. A drag gesture assumes a wrist that can hold a press while moving. None of these assumptions is written down, which is why they survive review: they are not claims anyone defends, they are the shape of the artifact. Inclusive design begins when those implicit assumptions are converted into explicit constraints and handed to the design as requirements rather than discovered as defects after release.

The usual substitute for an explicit constraint is a statistical one: design for the average. The average is a convenient fiction because it can be computed from a population, quoted in a specification, and checked in a review. It is also the single worst summary of a population for the purpose of fitting anything to it.

Why the average fits almost nobody

Anthropometric data is reported in percentiles: the 5th percentile stature, the 50th percentile sitting height, the 95th percentile grip strength. Each of those numbers describes one dimension. A person is described by all of them at once, and the dimensions do not move together. Stature and arm length correlate strongly; stature and hand breadth correlate weakly; a great many pairs are effectively independent across a population.

The consequence is arithmetic. If a design requires a user to fall inside the 5th-to-95th percentile band on each of ten independent dimensions, and the bands are treated as independent, the fraction of the population satisfying all ten is $0.90^{10}$, about 0.35. Designing to the middle of every distribution produces a product that fits roughly a third of the people it was designed for, and the people it excludes are excluded for different reasons. Real dimensions are correlated, so the true figure is higher than the independent estimate, but the direction is not in doubt.

from math import prod

# Fraction of a population inside the 5th-95th percentile band on k
# independent dimensions, if each dimension covers 90% of the population.
for k in (1, 3, 5, 10):
    print(k, round(prod([0.90] * k), 3))

The cockpit story is the canonical illustration. In the early 1950s, a United States Air Force study measured a large sample of pilots across ten body dimensions and asked how many fell within the average range on all of them. Almost none did, and the fraction that was average on even half the dimensions was small. The cockpit had been designed around the average pilot, which meant it had been designed around a person who, statistically, did not exist. The response was not to find better averages but to make the seat adjustable, which is the first example of a general pattern: when the population is too dispersed to fit with a fixed shape, the design stops choosing a shape and starts providing a range.

The tails carry the information

A distribution of ability is not a bell curve with a symmetric nuisance at each end. The tails differ in kind from the middle. At one tail sit people whose constraint is mild enough that the default works; at the other sit people whose constraint is severe enough that the default fails loudly. The severe tail is where the failures are visible, and it is also where the design’s hidden assumptions become legible.

Vision illustrates the asymmetry. A design that assumes acuity correctable to 20/20 works for a large majority and fails completely for someone with no light perception, while failing partially for the much larger group with low vision, glare sensitivity, or a visual field restriction. The severe case is not a rare curiosity appended to the real population; it is the limiting case that reveals what the design was silently requiring. Remove the assumption that the user can see the screen and the dependency graph of the interface becomes visible: what is conveyed by position, by colour, by the shape of a control, by the fact that a message appears at all.

There is a second reason to look at the tails. Ability is not a fixed attribute of a person. It varies with fatigue, injury, medication, pregnancy, ambient light, background noise, whether the user is holding a child, and whether the device is a phone in one hand on a moving bus. The same individual moves in and out of the tails across a day. A design that only works in the middle of the distribution works only during the intervals when its user is in the middle, which for most people is most of the time and for some people is never.

Requirement envelopes

The practical replacement for a target user is a requirement envelope: an explicit statement of the range of input and output conditions the design must accept. An envelope is written in the units the design actually consumes.

Envelope dimensionTypical statement
Pointer precisionAny target reachable with a coarse pointer; minimum hit area stated in CSS pixels
ReachPrimary controls within the comfortable reach of a small hand holding the device one-handed
ForceNo action requires sustained force or a two-finger pinch held for a duration
TimeNo task step has a deadline shorter than the user’s ability to complete it, or the deadline is removable
Sensory channelEvery state change conveyed by at least two channels, at least one non-visual
CognitiveTask completable without holding more than a small number of items in working memory

An envelope is not a persona. A persona is a fictional individual with a name and a photograph, and it invites the designer to check whether the design suits that individual, which is a judgement call. An envelope is a set of bounds that can be tested mechanically: measure the target, time the step, remove the visual channel and see what remains. The difference matters because personas are easy to satisfy in imagination and envelopes are not.

Envelopes also compose better with engineering constraints than with demographic ones. A minimum hit area of 24 by 24 CSS pixels is a number a design system can enforce; “consider users with motor impairments” is not. The target-size reasoning that follows from Fitts’s law is an example of a constraint derived from a model of movement rather than from a description of a user group.

The cost of widening the envelope

Widening an envelope is not free, and the cost is usually paid in one of three currencies.

The first is space. Larger targets, larger text, and more spacing consume pixels, and on a small viewport something must give. The resolution is almost always to reduce what is shown at once rather than to shrink what is shown, which converts a space cost into an information-architecture cost.

The second is interaction count. A design that avoids timed steps, drags, and precision gestures often needs an extra tap or an extra screen. The naive comparison charges the added step to everyone and credits the benefit to a minority, which understates the benefit: the users who need the alternative are usually the users for whom the default fails outright, so the comparison is between one extra step and no path at all.

The third is the cost of adjustability itself. A fixed design is cheap to build and cheap to test; a design with a range is more expensive at every stage, because every state in the range must be laid out, styled, and checked. This is the point at which inclusive design stops being a moral argument and becomes an engineering one, and the argument that usually wins is the one about which constraints generalize: a solution built for the narrowest case frequently serves a much larger set of users than the case it was built for. That effect, and its economics, is the subject of the curb-cut account of design economics.

Where percentile reasoning goes wrong

Percentiles are useful and easy to misuse, in four specific ways.

The first is the choice of reference population. A 5th percentile stature computed from a national sample of adults is not the 5th percentile of the people who will use a particular product, and the population that a product actually reaches is often older, more variable, and more constrained than the population the anthropometric table was drawn from. The number is precise and the population behind it is a decision.

The second is the collapse of a band into a boundary. Saying “supports users down to the 5th percentile” implies a cliff at the 5th percentile, when the real cost curve is gradual: reach becomes uncomfortable before it becomes impossible, and the design that just fits the 5th percentile is uncomfortable for a considerably larger group.

The third is treating dimensions as independent in one direction and correlated in the other, whichever supports the argument at hand. Correlations matter, and they are not uniform across populations; a single joint distribution rarely describes a user base that spans several body types, ages, and device classes.

The fourth is forgetting that the output side has an envelope too. A design can be reachable and still be unreadable, and the constraints on the output side (contrast, text size, motion, audio) are usually specified separately from the constraints on the input side. Splitting them produces interfaces that are operable by a user who cannot perceive the result, which is not a partial success.

The constructive version of all four warnings is the same: state the constraint in the units the implementation controls, state the population it was derived from, and state what happens outside the bound. A design that says “below this size, targets remain operable but require more time” is honest about its envelope. A design that says “meets the 5th percentile” is making a claim about a population it cannot see.

Once the constraints are explicit, the next question is where they come from and how long they last. The same underlying limitation can be permanent, temporary, or situational, and the design response differs in each case. That mapping is the constraint matrix used to derive requirements, and it is the bridge between a statistical description of a population and a concrete list of things the interface must do.

References

  1. The Principles of Universal Design — Center for Universal Design, North Carolina State University, 1997
  2. Design for the Real World: Human Ecology and Social Change — Victor Papanek, Thames & Hudson
  3. ISO 9241-171: Ergonomics of human-system interaction — Guidance on software accessibility — ISO
  4. Inclusive Design Principles — Inclusive Design Principles project