Lessons Learned by an Accessibility Professional: Designers Want an Array of Examples

A short reflection on a customer asking for one thing when they really needed more.?

Buttons. They’re ubiquitous in digital experiences. They’re everywhere, and we use them all the time. But, have you ever thought about how much effort goes into designing that button? The colors. The font choice, size, and spacing. Even the rounded or square corners. Or the pains a copywriter goes through to find just the right words to clearly and succinctly express to you the action you can take??

Suffice it to say, a ton of effort that goes into creating even the smallest digital element like a button. But, one cannot design just a button by itself in abstraction. There are a variety of button types, typically denoted as primary, secondary, and tertiary, as shown in the following image.?

And don’t confuse your buttons with links, for goodness' sake! A button is a button. And a link is a link. They’re each supposed to look a certain way and function a certain way, not to be confused. Yet, not only should they be visually differentiated as distinct entities, but they still need to visually convey that they’re part of a larger family of elements that share certain properties, where these varying properties convey different meanings. ?

For example, in the following image, these same primary, secondary, and tertiary buttons are displayed in their default, hover, and focus states. Accompanying them are a standalone link and an inline link, also displayed in these three states. What’s great about these designs is that the meanings they convey remain consistent within an element family (buttons for instance) and between element types (buttons to links, for instance). ?

It’s not as easy as it may seem. And these are the types of challenges that designers face every day. How do you build a set of digital elements that are all on brand, convey their set of states, meanings, and interactivity in similar ways, and are somehow accessible for every user? ?

It’s that last bit that’s the most nebulous part. How do you even know what all the required design decisions are from an accessibility standpoint, let alone within an element family or between element types? This is probably the biggest hurdle modern design teams face—the inability to apply the Web Content Accessibility Guidelines (WCAG) to specific elements / components. There is no direct mapping.?

At Level Access we’ve been tackling this problem ourselves for the past few months. We embarked on creating an accessible design system for our software platform. I was eager to share our designs with some customers who were struggling to ensure the accessibility of every element in their own design system. ?

And I was very surprised by their feedback. ?

They thought it was great that we created our own accessible designs, but they wanted to be shown many more examples. They wanted an array of potential options for accessibly designing individual elements, such that they could choose some of the properties to use in their own designs.?

And it makes sense. Level’s designs are just one application of styling and interaction these customers could consider. Unfortunately, there aren’t a lot of design-focused examples where we can point people that are WCAG-conformant. Those that do exist tend to be developer-centric (in my opinion) or not wholly accessible. So, we ended up reviewing an array of examples, identifying properties they liked and didn’t like, and properties that may or may not work in their design systems. All the while, we discussed the aspects of their examples that are accessible, are somewhat accessible, and do not consider accessibility at all. ?

Through this process, I challenged the customers’ thinking by encouraging them to ask?questions like: ? ?

• What are all the ways I can design this element’s [default, hover, focus, clicked, pressed, loading, expanded, collapsed, open, closed, selected, unselected, inactive] state to be accessible??
• When I use a keyboard to interact with this element, what is going to happen and why???
• What happens when a screen reader encounters this element???

I was attempting to tease out guardrails for their accessible design. From experience, I know that, lacking appropriate requirements, examples to plug and play could only take their designs so far. Examples may be what they asked for, but what these customers needed was more than that. It’s not enough to just look at an example and apply some aspect of it to your work; you need to understand the underlying logic powering the example.?

If you happen to be looking for some accessible design examples, check out my webinar on creating an accessible style guide. It includes templates you can download and import into Sketch, Figma, or almost any other design program. And if you’ve got some accessible design questions, feel free to reach out to my team at Level Access. ?