Permanent, Temporary, and Situational Constraints as a Single Design Axis

A designer who treats accessibility as a property of a minority group will build one set of features for that group and a separate set for everyone else, and will then spend the rest of the project reconciling the two. The reconciliation is unnecessary. The limitations that accessibility requirements address are not exclusive to any population; they are ordinary limitations that every user experiences in some form and for some duration. What differs is the duration and the label, not the mechanism.

One limitation, three durations

Consider the loss of fine motor control in the hands. For one person it is permanent, the result of a spinal injury or a congenital condition, and it will not change. For another it is temporary, a fractured wrist in a cast for six weeks. For a third it is situational: the user is holding a phone in one hand while carrying a bag, wearing gloves in cold weather, or riding a bus that is braking.

The interface requirement in all three cases is the same. Targets must be large enough to hit with a coarse pointer. Actions must not require a precise drag or a sustained simultaneous press. There must be a path that does not depend on the timing of a double-tap. A design that satisfies the permanent case satisfies the other two automatically, and a design that satisfies only the situational case (bigger buttons on mobile) frequently satisfies the permanent case as well, because the mechanism is shared.

The three durations differ in two respects that matter for scheduling. They differ in how long the user has to learn a workaround, and they differ in whether the user can be assumed to have configured anything in advance. A permanent constraint is often accompanied by a user who has already chosen assistive software, keyboard shortcuts, and display settings; a situational constraint arrives with no preparation at all, on a device the user may not own, in a context where settings cannot be changed. This asymmetry is why the situational case is a useful stress test: it removes the assumption that the user has tuned the environment.

Why the label is the wrong key

Requirements are usually written against labels: “screen reader users need…”, “users with low vision need…”, “users with motor impairments need…”. Labels are convenient for organizing a document and actively harmful for organizing an implementation, for three reasons.

The first is duplication. A requirement written for screen reader users (“all content must be available without seeing the screen”) and a requirement written for users in bright sunlight (“all content must remain readable when the screen is washed out”) can have the same implementation: content that is not encoded in an image. Written under two labels, they become two work items, and one of them is usually dropped.

The second is conflict. A requirement written for one label can contradict a requirement written for another, and the conflict is invisible until both are implemented. A design that enlarges text for low vision and a design that keeps a fixed-height container for a compact layout will collide. Keyed by function rather than by label, the conflict surfaces at design time, because both requirements resolve to the same constraint on the container.

The third is coverage gaps. Labels enumerate populations that someone thought of. A requirement keyed to a function covers every population that has the limitation, including ones not on the list: a user with a broken arm, a user with a temporary eye infection, a user reading through a scratched screen protector.

The alternative key is the capability the interface depends on. Enumerate the capabilities the design assumes, then ask what happens when each is reduced. The list is short and stable.

Capability assumed	Permanent reduction	Temporary	Situational
Fine pointing	tremor, limb difference	cast, sprain	one hand, gloves, motion
Sight	blindness, low vision	eye injury, dilation	glare, small screen, driving
Hearing	deafness, hearing loss	ear infection	loud room, muted device
Memory and attention	cognitive disability	illness, fatigue	interruption, sleep loss
Speech	mutism, motor speech disorder	laryngitis	noisy environment, public place
Sustained attention to time	attention disability	stress	competing demands

This table is the whole model. It is not a taxonomy of people; it is a taxonomy of dependencies. Each row is a claim the interface is making about its user, and each row can be falsified.

The capability inventory as a design artifact

The practical form of the model is a short document produced before layout, listing the capabilities the interface depends on and the fallback for each. It is short because the number of distinct capabilities a typical interface relies on is small, and most of them are shared across every screen.

A useful inventory entry has three fields: the dependency, the fallback, and the failure mode when the fallback is absent. For example, a dependency on colour to distinguish two states has a fallback of a second channel (text, shape, position) and a failure mode of two states that are indistinguishable in greyscale or under a colour-vision deficiency. A dependency on hover to reveal an action has a fallback of focus and tap activation and a failure mode of an action that exists only for pointer users.

Writing the failure mode is the step that changes decisions, because it forces a concrete answer to “what does the user see instead”. “Nothing” is a common answer and an unacceptable one.

The inventory also resolves a scheduling problem. Requirements keyed by capability can be attached to components, and components are where implementation happens. A component library entry for a toggle can carry the constraint that its state must not be conveyed by colour alone, which is testable, and which propagates to every use of the toggle. Requirements keyed by population cannot be attached to components because populations do not map to components; they map to whole journeys, which are reviewed late and changed expensively.

Duration changes the remedy, not the requirement

The requirement is stable across durations; the remedy often is not, and conflating the two produces both over-engineering and under-engineering.

Take text size. The requirement is that text remains legible at the size the user needs. For a permanent low-vision constraint, the remedy is support for user-controlled scaling, up to a substantial factor, with layout that reflows rather than clips. For a situational constraint such as a phone held at arm’s length in sunlight, the remedy may be a larger base size and higher contrast. Both satisfy the same requirement, and the second is not a substitute for the first: a design that only enlarges the base size still fails when the user needs to go further, because the base size is not the user’s choice.

The general rule is that a permanent constraint demands user control, because the user’s needs are stable and specific and the design cannot predict them. A situational constraint demands a good default, because the user cannot be expected to configure anything. A temporary constraint sits between the two and is best served by defaults that are easy to override. Three different remedies, one requirement, and the requirement is the part that belongs in the specification.

This distinction also explains a recurring argument in design review: whether a feature is “for accessibility” or “for everyone”. The question is malformed. The requirement is universal; the control is what varies. Providing a setting that adjusts something is not an accessibility feature bolted on, it is the implementation of a requirement that applies to every user, at the cost of one control.

Where the model breaks down

The capability inventory is a good default and has limits worth naming.

It treats capabilities as separable, and they are not. A user may have a visual impairment and a motor impairment, and the combination produces requirements that neither alone would: a screen reader user with a tremor needs keyboard operation with forgiving key timing, and the two constraints interact in the event handling. The inventory lists dependencies, not combinations, so it can miss interaction effects. Combinations are the normal case in older populations, where several mild reductions coexist.

It also understates the cost of recovery and error. Two users with the same reduced capability can have very different tolerance for a failed attempt, depending on fatigue, pain, or the consequences of the error. A constraint model that only asks “can this be done” misses “can this be done repeatedly, and what happens when it goes wrong”. The error-prevention and recovery requirements that follow from that question treat reversibility as a first-class constraint rather than a quality-of-life extra.

And it can become a checklist that is satisfied once and never revisited. The inventory is only useful if it is regenerated when the interface changes, because a new component introduces new dependencies. A component that adds a gesture, a timed transition, or a canvas-drawn chart adds rows to the table.

The model’s value is that it converts a vague commitment into a short list of falsifiable claims. Each row can be tested by removing the capability and observing what remains, which is exactly the shape of a test rather than the shape of a value statement. That testability is also what makes the model economical: the same constraint, written once, covers the permanent, temporary, and situational cases, and the curb-cut argument for that reuse is the reason the economics work out.