Accessibility by Design

It’s easy to get so siloed in our specialities that we often don’t take a step back to look at the bigger picture. Recently, I was part of a large redesign and one of the things I needed to focus on was making sure all of the UI components being designed were accessible regardless of the user’s physical capabilities. Accessibility is one of those many things we often think of as an afterthought, something that someone else can review when the design is in it’s final stages, but that couldn’t be further from the truth.

If I asked you to make a new digital product for me that would be largely accessed from a web browser, would you ask me if I wanted it to be responsive? Would you give me the option that it shouldn’t be accessible to the 55% of the growing internet users who primarily access the web through a mobile device? I would hope not. If we think about it, accessing a website through a mobile phone is an accessibility feature since we’re accounting for the user’s choice of device to navigate our product.

Accessibility from the perspective of people who are using screen readers, toggle switches, or other assistive technologies is no different. It’s with that understanding that I’d declare this: products should be designed with accessibility in mind right up front. It’s not about being an add-on, it’s just how things should be designed from this point forward. You don’t need the “accessibility person” on your team, yes be an advocate, but it’s everyone’s job to make sure the UI you’re creating can reach all of your users in a way that’s most appropriate for them.

Styling ARIA State

In having accessibility in mind right from the beginning, one thing that’s helped me is to question when I toggle state-based classes within my component. Instead of toggling a state-based class, I’d offer instead that you should toggle and style the ARIA state being defined by the component. Here’s an example of what I mean:

Traditionally, maybe we have a button that you can click and when you click it, you’ve toggled the class of .button--selected which gives it some type of selected visual state.

<button class="button">Display Details</button>

The button has a class of .button that we’ll use to target our JavaScript.

const button = document.querySelector('.button')
button.addEventListener('click', () => {
  button.classList.toggle('button--selected')
}

During this toggle process however there’s something missing from the component and that’s the ARIA state. The ARIA API let’s us manipulate the browser’s accessibility tree so we can communicate that the button is either selected or not.

<button class="button" aria-selected="false">Display Details</button>

Instead of caring about the class within our event listener let’s instead check the aria-selected state and toggle that.

button.addEventListener('click', () => {
  let ariaselected = 
    (button.getAttribute('aria-selected') == 'true');
  button.setAttribute('aria-selected', !ariaselected);
})

Then for the CSS associated with this state we could use an attribute selector to specifically target the ARIA state to make sure the visual representation of the UI is always in sync with the ARIA state.

button[aria-selected="true"] {
  background-color: red; 
}

This same concept would be just as appropriate for the visual state of menus, modals, or any other UI component where you’re normally assigning a CSS class to change the visual state of a UI component based on an event.

Changing the Way You Think

Designing for accessibility can be a bit of a mind shift, but most importantly it’s about remembering the purpose of the interface. The interface is about creating a medium where the user interacts with a system. Sometimes the interface can’t be interacted with visually, but that doesn’t decrease the importance of someone’s interaction with it.

Think about your UI in non-ideal conditions. Is the environment noisy? Is the user distracted? Is the user unable to see? Is the user unable to use a pointer device? Now what? Remember most importantly that your design is about solving the problem ahead of you and if it doesn’t consider events that might go wrong, it’s more decor than design.