Overview

#

A candidate component is a component whose accessibility, visual design, and interactions are largely established, and which has been identified as useful to include in the design system, but whose user experience or implementation details need more time to mature. This means that the following are expected to be refined:

• Visual and interaction details
• Props, slots, events, sub-components
• What parts belong in the design system versus consuming applications

Candidate components are in active use in consuming applications. Thorough unit and visual test coverage is expected to allow for smooth iterations.

Criteria

#

A component can be considered for candidacy when one or more of the following are true:

• It maps to a well-established accessibility pattern or is a collection of such patterns (e.g. APG patterns)
• The overall user experience is unlikely to change significantly

For example, consider a modal side panel component. Its accessibility requirements (focus management, ARIA roles, and keyboard handling) apply uniformly to all use cases, and the main parts of its visual layout are well-defined. Even with some visual or implementation details still unresolved, a single component ensures a more reliable and consistent user experience, avoids duplicated work, and lets real use cases strengthen its robustness across a wide variety of contexts.

A component is unlikely to become a candidate when:

• The accessibility pattern is still being explored
• The user experience is expected to change significantly
• It is highly specific to a single application

Note

#

See additional details and examples on the candidate process in this Figma file.