When Inclusive Constraints Conflict: Partial Orders and Documented Exceptions

Constraints interact, and some of them interact adversarially. Large text wants more space; a compact viewport wants less. A generous target size wants more space; a dense toolbar wants less. A visible focus indicator wants contrast against every surface; a low-contrast aesthetic wants none. Reduced motion wants transitions removed; a state change that is only communicated by a transition wants them kept.

A team that treats accessibility requirements as a flat list has no way to resolve these collisions, so it resolves them by whoever argues last, and the result is inconsistent across screens and unpredictable across releases. The alternative is to make the collisions explicit: define a priority order, apply it mechanically, and record the cases where the order was not followed.

Why the checklist model fails here

A checklist is a conjunction: every item must hold. That works when the items are independent, and it is the right model for the requirements that genuinely are independent: a page has a language, images have alternatives, controls have names. Those requirements do not trade against each other, and a violation is simply a defect.

The requirements that collide are a different class. They are not conjunctions but constrained optimizations: the design must satisfy as many as possible within a fixed budget of space, attention, or latency, and satisfying one may consume the budget another needs. A checklist cannot express “prefer A over B when they conflict”, so the team invents an implicit order under pressure, and the implicit order differs per team member.

The distinction is worth naming because it changes the review question. For a conjunction requirement the question is “is it satisfied”. For a colliding requirement the question is “which one was preferred, and was that preference the stated one”. Only the second question has an answer that survives staff turnover.

Writing a priority order

A priority order is a short, total or partial ordering of constraint classes, with a stated rationale for each adjacent pair. It has to be short to be usable; a list of twenty ranks is a list nobody applies consistently.

The ordering that most interface work converges on, and the reasoning behind it, is roughly as follows.

Blocking constraints first. Anything that makes a task impossible for a group of users outranks anything that makes it harder. An interface that cannot be operated at all is not improved by being beautiful. This class includes operability without a pointer, content available without vision, and text that can be enlarged.

Recoverability second. A constraint that prevents unrecoverable loss outranks one that improves comfort, because the cost of the loss is unbounded while the cost of discomfort is bounded. The reversibility requirements on destructive actions sit here, and they outrank density preferences without argument.

Comprehension third. Constraints on reading order, naming, and instruction placement come next. They degrade performance for everyone and block some users, and they are usually satisfiable by restructuring rather than by spending space.

Comfort and preference last. Target size above the floor, generous spacing, and aesthetic preferences are real constraints and they lose to the ones above. This is the rank that absorbs the collisions, and it is where most design argument actually happens.

The ordering is a partial order rather than a total one, because items within a rank still collide. Two blocking constraints can conflict: a layout that must not scroll horizontally and a table that must not be reduced below a legible column width. The partial order does not resolve that case, and the honest response is that it needs a separate decision rather than a rank.

rank 1  operable at all            (input, perception, magnification)
rank 2  no unrecoverable loss      (reversibility, confirmation, drafts)
rank 3  comprehensible structure   (order, naming, instructions)
rank 4  comfort and density        (spacing, target size above floor, motion)

Writing the order down converts a recurring argument into a lookup. When a sticky header competes with a short viewport, the answer is already decided: rank 1 operability outranks rank 4 density, so the header yields, which is the media query on viewport height rather than on width. When a dense toolbar competes with the target-size floor, the floor is rank 1 and the toolbar changes shape rather than shrinking, because the floor is derived from the effective width of the acceptance region rather than from the size of the drawn control.

The three collision classes

Most conflicts fall into one of three classes, and each has a characteristic resolution.

Space collisions. Two elements need the same pixels. Resolutions: reduce what is shown at once (information architecture), allow one of the elements to scroll or collapse, or change the presentation at the constrained size. The last is the most durable because it does not remove content. A table that becomes a list of records at narrow widths has not lost the data; it has changed the access pattern, and the comparison view remains available on request.

Time collisions. A transition, an animation, or a timeout competes with a user’s ability to perceive or act. Resolutions: remove the time dependency where possible, make the deadline removable or extendable, and ensure that anything communicated only during a transition is also communicated statically. A toast that announces a save is a time collision: the message exists for a few seconds and then is gone, so a user who was looking elsewhere never learns the state. The resolution is a persistent status, with the toast as a redundant convenience.

Attention collisions. Two things demand notice at once, or one thing demands more attention than the user has. Resolutions: sequence rather than overlap, move secondary information to a place the user can visit, and never use a modal for something that does not require an immediate decision. This is where the working-memory budget is spent, and the chunking and disclosure techniques are the tools.

The classes matter because the resolution strategies differ, and applying a space resolution to a time collision is a common error. Enlarging a toast so it is easier to read does not fix the fact that it disappears.

Exceptions need a record, not a silence

Every real interface has cases where the priority order cannot be applied: a third-party embed that cannot be modified, a canvas visualisation with no accessible equivalent, a legacy flow scheduled for replacement. The question is not whether exceptions exist but whether they are visible.

An exception record with four fields is enough to make the decision auditable:

Field	Content
Constraint not met	The specific requirement, quoted
Scope	Which screens, components, or user journeys are affected
Reason	The binding obstacle, stated concretely rather than as “technical limitation”
Disposition	Accepted permanently, mitigated by an alternative path, or scheduled with an owner

The disposition field is the one that changes behaviour. “Accepted permanently” is a decision that someone can defend; “mitigated by an alternative path” is a decision that creates work; “scheduled” is a decision that creates a date. An exception with no disposition is an exception that will be rediscovered as a defect by the next person to audit the interface, and the audit will then report it as an unknown.

The mitigation field deserves emphasis because it is where the constraint can still be honoured in substance. A canvas chart with no accessible rendering of its data can be mitigated by a data table below it, which is not the same experience and does satisfy the underlying requirement that the information be available. A drag-only reorder can be mitigated by move-up and move-down controls. The mitigation is a real design artifact and must be maintained; an unmaintained mitigation decays into a lie, which is why the disposition must name an owner.

Keeping the order honest

A priority order is a design decision and it can be wrong. Three signals indicate it needs revision.

The first is repeated exceptions in the same class. If the rank-1 constraint is routinely excepted, the constraint was probably misclassified: it was treated as blocking when the design can actually function without it, or the budget was set without regard to the cost of satisfying it.

The second is an exception that is really a scope decision. A constraint that cannot be met for a whole product area is not an exception; it is a statement that the area was designed without the constraint, and it should be tracked as a programme rather than as a record.

The third is a collision that the order cannot resolve. When two constraints in the same rank conflict, the order is silent, and the silence is filled by seniority. The resolution is to add a tie-break rule for that specific pair, stated as a rule rather than as a precedent, so the next occurrence is decided the same way.

The order also has to survive being encoded. A priority order that lives in a document is enforced by memory; one that lives in a design system is enforced by construction, which is the argument for constraint ownership at the component layer. The rank-1 floors belong in tokens and components. The rank-3 structural requirements belong in templates and lint rules. The rank-4 preferences belong in the review conversation, where they can be traded without a formal record, because losing them is not a defect.

What remains outside all of these layers is the judgement about which constraints apply to a particular population at all. That judgement is the one the tail-of-the-distribution reasoning is meant to discipline, and it is the point at which a constraint system stops being a checklist and becomes a design position: the bounds are chosen, the collisions are resolved in a stated order, and the exceptions are recorded with reasons. Everything else is bookkeeping, and the bookkeeping is what makes the position survive contact with a release schedule.