What this means for a design system

A composition contract

A design system is the artefact describing the rendering and interaction rules selected for a particular interface, driven by user capability, user preference and application need. In the assembly context that makes it a composition contract and a decision record, and it must be able to answer twelve questions.

1. Which components may be used at all in this instance.
2. Which variant of each has been selected, and why.
3. Which components may contain which others, and which containments are prohibited.
4. What semantics each component owns, and what it delegates upward or to the author.
5. Which component owns focus in each interaction state.
6. How the keyboard grammar resolves when components nest.
7. Which region owns status announcements, at what priority, and which child announcements are suppressed.
8. How the components reflow together, not just individually.
9. What obligations remain with the author and with the integrator.
10. Which assembled configurations have evidence, and of what kind.
11. Which combinations are prohibited, which are unsupported, and which are merely uncertain.
12. What must be retested at region, page and process level.

I want to be careful about what this buys, because the ambition can easily be overstated. A design system does not make arbitrary assembly safe. It constrains assembly to the combinations for which the selected rules and the available evidence are sufficient, and it makes the remainder visible instead of silent. That is a smaller claim than “the system is accessible”, and it is one that can actually be defended.

Guarantees do not union

This is the single most important formal point, and the one I am carrying into the specification. The guarantees of a parent composition are not the union of the guarantees of its children.

G(P) = V( R(P), C1..Cn, X, E )

G(P)      the guarantees of the parent composition P
R(P)      the parent's own composition rules
C1..Cn    the children, with their declared guarantees
X         the context: content, viewport, language, platform, profile
E         the applicable evidence
V         validation against the design system

A child guarantee propagates upward only if all of the following hold:

• its declared preconditions are still true after assembly;
• the parent has not overridden the relevant semantics, markup or behaviour;
• no sibling conflicts with it, whether over focus, keys, announcements or layout;
• the author obligations it depends on have been satisfied;
• the evidence for it covers the resulting configuration and environment.

Otherwise the guarantee is suspended, and must be re-established by evidence at the parent level. Guarantees are conditional and compositional. They are not labels permanently attached to component names, and a component that was accessible in one assembly has said nothing about the next one.

The practical effect is that a design system has to be able to record a guarantee as suspended, and most cannot. They carry two states, pass and fail, which forces a false choice whenever a guarantee is neither confirmed nor refuted but simply outside what its evidence covers. That third state is the common case in real assemblies.

What it means for component use

The relationship runs both ways, and the second direction is the one usually missed. If a design system is a composition contract, then using components changes character too.

• Components become selections, not defaults. A component is admissible only if the system admits it for this profile and this application need.
• Variants become profile-bound. The same requirement may resolve to a menubar for one profile and a linear list of links for another. Both are correct outputs of the same system.
• Escape hatches become declarations. Any override is recorded, with the guarantees it invalidates and the retest it triggers.
• Slots become typed. “Accepts children” is not sufficient. A slot declares which roles it accepts and which it forbids.
• Component documentation gains a context clause. “Accessible” is replaced by “guarantees X given preconditions Y, with evidence Z”.
• Uncertainty is first class. A component may honestly declare that its behaviour with a particular screen reader is unverified, and that declaration propagates upward.
• Third-party components are quarantined. A component with no contract enters as an unknown and forces evidence at the boundary.

The design system I am building implements the first four of those in its component contracts and the last three in its treatment of evidence and uncertainty.

The process change

Read as a working method rather than as a theory, the shift is from certifying components to evidencing configurations.

The formulation

Everything above compresses into four sentences, and these are the ones I am carrying into the specification.

A component framework supplies reusable possibilities. A design system records the components, variants, composition rules, ownership assignments and accessibility obligations selected for a particular interface. Component guarantees apply only while their declared preconditions survive assembly. Accessibility must be evidenced again at each higher composition boundary, and the complete process is the final boundary.

References

• W3C Web Accessibility Initiative. Understanding Conformance. Understanding/conformance
• Bob Dodd. Component design frameworks and the assembly problem. research/COMPONENT-FRAMEWORKS.md