Part 2. What a design system is, and why accessibility drives this one

What a design system is

Consider how design work happens without a system.

A designer needs a warning message, so they choose an orange, a spacing value, and an icon. Three weeks later another designer needs a warning message on a different screen, and chooses a slightly different orange and slightly different spacing. A developer implements both, writing the colour twice. A tester finds that one of the two oranges fails contrast against its background, files a bug against that one screen, and the other screen keeps its failing orange because nobody knew the two were related. Six months later the brand changes, and somebody has to find every orange by searching the codebase.

Nothing in that story is incompetence. It is what happens when a decision has nowhere to live except inside the artefact that used it.

A design system gives each decision a home, a name, and a version (clause 2.1). That is the whole of the mechanism. Everything in the specification follows from wanting it to hold for accessibility decisions specifically.

The five layers

The specification treats a design system as five layers, and clause 3.1 makes the observation that gives the model its practical value: when people argue about whether something belongs in the design system, they are almost always arguing across two of these layers without noticing.

The table below is clause 3.1 as the specification gives it.

Reading the layers

Read them from the top down as decreasing generality (clause 3.2).

A principle applies everywhere and is not negotiable per screen. A token is a value with a name. A layout primitive arranges things and does not know what they mean. A component is an interactive thing that does know what it means. A pattern is several components co-operating through a task.

The ordering is not a hierarchy of importance. It is a hierarchy of scope, and the practical use of it is that it tells you which layer a question belongs to before you try to answer it (clause 3.2). A layer is not more valuable for sitting higher in the table; it is only broader in reach.

Placing one decision in the layers

Take the warning message from the story above and place it (clause 3.3).

Confusing the layers is the source of many scope disputes, and the size of a question is often mistaken as a result. Can the warning be red is a token question. Should the warning steal focus is a pattern question, and it is a far larger one, because the answer changes what happens to the user's place in the page.

If you take one working habit from this section, take that one: name the layer before you argue about the answer.

Three things a design system is not (clause 3.4)

Clause 3.4 rules out three things a design system is regularly confused with.

It is not a component library alone. A library gives you code. A system also gives you the reasoning, the tests, and the record of what has and has not been verified, which is what lets somebody else trust the code.

It is not a style guide alone. A style guide tells you what things look like. It does not tell you what a component promises, what it refuses to promise, or which keys operate it.

It is not a design-tool file alone. A mock-up records an outcome without recording the decision that produced it, which is why the outcome drifts as soon as two people need it.

The third is the one most often left out, and it is the one that catches designers hardest. A file that shows the finished warning message shows the orange without showing why that orange, so the next person who needs a warning message has to decide again.

Why accessibility is the reason this system exists

Most design systems treat accessibility as a quality that components can have. This specification treats it as the thing the system is for, and clause 2.2 says plainly what follows from that: it changes what the system has to record. The whole of Part II — the declarations, the evidence records, the recorded uncertainty — exists because of that one shift.

The retrofit cycle treats symptoms

Accessibility work is commonly retrofitted: build, audit late, patch individual findings, repeat.

That cycle treats symptoms. A finding fixed on one page recurs on the next page that uses the same component, because the fix was applied to an instance and the instance is not where the decision lives. Attaching requirements to reusable components and patterns instead means a fix and its reasoning propagate to everything built from them (clause 2.2).

That is the same mechanism as the warning-message story, applied to a different kind of decision. A colour with nowhere to live is duplicated by accident. A contrast fix with nowhere to live is duplicated by hand, once per screen, forever.

Accessibility is split two ways, for a diagnostic reason

Accessibility does not sit in one module, which is what makes it easy to lose. Clause 2.2 splits it in two.

Every criterion recorded against a component names which branch it belongs to.

The reason is diagnostic, and it is worth being precise about it, because the split looks like bureaucracy until you have used it. A flat list of criteria per component hides whether a failure is geometric or semantic, and those two failures have different owners and different fixes (clause 2.2). A component whose text collides at 400% zoom and a component whose state is never announced are both "failing", and a single undifferentiated list says so in the same words. Branch the list and the first goes to whoever owns the layout primitive, the second to whoever owns the semantics.

The split needs judgement rather than mechanical application. The clearest case is the reflow exception, which looks like a layout matter and is decided by semantics (clause 2.2). Classification follows what carries meaning, not the visual mechanism that produced the appearance. The mechanics of that exception belong to clause 11.2 and to the scoped reflow profile at clause 22, which another section of this guide covers.

The honest cost

There is a cost, and clause 2.2 records it rather than leaving a reader to discover it.

An organisation without a design system cannot adopt this method directly, because it must first identify its de facto components.

That work is unglamorous and it is not optional. Requirements attach to components, so an organisation with no named components has nothing for them to attach to, and the first task is to look at what has already been built and give the repeated things names.

What the survey evidence supports, and what it does not

There is survey evidence for the shift towards design systems, and clause 2.2 gives it with figures.

The source is Putnam, C., Rose, E. J. and MacDonald, C. M. (2023). "It could be better. It could be much worse": Understanding Accessibility in User Experience Practice with Implications for Industry and Education. ACM Transactions on Accessible Computing, 16(1), 1-25. 10.1145/3575662. The paper is listed among the specification's informative references at clause 6.2.

The authors analysed 58 interview sessions with user-experience practitioners between 2017 and 2020.

Those figures are the encouraging half, and quoting only them would misrepresent the paper. Clause 2.2 records two findings from the same research that constrain what the project may claim from it, and it records them rather than smoothing them over.

The first is that concentrating responsibility is itself a failure mode. The groups most cited as responsible for accessibility were dedicated teams or specialists and engineers or developers, and the paper warns that resting responsibility there can produce an attitude that accessibility is someone else's problem. A design system can concentrate responsibility in exactly the same way, if it becomes the place where accessibility is assumed to have been dealt with already (clause 2.2). That is a warning about this project's own mechanism, not about somebody else's, and it is the reason the specification insists a component declare what it refuses to promise rather than only what it promises.

The second is a recorded disagreement. On audit and compliance the paper reads its findings as indicating a need for rigorous regulation, which is not the direction this project's argument runs, and clause 2.2 records the disagreement rather than smoothing it over. The project's answer is portable evidence and declared limits rather than regulation, and the specification does not pretend the paper endorses that choice.

Read together, the evidence supports the shift and refuses to underwrite it. A design system is where the project thinks accessibility decisions should live; the same research says that giving decisions a home is not the same as making anyone responsible for them.

The five gaps the project recorded

The project surveyed existing practice and recorded five recurring gaps (clause 2.3). Each is the reason a later part of the specification exists, so they are worth reading as a list of problems rather than as criticism of anyone's work.

1. Layout is treated as a visual concern rather than an accessibility concern, despite reflow, resize text, and text spacing being layout criteria.
2. Components are tested in isolation but not in composition.
3. Assistive-technology claims omit engine, browser, version, observed behaviour, and test date.
4. Tokens express values but not constraints or relationships.
5. Documentation does not carry machine-readable assertions, and drifts from the implementation.

A sixth sits slightly apart, and clause 2.3 says so explicitly rather than folding it into the five.

A common readiness model asks whether a component is visually accessible, screen-reader compatible, operable, and understandable. That is useful and incomplete, because it does not record which engines were tested, and does not address reflow, zoom, text spacing, or forced colours (clause 2.3). The four-category model of that shape which the project examined is the component scorecard in vendor guidance of the kind Supernova publishes, recorded in the project's design-systems research note as Romero, C., Accessibility in Design Systems: A Comprehensive Approach Through Documentation and Assets, Supernova, supernova.io.

The sixth gap is the one to watch if your organisation already has an accessibility checklist. A checklist that produces four green ticks and no record of which browser and screen-reader engine produced them has recorded an opinion, not evidence.

What the specification adds

Against those gaps, clause 2.4 states what the specification contributes. There are seven items.

1. Layout as a first-class accessibility concern inside the system rather than alongside it.
2. Intrinsic primitives that respond to available space rather than to breakpoint guesses.
3. Engine-qualified assistive-technology claims, with uncertainty recorded explicitly rather than omitted.
4. Assertions that travel with specifications, so a claim can be checked mechanically.
5. Composition conformance as well as component conformance.
6. A documented gap in token standards around contrast relationships, stated as a gap rather than papered over.
7. A portable package that carries the accessibility contract, its evidence, and its uncertainty as first-class records, rather than leaving them in a design tool or an untracked spreadsheet.

Items 1 to 5 answer gaps 1 to 3 and 5 fairly directly. Item 6 is the odd one, and deliberately so: it is an addition that consists of admitting something is missing. Item 5 is the one with the most consequence for a tester, and the requirement behind it is clause 18.2, which another section of this guide covers. The analysis of what goes wrong when accessible parts are assembled — the assembly hierarchy, the compositional failure modes, state propagation, and testing across the hierarchy — is carried by the companion document Component Design Frameworks and the Assembly Problem (research/COMPONENT-FRAMEWORKS.md).

What a design system cannot do

A design system is not an accessibility guarantee, and clause 2.5 says so in the same plain terms the strongest public example uses.

The GOV.UK Design System states on its accessibility page that using the system does not immediately make a service accessible (GOV.UK Design System, Accessibility). The specification adopts that limit as its own (clause 2.5).

The reason is structural rather than a matter of quality. A design system supplies parts. It cannot know whether the parts were assembled in an order that makes sense, whether an error message explains anything, or whether the task built from them is one a user can complete.

The consequence is worth stating as bluntly as clause 2.5 states it. A perfectly accessible set of components can be assembled into an unusable page, and every component will pass its own tests while that happens. That is not a hypothetical about careless teams; it is a property of composition, examined at length in the companion document Component Design Frameworks and the Assembly Problem (research/COMPONENT-FRAMEWORKS.md), which treats accessibility as not closed under composition.

What a system can do is improve the available user-interface resources and modalities, and record honestly what has and has not been verified. It cannot replace research with disabled users, assistive-technology testing, content quality, or contextual judgement (clause 2.5).

This is why Part II requires non-guarantees. A component that lists only what it promises invites the reader to assume the rest, and the assumption is where accessibility is lost (clause 2.5). The mechanism that carries that requirement is the non-guarantee record at clause 14, which another section of this guide covers; what matters here is that it exists because of this limit and not as an afterthought to it.

The limit also constrains what you may say about a package you have built. Clause 4.4 turns it into a prohibition on producers, and the conformance sections of this guide give it in full.