As part of a usability study focusing on accessibility, we recruited people who are blind or low vision, all of whom use screen readers regularly. One of the goals of our study was to learn more about our participants’ overall online shopping habits.
Two takeaways from the study were:
On a broader level, according to the Centers for Disease Control and Prevention (CDC), 27% of adults in the United States have a disability of some kind. Of this group, 12.1% have a mobility disability, while 4.8% have a vision disability that includes blindness or significant difficulty seeing, even with glasses.
Combine all of that data and it starts to become clear that there are a lot of potential customers abandoning online stores that aren’t accessible, which leads to those businesses leaving a lot of money on the table.
Generally accepted as the global standard for accessibility, WCAG 2.1 Level AA has 50 different success criteria. On top of that, there are other standards (HTML and ARIA, for example) and best practices (how to build a modal dialog, among others). That’s a lot for a Product Designer to remember.
So instead of asking you to remember all of that, I offer you a bit of a shortcut:
These rules won't cover every accessibility issue that may come up in your workflow, but they will cover the most common and problematic issues that I’ve had to deal with throughout my career.
Now let’s look at some practical scenarios where those rules come into play.
People who might benefit from this:
Let’s talk about a common design pattern: the tooltip.
Mouse interactions with a tooltip are so heavily implied that it becomes easy to forget about keyboard interactions.
So how does a keyboard user “hover” over an icon? They can’t, but they should be able to use the Tab key to navigate to that icon.
By default, the Tab key allows a person to navigate a site by moving the focus between every interactive HTML element. This includes links, buttons, and form fields. The Tab key moves you forward and the Shift+Tab key combination moves you backward. Try using the Tab key right now to see how this works.
Now, think about that as it applies to the tooltip. For a keyboard user to activate that tooltip, they need to be able to use the Tab key to get to the element that triggers the tooltip. So that icon needs to be more than just an image. It needs to be an element that the Tab key recognizes as something that it can interact with. We use a button with an aria-describedby attribute that points to the tooltip content, but you can do it in a way that works for your team.
While more complicated interactions will require more complicated keyboard interactions, you can cover a lot of common scenarios just by understanding how the Tab key works. So start there. And be sure to talk it through with your Engineering partners so that everybody understands how things will work for people who use a keyboard to navigate.
People who might benefit from this:
Let’s say that you have designed a basic form. Your form has fields for a person’s first name and last name. Both fields are required, as shown here.
If any of the fields are empty when the user submits the form, we want to let them know that the form has errors. What if all we did to indicate those errors was to make the borders of the form fields turn red, as shown here?
In this situation, you would be relying on the user to see that the borders are now red. Then you would also need for them to know that a red border indicates that there’s an error. If the person viewing your form can’t tell that both borders are red, they likely can’t tell that both fields are now in error state.
This doesn’t mean that you shouldn’t use colors to indicate errors. Just be sure to include additional information that clearly describes that the fields are in error state. And when it comes to clearly describing an error state, it doesn’t get much clearer than using words that tell a person what’s wrong, like telling them that required fields cannot be empty, as shown here.
People who might benefit from this:
While we’re on the topic of forms, let’s break the idea of a form down a bit. A form is a series of questions that you are asking your users to answer. Like a conversation happening between you and your customer. So rather than thinking about designing a form, imagine that you are designing that conversation.
This is helpful for accessibility since this is pretty much how a screen reader user might interact with the form. A screen reader will announce content in the order that it appears in the code. Although the order of content in the code can differ from the order it appears visually, for this section, we will assume that the visual order of the content is the order that the screen reader will announce it.
Let’s say you’re onboarding a new customer. What information do you need to be able to set them up? We’ll say that we need these:
Here’s a pretty basic design showing how you might set this form up.
So now that you know the questions that you need to ask, let’s imagine a quick script for how this conversation might flow:
Me: “Hi there. What’s your name?”
Customer: “Jack Burton”
Me: “What’s your phone number?”
Customer: “555-555-5555”
Me: “That’s a lot of fives. What’s your email address?”
Customer: “jack@theporkchopexpress”
Me: “Oops. You didn’t give me a complete email address.”
See how you just accounted for an error message in the conversation? That’s excellent. Immediate feedback that something is wrong is a great way to drive a conversation forward. You can’t finish this conversation without getting the full email address, but you also have a few more questions to ask, so let’s take this opportunity to step out of this exercise and see how it maps to designing a form.
Here’s what this conversation might look like as a form up to this point.
Two things to note from this screenshot: we have informed the customer that we need their full email address, and we have disabled the Submit button so that they can only submit this form once all required fields are valid.
So let’s see how that might play out as the conversation continues:
Customer: “I’m on a roll, so how about I come back to the email address once I’m done with everything else?”
Me: “Sure thing. What’s your home street address?”
Customer: “I pretty much live out of my truck but my Post Office box address is PO Box 13.”
Me: “City?”
Customer: “Los Angeles.”
Me: “ZIP code?”
Customer: “90009.”
Me: Proceeds to stare at the customer in awkward silence.
Unlike a conversation between two people, our form relies on the design to drive this conversation forward. Unfortunately, the Submit button is still disabled, so there’s no obvious way for the conversation to move on. We already told the customer that the email they gave us was invalid, but they chose to continue before fixing it. What if they got so caught up thinking about how their life as a long-haul trucker has caused them to lead a vagabond existence full of adventure that they forgot about the email address?
That disabled Submit button really is like an awkward silence dropped right into the middle of a conversation. In an actual conversation, we would likely remind our customer that we still need them to correct that email address. But in our current design, we need the customer to realize that something is wrong, then go back through the form to figure it out on their own.
So how might we handle this in our design? For this example, what if we enable that Submit button? When the user clicks Submit, the form validation checks to see if there are any errors. If it finds one, we’ll put the focus back on the field in error. This helps a screen reader user since that would announce both what's already in the field as well as the error message for that field.
Now we can let the Submit button drive the conversation to completion, like this:
Customer: “Alright I’m done giving you all of my info!”
Me: “Actually, it looks like we still need a valid email address from you. It looks like you told me that your address is jack@theporkchopexpress.”
Customer: “Ah. It’s jack@theporkchopexpress.com. OK, I think I’m done now. Everything good?”
Me: “Everything’s great. Thank you!”
People who might benefit from this:
If your team is already using a design system, you’ve got a head start here. Use patterns already defined in the design system when possible. If you’ve already laid a solid foundation of accessibility in the design system, then those patterns may already be accessible. If they aren’t, you can fix the pattern then push that fix out, which in turn pushes instant accessibility out to every part of your site using that pattern.
If your team is already using a design system, then you also probably already have most of your common design patterns defined and set up to be reused throughout your work. Now go back through your system and make sure that you have Rules 1, 2, and 3 covered in each of those patterns.
If you aren’t already using a design system, then this is probably the hardest of the four rules to implement because it can require a lot of initial set-up. At this point, I'd recommend reviewing your existing site to identify all of the patterns that you already use, document those patterns, and call that version one of your design system. You have to start somewhere, so why not start with what you already have? Now go through Rule 4 once more.
Now, it’s probably a good time to mention the one accessibility concern that most people are familiar with: color contrast. Why did I wait until this point to mention what's possibly the number one cause of accessibility issues ever?
Honestly, when I come across color contrast issues, they tend to be a lot easier to fix than they used to be. Within the past five years, the only color contrast issues that I’ve come across that were difficult to resolve were a result of the brand’s color palette not containing any colors that combined to form a high enough contrast, which required company-level conversations about how the brand’s color palette needed to change. Navigating those kinds of conversations is way beyond the scope of this humble post.
But once you have a workable color palette, a design system is a perfect place to define how to use those colors in a way that helps steer designers away from using color combinations that risk being low-contrast.
And if you’re interested in tackling important product and design challenges like these, check out our open roles.
