Atomic Design Systems: it’s a concept that’s transforming the world of design, breaking it down to its most fundamental components and then building it back up into something extraordinary.
Think of it as the design world’s answer to molecular biology, where everything starts with atoms — small, reusable components like buttons, text fields, and icons. These atoms then come together to form molecules, or slightly more complex structures like search bars or forms. Next up are organisms, which are a combination of molecules that work together as a unit — like a header or footer. Then there are templates, which are essentially the skeleton of a page with placeholders for content.
Finally, we have pages, the end product of this system, bringing together all the components into a fully functional design. This approach became popular around the mid-2010s and streamlines the design process, promotes consistency and makes scalable and maintainable design systems easier to achieve.
Even if you don’t think of your design system as atomic or have adopted atomic principles, all design systems are modular by design and you can easily break down each component into its most granular part. The beauty of this approach is that when you update an element, such as making an accessibility update to change the contrast ratio for text, this change will automatically propagate across all instances of that element, whether it’s within different molecules like buttons, headers or labels. It’s a nifty way to ensure accessibility improvements are consistently applied throughout your design system.
Designing accessible atoms
The success of an accessible design system boils down to creating accessible foundations for the design system — designing accessible atoms. By following accessible design practices such as colour contrast, appropriate headings and labels, button sizes and interactions, you’ll mitigate future issues by making each building block inherently inclusive. I won’t delve into the ins and outs of accessible design here, but here’s a great article that covers the basics.
Additional tips
Use an accessibility checklist
This is a proactive approach to ensure elements are accessible, though it might be tedious when designing so granularly. Deque offers a “basic web accessibility checklist for designers” that is quite comprehensive, and you can skip
Even better, the W3 organisation have also released preliminary tests: https://www.w3.org/WAI/test-evaluate/preliminary/
Reference other design systems
If you’re new to design systems, the good news is that many companies publish their design systems online and include accessibility notes and styles that you can draw inspiration from. Some good ones include IBM’s Carbon Design, Atlassian, Google’s Material Design, and GOV.UK. Use these as a reference point when designing similar atoms, but don’t feel the need to take exactly what they have and repurpose.
An accessible handover
Include detailed development or handover notes for your development team, specifying things such as accessible names, keyboard focus order, HEX codes, and landmark roles. I came across this article a couple of years ago and find myself referring back to it frequently as a valuable reference.
Developing accessible design systems
Use a linter
A linter is a static code analysis tool that scans your code for potential issues and discrepancies against predefined rules. For accessibility, a linter can be configured to check for violations of WCAG criteria, such as missing alt text, incorrect ARIA attributes, and improper color contrast. By integrating a linter into your development workflow, you can catch and correct accessibility issues early on, reducing the need for extensive remediation later in the process.
Automated testing for front-end
This can happen in code editors, production environments, and repos. Automated tests can be run regularly, ensuring that your application remains consistent and error-free as features are added or modified. Like above, the automated test process can identify potential accessibility issues in code such as missing alt text, incorrect ARIA attributes and colour contrast issues.
Auditing a design system
Performing an accessibility audit on a design system is an essential step to identify and remediate issues at scale. Testing can be conducted either at an atom level or at a page level. However, if you choose to start at the atom level, it’s crucial to also test the components together on a simulated page, ensuring they interact properly and maintain compliance when assembled together. The layered approach allows you to fine-tune each element of your design system.
You can complete a WCAG audit in a number of ways:
- Audit Numerically by WCAG Criteria (1.1 through 4.2)
This approach involves systematically reviewing your design against each WCAG guideline in numerical order. It is thorough and ensures you consider every criterion, but it can be time-consuming and potentially overwhelming due to the guidelines covering a wide range of topics.
2. Find Issues and Map to WCAG Criteria
This method requires you to first identify accessibility issues in your design and then map them to the relevant WCAG criteria. While it offers flexibility and can be faster for experienced auditors, it requires a deep understanding of WCAG criteria, and there’s a risk of overlooking some issues without a structured approach.
3. Use Third-Party Evaluation Tool to Audit and Compile Report
Tools like WCAG-EM assist in turning identified issues into a report, providing a structured way to document findings. This approach is user-friendly and I like it because it allows for partially complete reports to be saved. However, one drawback is that you might not always need a full WCAG report, especially if you’re logging issues directly into a bug tracking system like Jira, so it might not be for everyone.
Of course, with any of these options it is recommended to use some automated tests such as WAVE, Siteimprove, or Axe Devtools. However these will not pick up all issues — manual testing is always needed!
