If you’re working on a Design System, you want to create a library of code and visual assets that you can create once, edit in one place, and use everywhere throughout your system or product; and you also want to do it right.
In order to ensure that your product serves a pleasant experience to many users regardless of their abilities, you’ll need to make it accessible for as many people as possible. Doing this goes beyond asking developers to add appropriate aria labels, metadata, and using semantic HTML. In fact, it has everything to do with how you design your components, their states, and interactions within your product.
So how do we make Design Systems more accessible?
Every component in a Design System needs to be treated with the same care and love you would put into designing an entire webpage. It’s a component, after all, and it’s going to be used over and over again throughout your company’s product. It might even have different configurations you have to keep in mind. So give each and every single one you work on the time, care, and consideration it deserves from CTAs (call to action) to full-page overlays.
It’s not enough to say “this looks good, color contrast is alright, it’s done.” Or to check most of the boxes on WCAG or The A11Y Project’s accessibility checklists to be at least AA compliant with web accessibility. Or to just hand off your designs to developers in hopes they handle it somewhere between the company’s current coding standards and their QA process. You have to design each component with accessibility in mind.
You should design for at least four different people
When you design any digital product, try designing it for different types of people. This may sound like a lot of work but really it’s no different from designing with personas.
Each person listed below represents a broad spectrum of ableness. Many individuals who use digital products (maybe even you!) can be described as a combination of any of these four types of users. I encourage all designers to keep these users in mind when designing any digital experience.
The Four Types of People
- The “Average User”
- The Visually Sensitive
- The Keyboard User
- The Hard of Hearing User
The “Average User”
The first person at-bat is The “Average User” that everyone designs for. In the minds of most designers, the average user doesn’t require any special accommodations. The only thing they ask of you as a designer is that you don’t design products in a way that makes them overly confusing or difficult to figure out. Basically, they want you to follow general UX best practices. So if your design is simple, clean, and straightforward, your “Average User” is happy.
It is important to remember as designers that the ‘Average User’ isn’t necessarily someone who is able-bodied or fully without disabilities, they are just individuals who do not require special accommodations such as screen readers or other assistive tools to use digital products.
The Visually Sensitive
The second person we want to talk about is our visually sensitive person. They represent digital users who suffer from color deficiencies, low-contrast vision, blindness, or photosensitive epilepsy. When it comes to designing components, they want you to keep several things in mind:
- Use thoughtful color and pay attention to contrast. They’d like you to make sure you’re using decent contrast ratios (AAA compliance is best, 7:1), especially where text and other important indicators are concerned. This makes your component more accessible to users with low-contrast vision and color blindness.
- Use large text sizes and readable fonts where possible. Ensure text can be magnified without breaking your layouts.
- Only use animations that are subtle and don’t flash within your component. Excessively flashing can trigger seizures in users who have photosensitive epilepsy and you want people to be safe when they’re using your product. You can also provide a means to opt out of non-critical animations for devices that have ‘reduce motion’ settings.
- Be a part of your team’s QA development process, familiarize yourself with screen readers and available screen reader tests. Ensure that users who rely on screen readers can use your component and extract the information they need, as well as execute any available actions that the component allows.
The Keyboard User
When you’re done with The Visually Sensitive’s iteration of your component, let’s take a look at accommodating our Keyboard User. This individual has some physical limitations that make using a mouse rather difficult. They tend to rely solely on the keyboard and really appreciate experiences designed with them in mind.
When using a keyboard to navigate through a site, users heavily rely on the ‘active/focus’ highlight around components or HTML elements (such as links, buttons, or tabs) to indicate where they are on a page and what they can interact with.
Here are some things to do when designing for keyboard users:
- Ensure that the ‘active/focus’ highlight on and within components has enough visual color contrast to be AAA compliant. Depending on your product’s color palette, the default CSS ‘active/focus’ highlight might blend in the background and become virtually invisible.
- Put yourself in the shoes of a Keyboard User. If you were interacting with the component, how many clicks do you think it should take to perform a specific action?
Map out and test simple and complex component navigation using the keyboard and see for yourself how accessible it is. Remember, accessibility is just as much about ease as it is about availability.
Consider this full-page take-over modal below. If you were a user who wanted to dismiss this modal, how would you do it?
In this example, there appears to only be two obvious escape routes but in reality, there are three. While tabbing through the modal, a keyboard user can do any of the following:
- Use the escape key
- Select the close icon
- Disagree with the terms.
By giving users multiple escape routes, this modal has become more accessible and easier to navigate.
3. Remember to always talk to your developers about how the component should work for The Keyboard User. Be a part of the QA process, test and make sure keyboard navigating through your components is as smooth as possible.
The User Constantly Disrespected by Audio Content
If you’re adding audio or video to a component please keep users who are hard of hearing close to your heart. Adding video components that are for streaming captions can sometimes leave users who are members of the Hard of Hearing Community out of the loop.
- Set strict guidelines for video components and ensure that uploaded audio or video files include captions and/or transcripts.
- Transcripts: A plain text depiction of speech or audio content, where no time information is attached to it. Benefits of transcripts include improved comprehension of content by second-language listeners, increase user interaction among hard-of-hearing users, and sometimes it can help with SEO.
- Captions: Transcript text divided into ‘small chunks’, time-coded, and synchronized with video audio. Their benefits include making content accessible to hard-of-hearing users, individuals in sound-sensitive environments, and providing comprehension assistance for individuals who are not native speakers of languages used in audio.
- Accompany sound notifications with visual indicators, so hard-of-hearing users are able to stay notified and informed.
- Don’t forget to talk with your developers, content owners, and marketing team members about making captions and/or transcripts for audio content throughout your product.
If you account for these four different types of people when designing your components, you can easily make your design system more accessible for everyone. You’ll also check off a nice portion of WCAG and The A11Y Project’s accessibility checklists in the process. It’ll make for a more accessible Design System, a better product, and you a more accessible designer.