What is still open

Six questions I cannot answer yet, and the thirteen concepts this work puts into the specification. The questions are recorded here rather than resolved quietly, because a design system that hides its own uncertainty is the failure this whole section is about.

Where composition predicates live

Should the predicates sit in each component contract, in a separate composition clause of the package, or in both? Duplication risks drift between the two records. Separation risks a contract that cannot be validated on its own, which undermines the case for portability. I currently lean towards the component contract holding its own local rules and the package holding the cross-cutting ownership assignments, but I have not tested that against a real assembly.

Two design systems on one page

How is ownership expressed when a page assembles components from two design systems? There has to be either a merge rule for the single-owner properties (focus, keyboard grammar, live-region priority, landmark identity) or an honest statement that dual-system use is simply out of conformance. The second is cleaner and much less useful, since acquisitions, migrations and embedded third-party widgets make dual-system pages ordinary.

The minimum evidence set at page level

What is the minimum evidence for a page-level claim, and can any of it be inherited from component level? The argument in this section suggests inheritance is unsound in general, but a rule that inherits nothing makes page-level evidence prohibitively expensive and therefore unlikely to be produced at all. There may be a class of guarantee (contrast of a token, say) that genuinely does survive, and identifying that class is worth doing.

Whether uncertainty has a severity scale

Is uncertainty binary, or graded? “Unverified on VoiceOver” and “unverified on a browser nobody uses” are not the same risk, but a scale invites false precision and becomes a negotiating surface: the point at which a team argues its way down a level rather than running the test.

Profile-selected variants and server rendering

If capability and preference select the variant, and the profile is not known at render time, what does the server send? Sending a default and re-rendering on the client risks losing focus at exactly the moment the interface changes shape: the responsive navigation failure, moved to the network boundary.

A canonical accessibility-tree serialisation

Evidence at region and page level needs a stable representation of the accessibility tree to compare against. If no canonical serialisation exists that this work can cite, the project has to define one, which is a considerably larger undertaking than it first appears and one that would be better done by somebody else.

What this puts into the specification

Thirteen concepts follow from the argument, and they are the working list for the next revision of the design system.

  1. The composition hierarchy as a normative structure, with obligations defined per level.
  2. Composition contracts: allowed parents, required context, prohibited descendants, typed slots.
  3. Accessibility ownership: a single declared owner per subtree for semantics, focus, keyboard grammar, announcements and layout adaptation.
  4. Conditional guarantees, each carrying preconditions and invalidation conditions. Nothing is unconditional.
  5. Non-union propagation, stated normatively.
  6. Conflict resolution: parent-level arbitration policies with a defined default.
  7. The state model, with its mapping to accessible expression and to focus and announcement consequences.
  8. Evidence scope: every record states its level and its environment.
  9. Uncertainty propagation: unresolved child uncertainty rises unless bounded.
  10. Override accounting: overrides name the guarantees they suspend.
  11. Content contracts: author obligations are testable, not advisory.
  12. Profile-selected variants: one requirement may legitimately resolve to different assemblies.
  13. Whole-result validation: the rendered page and the completed task remain the final units of accessibility, regardless of component provenance.

Several of these are already present in the specification in weaker form. What this section changes is their status: they stop being desirable properties of a good component and become obligations that attach to the assembly.

References