A design system is a library of styles, components, and patterns used by product teams to consistently and efficiently launch new pages and features. A good system has accessibility embedded throughout and includes documentation, guidelines and implementation notes for accessibility.
There are several benefits of an accessible design system for you, your team, your organisation, and the people using your products.
By embedding accessibility in your design system, your team reduces the need to repeat accessibility work, freeing them to focus on new things. For example:
- Colour pallets don't have to be recreated and tested again and again
- Visible focus states can be designed once and used uniformly across a website
- Text descriptions and accessible names can be written once and used everywhere removing the need to re-write copy
As the Inclusive Design Principle, be consistent says:
Use familiar conventions and apply them consistently.
By documenting accessibility for styles, patterns and components, your team reduces the risk of designing and building inconsistent experiences for people with disabilities. For example:
- Inconsistent keyboard focus order for people who browse with a keyboard, speech recognition, a desktop screen reader, a mobile screen reader or switch input
- Inconsistent labels for buttons that do the same thing, which makes people unsure what a button may do
By increasing accessibility efficiency and consistency, your team can build inclusive products faster and at scale. For example:
- Complex components such as tab panels, menus and navigation can be built once and re-used across multiple areas of a website or application
- Accessible styles can be applied across all products and platforms
By considering accessibility as integral to your design system, you improve the user experience for everyone as many accessibility requirements improve usability for all. For example
- Good contrast for text and UI components is beneficial for people using a mobile
- A logical page structure with good use of headings helps everyone understand the relationship between content on a page
By embedding accessibility in a design system, you are one step closer to sustainable accessibility across your products and within your product development process. An accessible design system contributes to:
- Reducing remediation time for accessibility
- Creating a culture of accessibility across product teams
- Freeing up product teams, so accessibility is proactive and not reactive
Design systems vary, but an accessible design system can include style guides, components, patterns, and accessibility documentation.
Accessibility must be embedded throughout the design system. This means there is general guidance for accessibility and specific accessibility guidance for all styles, components, and patterns.
The general accessibility guidance can include:
- Your organisation's accessibility principles
- Your organisation's accessibility compliance level
- An overview of accessibility guidelines and techniques
- Accessibility resources for product teams
Specific accessibility documentation is then included with each style, component or pattern.
Visual style guide
A visual style guide documents the look and feel of a brand. What is included can vary but should always include:
- Colour contrast used for all typography and background colour combinations as well as UI components and meaningful graphical elements so people can perceive a product
- Focus states for actionable elements including links, buttons, controls and form inputs so people can operate controls
- Typography with fonts and font sizes that support readability so people can understand a product
- Icons with visible text labels and text descriptions that help people understand a product
Editorial style guide
Editorial guidelines apply to all copy, this includes both visible copy and hidden copy that screen reader users access. It should cover readability and copy patterns for:
- Body text
- Form labels
- Error messages
- Alerts and status messages
- Text descriptions for images
- Labels for landmark regions
An accessible editorial style guide will also document inclusive language guidelines for your organisation. This includes preferred language for:
- Sexual orientation
- Socio-economic status
A component library documents re-usable components such as menus, tab panels, accordions, buttons and so on.
Each component is designed, built, and tested for accessibility before it is added to the design system. Each component should include accessibility documentation so designers and developers using the component don't break the accessibility when they add it to a page.
For example, a component should include implementation advice on:
- Focus order
- Keyboard behaviour
- Text descriptions
- Announced screen reader content
- Expected user experience
The last item, expected user experience, is a good way of helping people using your design system understand what the expected outcome is for people browsing with different assistive technologies.
The BBC News team have a guide on How to document the screen reader user experience which includes seven steps for designers to consider. There is also an accompanying screen reader UX poster (PDF, 67kb)
A pattern library documents how two or more components can be combined to help people complete a task or process. This can be content structure, layouts, page templates, forms, status messages, or other combinations of UI elements.
As with the components, including the expected user experience for people browsing with assistive technologies and various disabilities is key.
An accessible design system is for use by product teams.
Who creates it
When it comes to who is responsible for accessibility in the design system, the short answer is that everyone who works on it is responsible.
If you have a design system team, the team should include at least one person from each discipline. For example a UX researcher, content creator, interaction designer, visual designer, a developer, a QA tester and product owner.
Each team member is responsible for the accessibility of what they design, code, test, or write. This means making the styles, components, and patterns accessible as well as documenting accessibility implementation specifications for each.
How your team manages this process will vary but ultimately, it is a collaborative process. No individual role in the team should work in isolation; multiple roles will have input on what you do:
- UX researchers are responsible for including people with disabilities in all research, and ensuring accessibility is part of the overall user experience working closely with product owners
- Content creators are responsible for making sure that all editorial is accessible and work closely with UX researchers, interaction and visual designers
- Interaction designers are responsible for accessible interactions that support diverse user experiences and will work closely with visual designers and developers
- Visual designers are responsible for making sure everyone can perceive and understand styles, components, and patterns and work closely with UX researchers, interaction designers and developers
- Developers are responsible for accessible code working closely with interaction and visual designers
- Quality Assurance (QA) testers are responsible for verifying the style, component, or pattern meets the expected accessibility standard working closely with developers
- Product owners are responsible for making sure accessibility is included throughout the design, build and test of assets for the design system working closely with everyone at each stage
If you don't have a design team, you can create your system on a small scale by documenting established accessible style, components and patterns for re-use. This is an investment of time, but it is time you will immediately win back as you evolve your product.
You can also look at adopting or adapting an existing accessible design system, component library, or pattern library. This can be as large or as small as you need:
Tip: regardless of whether you are using a third party to host your design system, or you are hosting it on your platform, it must also be accessible.
If using a third party platform, check to see if they have an Accessibility Conformance Report (ACR). You will need to make sure that both the front-end is accessible as well as the back-end so that people with disabilities in your product teams can use and contribute to the design system.
There will be times when product teams can't find the component, style, or pattern they need, or it doesn't do exactly what they need it to do.
When this happens, there is a risk of people adapting styles, creating their own components, or ignoring the design system and doing their own thing. This runs the risk of accessibility becoming compromised or broken.
Put a design system governance process in place where people can request or suggest updates. All new content added to your design system must then pass a design system accessibility assessment before it can be added. All new styles, components, and patterns should meet WCAG 2.1 Level AA and include accessibility implementation guidance, as well as include accessibility documentation.
As well as maintaining accessibility, this has the added benefit of ensuring your design system can evolve and innovate with accessibility being a driver for good.
- Building accessibility into design systems, Adobe Spectrum
- Annotating designs for Accessibility (video) Claire Webber and Sarah Pulis at #id24 2021
- A Designer’s Guide to Documenting Accessibility & User Interactions, by Stephanie Walter
- The Inclusive Design Principles
When you want your design system to be the best it can be, our design system accessibility service gives you the information you need to build accessibility into the core of your products and services taking you one big step closer to sustainable accessibility.
We like to listen. If you have a project, product, problem, or idea that you want to discuss, get in touch!