Broken plates, by CHUTTERSNAP on Unsplash

Strategies for building accessibility awareness into your development process

Hi everyone!

My name is Trish, a.k.a. @feesh on the internet, and my pronouns are she/her. Presently, I’m a Front End Engineer at Slack, where I work on our internal design system and component library, called Slack Kit. More specifically, I work with fellow engineers to build React components that comprise the foundational layer of our Slack client, and help to ensure this base layer of components are fully accessible.

A preview of our internal design system documentation for Slack Kit

I’ve been working in the industry as a front end engineer for a bit over a decade at this point, and if there is one thing I am familiar with, it’s failure. But, I’m here to tell you, that’s okay! Failure is normal: everyone fails sometimes, and then we learn, and then probably fail again in an equally spectacular way and learn again. It’s a cycle we all go through, and it’s how we grow as humans.

A fire lizard caught in a cycle of failure

If you’re also a front end engineer, I’m sure you’re equally familiar with this feeling of failure. Browser rendering inconsistencies often feel like you’re in the wild west, web compilers behave like a black box of nightmares, and then there’s that dreaded finishing step of any web project: accessibility.

Good ol’ CSS

Allow me to share a personal story of failure. A little over a year ago I was preparing to launch my first big feature in Slack. I felt like I was on top of the world, this new tool I’d spent months on would roll out to all the folks who use Slack to help make their working lives simpler, more pleasant, and productive. And then, I got a message like this:

In summary this reads, “Hi Trish! Is this the OptionsList? Because this is not accessible with a screen reader at all. Also, congrats on the launch! Sorry for raining on your parade.”

It was really hard for me to not feel like a failure at this point. But, I’m proud to say that at Slack, we treat accessibility bugs as broken functionality, and product blockers. If your website is inaccessible, that means that real humans on the internet cannot use it. And for Slack, where we have over 10 million users daily, being unable to communicate with your teammates, interact with content, or being blocked from doing your work is simply unacceptable.

I’ll be honest, I’m not an accessibility expert. Luckily, this message showed up after an internal launch, flagged by our incredible accessibility team, and was just letting me know that I had a lot more to learn and a little more work to do. Since this time, I’ve learned a ton about the complexities of screen readers, building for inclusivity, and creating accessible experiences. I’m not an accessibility expert, but as it turns out, you don’t need to be to do this work.

So, let’s flip the script, and dive into — “How not to fail at accessibility”

We’re going to cover three main areas:

  1. Testing — how do you know if your website is or is not accessible currently?
  2. Building — once you’ve identified some bugs, how do you code for accessibility?
  3. Process — how can you improve your process to prevent bugs in the first place?

Testing

What does accessibility on the web even mean? It is very broadly scoped, but thankfully also thoroughly documented. The W3C established what is known as the Web Content Accessibility Guidelines, or WCAG. If you check out this lovely doc, you’ll find everything you’ve ever wanted to know about web accessibility in a lengthy format.

A screenshot from the Web Content Accessibility Guidelines on W3C.org

These guidelines break down accessibility compliance to three grades: Levels A, AA, and AAA, with specific criteria for each on what is or isn’t WCAG compliant. Each level defines stricter adherence to supported accessible functionality, with Level A being the lowest level of compliance, and Level AAA being the most strict. At Slack, we aim to meet Level AA for all of our features, and for Level AAA compliance wherever possible.

The spectrum of human abilities and the technology to support them is infinitely broad, and there are complexities that even these guidelines don’t properly address. For now, we’ll get you started on four areas you can test now — the Hello, World of accessibility, if you will — and I’ll let you dig into more nuanced support later. These four areas are: color contrast, user interface zoom support, keyboard interaction models, and screenreader support.

🌈 Color Contrast

When looking at contrast, we’re not evaluating every last color across your beautiful website: instead we’re interested in making sure the information and interactive elements on your website are perceivable and understandable. That means, specifically, the body copy, large text (meaning anything bold 14pt or 18pt non-bold and up), and UI elements on your website, such as iconography and form elements.

A few examples of where to check for color contrast

The best tool for the job here is the Colour Contrast Analyzer, which lets you use an eyedropper or hex code to check foreground and background colors, and will immediately tell you whether or not you meet the criteria at the bottom. It should come as no surprise that light gray text on a white background does not meet the contrast requirement.

A pass and fail example within Colour Contrast Analyzer

🔎 User Interface Zoom

UI Zoom refers to the browser’s built-in zoom functionality that is toggled using CMD or CTRL +/ -. At Slack, our designers provide mock-ups at the different zoom levels we support whenever relevant. The easiest way to go about testing this is to simply zoom in a few levels and spend a day or two looking for broken areas in your interface.

An example of a design for various UI zoom levels

⌨️ Keyboard Navigation

Also known as the Keyboard Interaction Model. This refers to navigating your web content using only a keyboard, most commonly using the Tab and Shift + Tab keys to move forward and backward, and using Arrow keys, Enter, and Esc to interact with UI elements.

Every year in May, our accessibility team hosts a week-long challenge for Global Accessibility Awareness Day where they encourage us to put our mice away in our desk drawers, and spend the week using Slack only by keyboard. I remember trying this last year and finding both how many ways I was able to be more efficient, and also ways where I struggled because I didn’t know what the different common patterns are.

Within the Slack client, we provide this handy palette of key commands to help folks who may have mobility limitations, and also to enable people to become power users of Slack.

An example of the keyboard shortcut panel in Slack, toggled using CMD + /

In addition to keyboard-support, accessibility guidelines require that you indicate what has current focus, visualized here by a fuzzy blue ring.

An example focus ring that follows along as you tab around

An important thing to look out for while you’re testing out your interface is if you notice that you’re able to tab into a section, but then are unable to tab away from it. These are known as keyboard traps and should be avoided.

A cat falling into a trap. Don’t do this to your keyboard users.

💬 Screenreader support

If you’ve fixed up your keyboard interaction model, you’re already halfway there! Screenreaders are a type of assistive technology that audibly dictate what a user is currently interfacing with, particularly useful for folks with low or no vision.

If you have a Mac, screenreader software is built in with VoiceOver. To turn this on, open up Systems Preferences, navigate to the Accessibility tab, and enable VoiceOver. There are equivalent free software options for PCs as well, such as NVDA.

The toggle to enable VoiceOver on a Mac

Here’s a quick preview for what it’s like using a screenreader: you’ll notice as the keyboard focuses on an element, the screenreader will first announce what type of element it is, how it’s defined, and then will update as you’re interacting with it. Can you guess what interface this is just by listening?