Design systems accessibility
Shared components multiply whatever they contain, including barriers. We help design-system teams understand how accessible their components really are, and turn fixes into practices that carry across products.
Design systems are where accessibility decisions are cheapest to make and most expensive to get wrong. This page explains how we can help you make them once, in the system, instead of repeatedly in every product.
Who this is for
- Design-system leads and maintainers who own shared components.
- Design and engineering leaders whose products are built on those components.
- Product teams about to adopt an internal or external component library.
When teams usually get in touch
A component library is about to be adopted more widely, a major release is planned, or the same accessibility problems keep reappearing in products built on it.
What is in scope
- Evaluation of selected components, covering semantics, naming, keyboard and focus behavior, states and content, against the parts of WCAG 2.2 that apply.
- Review of the documentation, guidelines and contribution practices that shape how components get used.
- Recommendations that fit how your team designs, builds and ships.
How we approach it
- Agree which components, platforms and assistive-technology combinations matter most.
- Review design specifications and implementation behavior for the agreed components.
- Group findings by root cause, so one fix in the system benefits every product that uses it.
- Walk through the recommendations with your team and agree priorities.
Likely deliverables
Exact deliverables are agreed when we scope the work. They may include:
- Component-level findings with the reasoning behind each.
- Reusable guidance, such as patterns and acceptance criteria for design and code.
- Suggested priorities for your roadmap.
- A working session with your team to discuss the results.
Limitations
- This is evaluation and recommendation. Making the changes in your components is remediation, which is a separate conversation and only happens if we agree it.
- An evaluation reflects the components, versions, platforms and contexts reviewed. It is not a statement about anything we did not review.
- It is not legal advice, a certification, or a guarantee of compliance or of any particular outcome.
What helps us scope
- Links to component documentation, a component explorer or a staging environment.
- The browsers, platforms and assistive technologies you need to support.
- Known issues and the results of any previous audits.
- Your release timeline and who makes decisions about the system.
How scoping starts
Scoping starts with a free introductory conversation about your components, constraints and timeline. If it looks like a fit, we agree the scope together before any work begins.
Questions teams ask
Do you fix the components for us?
Evaluation and recommendations are the core of this offer. Hands-on implementation is a separate conversation, and only happens if we agree it.
Will this work with our technology stack?
Tell us your stack in the introductory conversation. We will say plainly whether we can assess it well.
Is one evaluation enough to make our system accessible?
Probably not on its own. An evaluation shows where the biggest problems are and what to change. Sustaining the result depends on how your team builds and maintains the system.
Have a project in mind?
Start with a free introductory conversation about what you are building, buying or publishing. If it looks like a fit, we agree the scope together before any work begins.