When given the choice between an accessible bathroom or a non-accessible one, many people would pick the accessible one: there’s more space, it’s more comfortable, it’s a no-brainer. Digital products are the same. When given the choice, people naturally prefer what’s easier for them to use, to read, or to understand
But designers tend to be reluctant to follow accessibility standards — the design practices that help people with visual, motor, auditory, cognitive, or other disabilities make the most of a digital product. Accessibility is a complicated subject, and sticking to those standards is often perceived as a creativity inhibitor, which might turn a sensible design into something that looks more like a road sign:
Crossing the Slack interface with caution tape colors: what designers think when they hear “accessible” 🙁
But accessible design helps everyone. It improves experiences not just for people with disabilities, but for people in temporary situations where their usual way of interacting with your product won’t work — say, if they’re outside and can’t see their screen well or if their mouse runs out of battery and they can only use their keyboard.
Accessibility is not a constraint: It is a design philosophy that encourages you to make better choices for your users, and helps you focus on what really matters. Simplicity will always be the most difficult target to reach in a design, and accessibility can be one of the best tools to get you there. Slack has been investing more resources to focus on accessibility in the last few years, and what was originally perceived as an extra burden turned out to be one of the best things that ever happen to our design team. There are a million different ways you could implement accessibility in your process, but here are a few that are working really well for us.
Narrow down your choices
The typical design process can feel like a succession of micro decisions, most of which tend to be hard to explain individually. Why would this color work better than another? Why would this font size be more appropriate? This famous quote from Douglas Bowman resonates a lot with designers:
A team at Google couldn’t decide between two blues, so they tested 41 shades between each blue to see which one performs better. […] I’ve grown tired of debating such miniscule design decisions. There are more exciting design problems in this world to tackle.
Having a good, thought-out reason to make those micro decisions is essential to keep your product moving forward, and this is exactly what accessibility standards can give you. For example, only using accessible colors will help you narrow down your choices, so it’s easier to make a decision.
A smaller subset of colors meets accessibility standards, which simplifies design choices
If you’re making your decisions in service of a goal, accessibility, they’re much easier to defend. People can disagree with many of the choices you make, but it is infinitely harder to argue against a decision that makes your product accessible to more people. Between the blue that the CEO prefers and the one that you prefer, you will always lose, but if your blue is accessible, then it stands a much better chance.
This process is true for many aspects of design. Here at Slack, for example, we used to display the list of keyboard shortcuts inside a modal (a pop-up window, if you prefer). Eventually, we had enough shortcuts to start looking into making this modal scrollable. That’s a trivial technical change, but as we were looking into the potential accessibility issues, we realized that people with short term memory impairment could really struggle using this modal, as they had to close it in order to try the shortcut, effectively hiding the shortcut that they are trying to use.
Our previous keyboard shortcut modal required scrolling
Our solution was to move the panel into the right sidebar, so it could be left open while trying the various shortcuts (you can open it using Cmd/Ctrl + /). By designing for a small portion of users, we ended up creating a much better experience for everyone, as you don’t have to constantly open and close the modal to learn new shortcuts. Furthermore, this solution was much more flexible for adding new shortcuts to the list, and allowed us to even make some of the items clickable to preview the feature without needing to use the shortcut. What’s more, this was also simpler for our engineering team to build.
Our new keyboard shortcut panel opens in the right sidebar
We’ve also drawn on accessibility principles to improve the design of our custom status modal. A custom status in Slack is a way to quickly communicate to your teammates what you’re up to right now: commuting, in a meeting, on holiday, etc. When we first released custom statuses, the interface was entirely contained inside of a menu item.
Our first version of the custom status form used a submenu
But a form inside a menu item is a big problem for screen readers, who are expecting a menu item and have problem reading a form in this context. So instead we decided to use a modal to contain the form. Not only did it work better for screen readers, but it was also a more flexible solution that allowed us to introduce new features like status expiration, or having a keyboard shortcut (Cmd+Shift+Y) to open the modal, which is not something that would have made sense for a submenu.
Our new custom status form, in its own modal
With this solution, it was easier for everyone to summon the form without using their mouse, which on top of being a great accessibility improvement, resulted in a significant usage increase for this feature since launch.
Train your team
Designing for accessibility doesn’t happen overnight; it can take some time to make your team or your company understand its value. But by backing up your design decisions with accessibility principles, you can start to build robust design patterns that will make your team’s life much simpler.
Back in 2016, Slack was using more than 130 different colors, 32 of which were different shades of blue. It wasn’t immediately seen as a problem until we raised the accessibility flag. If we ever wanted to adopt some form of accessibility standards, we needed to regain control of our colors. In a surprisingly fast process, we managed to reduce those colors to 18. This smaller palette was much easier to manage both for designers and engineers.
Slack’s original colour palette on desktop: more than 130 colors
Fast forward to today, engineers are often the first ones to point out if a color is outside of our existing palette, as it is more work for them to create a new color than to use an existing one. This also comes with the guarantee that if we are not creating new colors, we are much more likely to meet accessibility standards.
Slack’s new color palette on all platforms: 18 colors!
This new system also simplified the process for the design team. We often don’t need to specify what color to use in our design specs, as they are quite self explanatory. This is less work for designers, less work for engineers, and a more accessible outcome.
With this new set of colors, we could more effectively start to work on the most pressing accessibility issue we had, which was the low contrast elements in the interface. A more contrasted interface is easier to use for everyone, not just people with vision impairments. But the transition to a more contrasted interface can be difficult at times. Whenever we would make a portion of the interface darker to meet accessibility standards, the immediate feedback was that it was too dark, too polarizing. People are used to the existing interface and don’t even realize the effort they have to make to use it. But after a few days, when the dust settles and they get use to the new colors, if you show them how it was before, they tend to have the exact opposite reaction. Suddenly they realize that they always had to make an effort to see the interface, even though their vision was completely fine.
Our previous, faint input field, and our current input field with sufficient contrast
Making the interface more contrasted ended up making it more comfortable for everyone. Once people experience this, they will be much more accepting about using accessible standards all across the interface.
Own your craft
One of the values we hold dear here at Slack is that if you’re not doing it right, then it’s not worth doing at all. Same goes for accessibility: It’s not something you can only do a little bit. When you start seeing accessibility as this magical ingredient that forces you to make things the right way, it becomes crystal clear that you need to apply it to every aspect of a product: from design to engineering, from marketing to customer support. For this to be possible, as a designer, you should feel empowered to completely own accessibility. Don’t assume that engineers are fully aware of accessibility standards, don’t assume that project managers have it on their list, don’t assume that your QA team is testing for it. Own it, teach it, help build the process, make it easier for everyone to understand the game. It is always more fun to play a game when everyone understand the rules.
Thanks to Valerie Ross and the writing team at Slack for making this blog post a million times better than my original submission.
———