Simple steps towards accessibility

Building user interfaces that are accessible for everyone is fun but it's also a great responsibility. Even though the very first guidelines to Web Content Accessibility were created over two decades ago, many companies and products still don't pay enough attention to this topic.

Recently I decided to rethink how I approach this topic and curated a simple list of key elements to pay attention to when building accessible interfaces. Here are a few simple concepts to get you started.

Use semantic HTML

HTML is accessible by default. It's as simple as that, yet building web applications with semantic HTML isn't always that easy. That said, differentiating between a button and link element, using correct elements when building forms and structuring layouts with layout specific tags such as header, footer or aside can already get you a long way. This way your document reflects semantically whatever visual hierarchy you might have going on the website.

Add correct data attributes

Not everything is possible with just choosing the right tags. That's especially true for representing relationships between elements or adding necessary context for elements that can be purely visual. In case of creating relationships between elements, HTML forms are the primary example here. Kent C. Dodds has a great, in-depth article on this. For visual elements, it's important to give proper labels and names to images or icons for screen readers.

If something is mouse accessible it should be also keyboard accessible

The de facto interface for interacting with websites or computers, in general, is a mouse. Naturally, user interfaces are designed to have most user actions happen through clicking. But not all users can use this interface, so every mouse accessible element should albo be keyboard accessible. Again, semantic elements such as button or select have all that you need already built-in. For any other case, it's worth checking if an element is focusable (and use tabindex if necessary) and responds correctly to keyboard events.

Use static analysis

Remembering about all of this requires responsibility, so it's worth outsourcing some portion of this responsibility and automating this process. A great example of this is using eslint plugin, here specific to React, called eslint-plugin-jsx-a11y. It enforces using alt text, correct role or aria-* attributes and many others.

Test with React Testing Library

...or use any other library that encourages writing accessible code. React Testing Library is just simply a fantastic example of that in React ecosystem. By promoting getting elements with getByRole queries it forces developers to make sure element have correct roles and accessible names assigned. Not only are your tests then valuable as you're testing only functionality, not implementation details, but they also ensure code accessibility at the same time.

In general, find tools that encourage good practices, whether that's your testing library or visual component library with all the right defaults in place.

Perform accessibility audits

Another step in automating the process is performing audits. Google Chrome gives everyone access to Lighthouse, which is an automated tool for measuring the quality of web pages. One of the checks that can be performed is an accessibility audit. It checks elements related to the HTML document such as roles and correct attributes but also measures contrast between the content and background or checks if the font size is big enough to ensure legibility. Finally, it gives a lot of hints about what should also be verified manually. Lighthouse can also be installed as a package and used as a step of your CI/CD pipeline.

Listen to the user

Users can tell us exactly what they need. Some example of how we as web developers can listen are prefers-reduced-motion and prefers-color-scheme media queries. They give us access to the user preferences about motion and colour respectively. Those settings can simply be a reflection of user's personal preference, but for some people is might express the fact that too much motion in animation can cause sickness or that the content is easier to read in a dark colour scheme. It's worth adapting the UI to the information the user is giving us.

Conclusion

This list isn't by any means complete. It's a high-level overview that helps me navigating around this topic and one I can reference when creating web applications. Each of the concepts mentioned before is a topic for a separate article or even a series of articles. I hope this text can serve as a starting point for a deeper dive and further learning for you as well.

Finally, what are your steps to building accessible UI?