Want to know how we audited our Design System for Accessibility?
At Birdie, one of our values is “We care”. We care about our society, the people we work with and for, the planet and the ways in which we can impact positively on millions of other lives. With care at our core, it was quite natural to see a group of accessibility evangelists at Birdie trying to put accessibility higher on the agenda.
Our objective for 2023 is to make our product accessible, starting with our Design System. Why did we start with the Design System? It is the single source of truth for our UI. It groups related implementation elements together, defines their purpose and clarifies their delivery. From an accessibility point of view, the Design System presents a unique opportunity to bake accessibility into our components. It enables us to scale accessibility: we make a component of the Design System accessible once and it applies everywhere where the component is used.
How did we run the audit?
We audited the Design System against WCAG 2.1 Level AA success criteria:
- WCAG stand for Web Content Accessibility Guidelines, a set of recommendations for making web content more accessible. WCAG are considered as the international standard for web accessibility.
- WCAG 2.1 is the most current version of the WCAG.
- Level AA is the conformance level used in most accessibility rules and regulations around the world, including the Americans with Disabilities Act (ADA) and the European Accessibility Act.
We audited our Design System in Storybook, the development environment that makes UI development faster and easier by isolating components in an environment outside your main application. We audited each and every variation of the 40 components present in our Design System.
Extensive audit, both automated and manual
We decided to carry out the audit internally using the accessibility tools available online, also because we had the necessary knowledge and skills in-house. We used the axe DevTools by Deque which is an automated and guided accessibility testing tool, available as a Chrome extension or Firefox extension. It shows up as a panel in the developer tools. You can test a whole page or just part of a page, and all detected issues are sorted by severity and come with code snippets for easier debugging.
Even though automated testing tools can give a solid head start, accessibility auditing is complex and always requires a lot of manual testing. For each component, we performed a range of different manual tests:
- Screen readers: use screen readers to make sure that the reading sequence is correct, ie. words and paragraphs are presented in an order that does not change the meaning of the content.
- Keyboard navigation: test the navigation of the components with keyboard only, making sure that content exposed via pointer/hover is also keyboard operable and that keyboard interaction and navigation is never trapped in a component.
- Text resize: check that when resized to 200% (i) text wraps appropriately, (ii) scrollbars are present and (iii) offscreen content can be brought into view.
- Text re-space: look for content or functionality lost as a result of increasing text spacing.
- Heading levels: inspect the heading structure of the components to check that headings communicate properly the organisation of the content.
- Focus management: for interactive elements, move focus from one element to another and verify that (i) the elements receive focus in a logical order, (ii) no element is skipped in the natural focus order and (iii) when the element in focus disappears, the user returns to wherever they were before they focused on the element.
- Visual characteristics: when colour is used to convey information or distinguish a visual element, make sure that there is a different visual cue that does not rely on colour and that conveys the same information.
- Text alternatives for images: check that text alternatives are provided for any non-text content so that it can be changed into other forms assistive technology users need, such as braille or speech.
We ended up with an exhaustive list of issues to be solved in order to meet WCAG 2.1 AA requirements. We already started to solve the most critical ones. Because we have built custom versions of native HTML elements, the number one issue relates to ARIA attributes that are missing in a substantial number of components. For example, our progress bar is built using a <box> which has no meaning from an accessibility point of view. Since then, we have added the ARIA role "progressbar" that informs the browser that this component is actually a JavaScript-powered progress bar widget, as well as the aria-valuemin and aria-valuemax attributes which specify the minimum and maximum values of the progress bar.
How to make the rest of the product accessible?
Once the individual components of the Design System have built-in accessibility, we will define a primary user journey and we will make it accessible too. Unfortunately, having an accessible Design System does not mean that user flows at page level will be accessible so there will still be a fair amount of effort. As Matt May, head of inclusive design at Adobe, rightly put it: “If there were such a thing as an accessible brick you can still build an entirely inaccessible house, and that has to do with how things go together”.
Our ultimate goal is that in each delivery squad, accessibility is being integrated within the product cycle. It will impact each role:
- Product managers will encourage designers and developers to adopt habits that lead to more accessible outcomes by discussing accessibility requirements more explicitly in refinement to drive the thinking across the squad. They will ensure that decisions early in feature definition support an accessible outcome.
- Designers will consider accessibility and the different ways that users interact with applications in design research. They will involve people with disabilities in user testing.
- Engineers will use tools like accessibility linters that flag accessibility errors while you code. They will ultimately include accessibility checks in their CI pipeline to prevent pull request from being merged if accessibility errors are found.
To achieve this goal, we — the accessibility evangelists at Birdie — are investing in educating and sharing knowledge with fellow colleagues. Education and evangelism are fundamental aspects of embedding an inclusive mindset and approach. We will also increase our efforts to raise awareness through demoing or inviting participants to test how users with disabilities might experience our product. At its heart accessibility is a human issue affecting real people. The more we can make those people real, the more effective our evangelism efforts will be.
We’re hiring for a variety of roles within engineering. Come check them out here:
