Following-up on our live panel, our experts are back to answer the top questions on accessibility and design systems in this deep-dive Q&A.
Last month we hosted the Scaling Accessibility Through Design Systems panel — with our fantastic panel consisting of accessibility advocate and design leader Geri Reid, renowned engineer Lauren Beatty, and UX and design researcher Stéphanie Walter. You can also find the recording of the panel if you missed it.
However, the topic of accessibility within design systems is enormous and couldn't possibly be covered in just an hour, and many of you had some burning questions that you followed up with. So we brought your questions to our amazing panelists for a follow-up Q&A to give you all that detailed insight. We split the questions into three main sections, education and adoption, testing and tracking, and broader technical questions.
Lauren: At Zapier, we face two main challenges in ensuring accessibility:
To address these challenges, we take the following steps:
Geri: Focus on the target demographic who love your brand. How many of these customers aren’t able to use your product because they have visual impairments, are color blind or use your app outside in bright sunlight? Use an impairment simulator to show the brand team how these customers perceive your product. Calculating this exclusion might give your argument more weight.
Stéphanie: I’m not sure anyone lost customers because they changed the branding, and I would ask them for some data to back up that claim. But, this might be deeply rooted in the “accessibility makes products ugly” old myth. If anything, having a more accessible website could actually bring more customers. And if that doesn’t work, if it's a website (or native app), there might be a technical solution for that. You could offer a theme switcher and have a “high contrast” mode for people who need it. It’s not a perfect solution because this will only cover the app and site, so you might still have issues with PDFs, documents, and print communication, but it’s a start.
Geri: Aligning accessibility to the company’s strategic goals can help get it onto roadmaps. This could support objectives around driving forward innovation, extending market reach, or enhancing brand values toward diversity and inclusion. Minimizing legal risk is also a consideration that might help prioritize accessibility.
Gerri: Assist consuming teams by documenting component accessibility. Suggest aspects such as focus order, keyboard interaction, ARIA tags, and expected user experience to help teams configure and compose components thoughtfully. If you possess accessibility knowledge in the systems team, you could offer an accessibility review of their work-in-progress. Catching potential issues early in the design phase can prevent complications later. It's important to note that although a design system supports accessibility, it is not solely responsible for ensuring the end product is accessible. Product teams must also be accountable for their own quality assurance and testing.
Lauren: I would start with an audit of what's currently being used in the product. What are the common patterns? A design system that folks love to use is not something that’s forced upon product teams but is directly solving those teams’ challenges. I don’t know that there is a bare minimum of what you need to get started; the smaller the initial setup, the faster you can get the design system out to your consumers and get feedback. Rinse and repeat!
Geri: The "curb-cut effect" is making accessibility improvements that go on to be appreciated by a larger group than the people they were designed to help. A digital example of this is Search Engine Optimisation (SEO). Producing design system components with structured, semantic code and content in plain language can make your products more accessible to users of assistive tools like screen readers. But it also improves how search engines like Google crawl and rank your site. SEO can be a nice upsell to business-focused stakeholders.
Stéphanie: You can do a couple of things:
Lauren: Tying the work back to the company's strategy and values is crucial. For example, you could say, "Our company's number one key bet is X. This work aligns with X because Y. It is also in direct alignment with our core value of Z." Stéphanie previously made a great point about survivor bias — it's possible that there are many potential customers who are unable to use your product due to its inaccessibility.
Geri: The WCAG guidelines can be complex, so bringing them back to specific applications in your company is a great idea. When I worked at a fintech company, the design system ran an accessibility workshop with the product design team. We created cards that showed the criteria we needed to comply with to meet WCAG AA, and had the designers measure their design layouts against them to decide what needed to be changed. Reducing the WCAG guidelines to relevant and actionable points makes the criteria more relevant. This was a useful exercise to work through as a team, and we saw some positive changes going forward.
Stéphanie: There is a pretty decent list of tools and techniques here. These will help you automate some tests, but at the end of the day, you still need manual testing.
Lauren: Both! Having both design and engineering on board with testing for accessibility is a game-changer! If design and engineering are really in sync, then the product and users benefit.
Stéphanie: When it comes to “where does design stop and where does dev start,” I’m not sure there is a “one size fits all” guideline here. I would discuss this with the team directly and see who feels comfortable documenting what. You could create sort of a roles and responsibilities matrix for the whole team (and rework it with new team members) as to where each role finishes / starts.
Geri: WCAG guidelines don’t specify a minimum font size for the web. It’s generally agreed that 16px is a thoughtful minimum for body copy and I wouldn’t suggest going smaller than 14px for footnotes. This can vary though, depending on the font. More importantly, text must allow resize to 200% of its original size. Line length is also a consideration for comfortable reading.
Stéphanie: I would also add that you test this with users as well. Especially if you work on enterprise products and dashboards with a lot of data. I work on a project where we switched to 16px to make it easier to read, and we thought it would help everyone. But, we then had a LOT of feedback that the new site is too big and users see fewer data, so they wanted the font smaller. Some users wanted a 10px font size. We ended up with 14px as the base and taught people to use the zoom feature if they wanted smaller or bigger. So, this goes back to Geri’s answer, make sure you don’t block zoom, and people can resize without breaking the layout.
Geri: Good accessibility is allowing multiple ways to perceive a product, so font size and zoom are both important. If I had to pick one, I’d go with zoom — it’s crucial to be able to resize text up to 200% and allow for reflow when zoomed. The web is fluid and responsive, and it’s us designers putting up barriers by constraining content! This should be a consideration early on in design.
Lauren: I think Geri and Stéphanie touched on this during the live stream. APCA is promising, but if your site is required to conform to a certain WCAG standard, you should stick with WCAG. We’ve experimented with this at Zapier with some elements that need dynamic color variation, and it’s challenging to maintain WCAG compliance.
Geri: An understanding of semantic structure is fundamental to an accessible screen. Encourage teams to start with unstyled copy and group content into logical regions. Is the order still logical with the styling removed? WebAim has a great basic overview.
Stéphanie: There isn’t. The W3C documentation explains that the existing WAI accessibility standards and guidelines cover mobile. So, for now, there’s nothing specific for native apps. There are still guidelines that apply to both web and native.
Some people collected resources on how to make mobile apps more accessible though, you could check:
Geri: I’m a fan of the Radix UI color system — its use of color allows designers to make sensible choices and, if applied in accordance with the scale, ensures components maintain contrast.
At NewsKit, we use tokens for multi-brand theming. Using documented tokens helps remove the guesswork for designers on which color and font sizes to use.
That's all for this time, we hope these insights can help you better implement and scale accessibility within your organizations. Share with us on Twitter what your top tips are and join the discussion.
Unlock the full potential of your design system with Supernova, empowering you to drive innovation, collaboration, and seamless scalability.