Design System Guide. Chapter 3. Accessibility

Within a design system, accessibility does not exist as a separate discipline.
It is the result of systemic decisions that define how the interface scales, repeats, and remains predictable over time.

In practice, accessibility is rarely perceived as a natural part of design.
Most often, it enters the discussion only when an external trigger appears: a legal requirement, an audit, a user complaint, or the need to enter a new market.

Until that point, accessibility exists in a fragmented form, as a set of isolated decisions dependent on specific screens, teams, and contexts. This is where it becomes clear that without a design system, such requirements cannot be sustained.

Most accessibility issues do not appear critical at the moment decisions are made.

Typical lines of reasoning include:

• the button seems “large enough”
  
• the contrast “looks fine on this screen”
  
• the spacing is “justified by information density”
  

Each of these decisions makes sense locally.
Problems arise not because of a single decision, but because of their accumulation.

Without a design system:

• interaction parameters begin to differ from screen to screen
  
• identical elements are allowed different exceptions
  
• requirements are applied selectively and inconsistently
  

A design system exists precisely to ensure that such parameters stop being subject to local interpretation and become reproducible rules.

In many products, accessibility becomes mandatory not for internal reasons, but because of legislation.

In such cases, the standard
WCAG 2.2
is used as a set of criteria the interface must comply with.

For a design system, this means:

• requirements cease to be recommendations
  
• they become system constraints
  
• deviations from them can no longer be resolved locally
  

If these requirements are not fixed at the system level, compliance remains declarative and breaks down as the product scales.

The absence of direct legal requirements does not mean accessibility loses its value.

Many accessibility criteria describe threshold values, below which an interface becomes:

• less reliable
  
• more fatiguing
  
• more demanding in terms of concentration
  

Examples of such thresholds include:

• interactive elements that are too small
  
• insufficient spacing between them
  
• unpredictable behavior of identical components
  
• poor distinguishability of states
  

For a design system, this means accessibility is directly related not only to inclusion, but also to interface resilience as the product grows.

Within a design system, accessibility is not implemented through checklists.
It is defined through parameters that become part of the architecture.

Such parameters include:

• minimum interactive area sizes
  
• allowed spacing between elements
  
• contrast pairs
  
• rules of behavior and navigation
  
• system responses to errors
  

If these parameters are not fixed:

• components begin to diverge
  
• the UI Kit grows uncontrollably
  
• requirements stop being reproducible
  

If they are fixed, accessibility becomes a property of the system, not the result of manual enforcement.

Some accessibility requirements cannot be solved locally, as they affect the very structure of the design system.

Interactive element sizes

Related criterion:
2.5.8 Target Size Minimum

At the design system level, this decision means:

• a single minimum hit area size
  
• mandatory application to all interactive components
  
• no local reductions allowed
  

This decision affects not an individual button, but:

• component structure
  
• interface density
  
• composition rules
  

Predictability of behavior

Related criteria:

• 3.2.3 Consistent Navigation
  
• 3.2.4 Consistent Identification

At the system level, this is fixed as:

• identical behavior for elements with the same role
  
• unified rules for navigation and states
  

Without this, the system may look visually consistent but remain functionally unstable.

Contrast as a system constraint

Related criterion:
1.4.3 Contrast Minimum

In a design system, contrast:

• is defined through tokens
  
• does not depend on a specific screen
  
• is not weakened by local decisions
  

If this is not fixed, decisions begin to depend on taste, brand pressure, and context, and the system loses predictability.

Even fixed parameters are undermined through exceptions.

Typical justifications include:

• “it can be slightly smaller here”
  
• “this is temporary”
  
• “a special case”
  

Without governance, such decisions:

• are not documented
  
• are repeated
  
• eventually become the norm
  

Governance makes it possible to:

• distinguish between mandatory and recommended parameters
  
• track deviations
  
• preserve system integrity
  

In this context, accessibility becomes part of the decision-making process, not a final check.

In a mature design system, accessibility:

• is not re-discussed in every project
  
• does not depend on specific individuals
  
• does not break as the product scales
  

It manifests through interfaces that:

• forgive imprecision
  
• reduce cognitive and physical load
  
• behave predictably
  

This is not a separate goal, but an indicator that the system makes decisions consistently.

In a design system, accessibility is not a separate topic or a specialized layer.
It is the result of architectural decisions that the system reproduces at every level.

The law may define requirements, but it is the design system that determines whether they become a stable part of the product.

Without systemic fixation, accessibility degrades as the product grows.
With it, accessibility scales together with the system.