Building Accessibility into Your Design System — Part 3
Imagine going about your online activity — paying bills through your bank, buying tickets to go to your favorite band’s show, or scrolling through your social media feed. Now imagine that, as you’re doing this, the website gets stuck in frustrating dead ends, the checkout flow won’t let you complete your purchase, and there is a clear mismatch between how you use technology and how interfaces are designed.
For many people who use assistive technology to navigate the web and digital products, this is a daily reality. A recent WebAIM study found that less than one percent of website homepages are likely to meet standard accessibility requirements. Assistive technology encompasses a wide range of devices, including screen readers that read out an interface, magnifying or zoom software that enlarges interfaces, or alternatives to computer mice such as trackballs. Many users are also keyboard only users for a variety of reasons, such as mobility disabilities, efficiency, or personal preference.
As more and more companies are relying on design systems as a foundational approach to building and delivering websites and apps, it’s crucial that these systems are inclusive and accessible, as they will have a knock on effect on the end user experience.
Design systems: an opportunity for accessibility
Design systems present a unique opportunity to build accessibility and inclusion into your component libraries from the get go, both from a UI/UX design perspective, and from a code repository perspective.
For Matt May, head of inclusive design at Adobe, it comes down to values. “If you want inclusion to be the outcome you have to make a statement that this is something you consider to be meaningful.” For the team working on Adobe’s design system, Spectrum, articulating these values was the first step in ensuring an inclusive approach to the design system. “The first thing we agreed upon was that we were going to make inclusive design one of our principles (‘for everyone’). Your design system documents what you value, and in this case, our values dictated that we needed accessibility to be a core aspect of Spectrum.”
Seeing accessibility as an integrated part of design and development, rather than a box to check at the end, is something that Fable CEO Alwar Pillai is seeing more of these days. Fable is a tech platform that enables companies to do accessibility testing with real users, and engage people with disabilities in design, development, and QA. “Our mission is to help organizations integrate and decentralize accessibility,” says Pillai. “We are engaging with companies who are building their design system, and they want to bake accessibility into it. So that it becomes the guiding force for all teams when they are building products.”
Levels of accessibility
When thinking about how to incorporate accessibility into design systems, there are several lenses to consider. Pillai frames the two key considerations as usability and compatibility. “Usability is the experience, the flow, being able to identify, navigate, and operate an interface to get a task done. Compatibility has to do with how various assistive technology interacts with systems and interfaces. This is the part that is outside of the users’ control, and can be limited by the OS and the type of assistive technology they use. For both usability and compatibility, we need to be able to provide affordances in the design system,” says Pillai.
Usability and compatibility play out at several levels of the design system. It starts at the individual component level. For the Slack design systems team, “we try to ensure that all of our components are accessible by default,” shares Trish Ang, a front-end engineer on the Slack Kit team. “One of the big success stories has been creating completely accessible versions of our Select components. It’s been one of the hardest components. It’s a series of different dropdowns and it took us almost a year on and off to build it and make it fully accessible. One of the reasons we took it on was that multiple people had built one-off versions of this, which weren’t accessible.” The huge benefit of this effort to create accessible Selects is that now the component is used in dozens of places.
Mina Markham, a senior engineer on the customer acquisition team at Slack (known, among other things, for her groundbreaking work on design systems for the Hilary for America campaign), emphasizes the importance of having baseline accessibility built into every component. “Systemwide we include not only a hover state, but we include a separate focus state, always making sure that each piece of UI that’s meant to be interacted with has defined states for both mouse interaction and keyboard interaction. On the content side, we’ve made sure we ask for alt-text for every single non-decorative image we get from our design team.” Markham also emphasizes the importance of documentation within the design system. “You can document guidelines for that particular component, and document the steps you took to make that component accessible.”
It’s really important to keep in mind that even if individual components have built-in accessibility, that doesn’t necessarily meant that user flows at the page level or template level will be accessible. “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,” explains May. Designers and developers need to consider how components fit into holistic layouts and experiences. Having a clear navigation structure and using semantic code help.
“Making each component accessible doesn’t guarantee that your overall experience is accessible. There are so many aspects to how a component impacts usability (page content and flow, for example). It’s important for designers and developers to have more context for when they use components. For example if you have a set of forms, you need to have instructions that mandate the inclusion of a descriptive header for each form. There needs to be dependent criteria related to the context you’re using the component in,” says Pillai.
“We’ve learned this the hard way. When the Select component was launched, we built things out and then when we were nearly finished, I discovered that the structure was not accessible. So now we make sure to think about structure from the beginning,” says Ang. “I’m proud to say that Slack treats accessibility bugs as broken functionality, and product blockers, so we had to make sure we went back and fixed the component.” Ang mentions that one of the ways the Slack team addresses this is that “our designers now provide articulated keyboard interaction models when necessary.” This means handing over comps and wireframes that actually map out the navigation in terms of the tab order of the page.
Ensuring accessible design systems through testing
Testing is one way to help ensure that components and page level flows are accessible. There are a few different forms of testing that are helpful: manual, automated, and testing with users.
There are several tools that designers and developers can use during their workflow. Colour Contrast Analyser lets designers check their hex codes to ensure adequate color contrast. Markham recommends the aXe plug in, which is “a chrome extension that checks base level accessibility issues. Using the tool is often when we find hierarchy issues.” Similarly, Pillai mentions the Google tool Lighthouse, which is an automated tool to improve webpages, including accessibility issues. Within teams, there is also the opportunity to leverage QA and code reviews to consider the accessibility of a design system component or page template.
Automated checkers are one tool in assessing accessibility, but it’s important to consider that, to understand whether an implementation is accessible to a particular user and their unique assistive technology set up and needs, you need to do testing with real people. That’s why Fable’s mission is to make this easy to do. “Our perspective is that the best way to assess accessibility is to include the end users and hear their perspectives, so we’ve made it really easy for companies to research, co-design, and test their products with people with disabilities through our platform,” says Pillai. Fable was inspired by Pillai’s own experiences as an accessibility manager in large organizations, and the barriers she experienced to including people with disabilities in the design and testing process.
The importance of education
Creating an accessible design system at every level requires an awareness and understanding of accessibility throughout the design systems team and ideally, the broader organization. Pillai has seen the challenges of being a single “accessibility expert” or manager, because that model cannot scale. “Every person’s role and position impacts accessibility — knowing that your actions/decisions can limit someone’s online experience is important,” she says. This is where education and awareness building come in as fundamental aspects of embedding an inclusive mindset and approach to building digital products.
Education efforts can be formal or informal, and often end up being a mix of both. At Adobe, “as of January we’ll have done 11 full-day trainings across 9 sites on 3 continents, and reached everyone inside Adobe Design,” shares May. The genesis of this inclusive design training was Blue Belt, “the first major training package we built on the accessibility side for engineers. We covered things like a lot of the details of how an accessibility API works at an OS level. What we found was that engineers are called upon to build systems they can’t make accessible enough on their own, because the design didn’t account for accessibility in the first place.” Now, Adobe has rolled out training across the entire organization, to ensure all products are considering accessibility from the ground up. In 2020 Adobe will make their inclusive design materials public, including things like a hands-on introduction to evaluating and documenting accessibility in design deliverables such as wireframes.
At Slack, education on accessibility is mostly peer-to-peer and informal. Ang mentions that there have been a lot of efforts to get everyone up to scratch on basic accessibility requirements. For example, testing out ARIA labels during code reviews (ARIA labels help screen readers and other assistive technologies have more context about a specific element). There are some documented guidelines, such as the color palette, and working side by side with folks with deep accessibility expertise helps the teams level up. “It’s a lot of ‘in the moment’ education, when I see something going astray I’ll call it out. I was noticing that a few of our engineers were writing uppercase letters in the actual code base, and the screener reader will read it out as an actual acronym. All it took was that one little call out and now it’s no longer an issue,” says Markham.
For designers and developers that want to get started in their learning process, there are lots of resources and communities that can help. Liz Jackson’s Interaction19 keynote covers helpful framing around inclusive design, as does Kat Holmes’ book Mismatch. Alwar recommends the book The End of Average by Todd Rose. At a technical and component level, Markham suggests Heydon Pickering’s blog and book, Inclusive Components, that walks through specific examples of accessible components. Ang has also put together a comprehensive list of accessibility resources that span from accessibility 101, to ones focused on testing and building.
Accessibility as an intentional outcome
“The way I think about accessibility is that it’s not a separate thing, it’s just part of the design process,” says Markham. Pillai agrees. “As designers, we are in charge of the overall experience, and that includes accessibility. If every team and project isn’t considering inclusion and accessibility as part of their responsibility, it’s not going to scale.”
For design systems teams looking to encourage widespread adoption of their systems, accessibility can be a compelling argument. May has seen this advantage with Spectrum. “Enshrining accessibility in Spectrum from the ground up means that we’re not starting from scratch. It’s actually become a selling point for Spectrum for product teams — a baseline of accessibility comes free.”
Thankfully, there is more and more recognition in the design and tech world that inclusivity is an imperative for building successful, ethical products. “One essential aspect of inclusive design is to design with the people who are going to use what you have to offer,” says May. “Design systems are the frame into which you can put values and behavior that can end up excluding people.” Because design systems are becoming the foundational structures that inform digital product design and development, we have to ensure that the systems are inclusive and accessible.
Continue to part four: Three Lessons from Brand Setting Up and Driving Adoption of Design Systems.
Thank you to all of the people who participated in research, interviews and surveys, and shared their deep knowledge and expertise. For more on design systems, download the Adobe and Idean e-book ‘Hack the Design System.’
For more unique insights and authentic points of view on the practice, business and impact of design, visit Adobe XD Ideas.
To learn about Adobe XD, our all-in-one design and prototyping tool:
- Download Adobe XD
- Adobe XD Twitter account — also use #adobexd to talk to the team!
- Adobe XD UserVoice ideas database
- Adobe XD forum
Originally published at https://xd.adobe.com.
