Antoine Lehurt

Accessibility is often viewed as making your site work on screen readers. In reality, web accessibility is a subset of User Experience (UX) focused on making your websites usable by the widest range of people possible, including those who have disabilities.

https://a11yproject.com/posts/myth-accessibility-is-blind-people

It’s important to acknowledge that when we talk about accessibility, we don’t only talk about making the website available for people with permanent disabilities, for instance, someone blind or deaf. But, we also include people with temporary disability. Think of someone with a broken arm or a parent with a child in his/her arms. And finally, there could be people in a situation of disability. Like when we have a glow on the screen because of the sunlight. Anyone can be affected in a moment in time by a disability that would prevent us from using a service.

According to the new figures released by the Census Bureau on July 25, 2012, 56.7 million Americans (18.7% of the U.S. population) have some type of disability and out of this number, an estimated 38.3 million (12.6%) have a severe disability.

https://www.interactiveaccessibility.com/accessibility-statistics

Taking accessibility into account means increasing our target audience by allowing as many people as possible to use our services.

And finally, the number of lawsuits in the US has increased by 177% from 2017 to 2018, and we can expect it to continue on that trend. For instance, Dominos lost last year against a blind man named Guillermo Robles. So, by taking accessibility into account early in the process of development, we avoid having to hire more lawyers ;)

With Acast design system Decibel, we aim to have accessible components. It reduces the possibility of having non-accessible interfaces. Still, it doesn’t entirely remove the need for the developer to test their product to make sure that everything fits well together. Therefore it’s important to include accessibility into our workflow.

Accessibility tools

There are several tools available to help us when working on the client-side. It’s easy to miss an Aria attribute, I’ve done it myself many many times, so the tools I will introduce are here to give us some hints about what could be improved.

VoiceOver

VoiceOver is the screen reader for macOS. It helps us to validate that users can navigate between pages or if elements can easily be reached. People using mouses don’t wait to read the full page to make a decision. The same goes for people using screen readers. They don’t wait for the voice over to read the full page to decide what they want to do. I recommend checking Youtube videos from people using screen readers to see how effective they can be. They usually use the rotor to navigate between pages quickly.

As a developer, it’s essential to verify that the page architecture is correct, and all links or interactive elements are available in the rotor.

To open the rotor, we need to press cmd+f5 to start VoiceOver, then ctrl+opt+u. The, we can navigate between the section using arrow keys.

For instance, it can help us catching if a button has a meaningful label. In the screenshot below, the “button” refers to the play button, so it’s complicated for the user to know what the “button” will do.

Another example is buttons that are not implemented as such. It’s common for developers to use <div>s because it’s quicker to style. But, if we forget to add Aria attributes to specify what the div is, the screen reader won’t be able to find it. In the screenshot below, the “sign up” button can’t be found in the “Links.” So people using screen readers or navigating with keyboards won’t be able to reach for the button and join Acast.

On a side note, VoiceOver works better when using Safari. So, it’s recommended to use it while testing with VoiceOver.

Axe

Axe is an accessibility engine that is available through different types of plugins. They make sure that their accessibility tests have 0 false positives. So, they only test violations that they are confident about.

• Devtool plugin (Firefox and Chrome)

Axe can be used as a devtool extension. When opening it in the devtool it will display the list of issues that can be fixed in the current page.

• React plugin (react-axe)

There is also a React plugin that will display the report in the console. You can enable it in the entry point of your react app (where you mount the root component).

import React from 'react';
import ReactDOM from 'react-dom';

if (process.env.NODE_ENV !== 'production') {
  const axe = require('react-axe');
  axe(React, ReactDOM, 1000);
}

• Cypress (cypress-axe)

The Cypress plugin will inject Axe and check the DOM when navigating to a page. It will make your test fail when there is an a11y violation.

describe('doc example', () => {
  beforeEach(() => {
    cy.visit('http://localhost:9000');
    cy.injectAxe();
  });

  it('Has no detectable a11y violations on load', () => {
    cy.checkA11y();
  });

  it('Has no a11y violations after button click', () => {
    cy.get('button').click();
    cy.checkA11y();
  });
});

Tota11y

Tota11y is an accessibility visualization toolkit developed by the Khan Academy. It has several overlaps with VoiceOver rotor and Axe, but I think it’s an excellent complement. I find it useful to review a page for specific elements quickly. For instance, we can check the heading hierarchy and spot if we are misusing a heading level.

The plugin is available for Firefox and Chrome.

Or if an input doesn’t have any label

Aside from these tools, I also recommend using as much as possible React Testing Library selectors to target attributes that the user sees. It’s a good practice to avoid using *ByTestId but instead rely on other selectors such as *ByLabel, *ByAltText, etc.

So far, I haven’t found a better tool than a screen reader to fully test the user experience. Please, don’t hesitate to share the tools you are using to test accessibility.