How To Choose An Accessible React UI Component Library

Carol Scott
Girl Develop It San Francisco
6 min readMay 17, 2018

Today, May 17, 2018 is Global Accessibility Awareness Day! As React developers, we all want to make our sites accessible, but how?

Making our own code accessible is one part of that equation. There are many great accessibility resources available online for web developers (Google has a great primer, as does Mozilla).

(And psst, if you’re reading this in May 2018, I’m teaching Intro to Web Accessibility & Inclusive Design for Girl Develop It San Francisco on Tuesday, May 29!)

But for those of us who lean on open-source libraries in our React projects, the other part of building accessible websites is picking the right UI component library. It’s possible to have the code we write be accessible, but forget to evaluate the libraries we decide to use until after the product is built.

Earlier this year, I was working on a quick project where I built a scheduling tool with React. Form elements were a big part of my project, and not being a designer, I reached for a React UI component library.

Midway through the project I realized — whoops! — the form elements I was using were not accessible.

Instead of choosing the library based on visuals and checking afterward if it was accessible, I could have spent a short amount of time investigating the accessibility of the libraries I was using before I selected them.

Moving forward, I’m going to investigate the accessibility of a UI component library before I choose it. Here is a quick guide I created for myself to help choose a library. These steps apply to other front-end frameworks as well, but I’m focusing on React UI component libraries today.

1. Can I Use This UI Component Without A Mouse?

Some users of your site are navigating without a mouse. This could be because of a motor impairment that makes it difficult to operate a mouse. Or it could be that a person is using a screen reader. It could even be personal preference (Vim keyboard shortcuts, anyone?).

Before you pick a library, tab through the UI components and find out whether you are able to navigate, select, and interact with them using solely your keyboard.

Example: The very popular React Material-UI, a component library based on Google’s Material Design, has a date picker that is not accessible for keyboard-only users. (This has been fixed in an updated version of the library, called React Material-UI-Next.)

On the left, screenshot of React Material-UI version 0. In this version, you have to manually click on the picker in order to open the dialog. On the right, React Material-UI version 1, called Material-UI-Next. You can tab into it and change the values with your keyboard.

2. Am I Getting Enough Color Contrast?

Whether it’s setting the tone of your website, guiding users through a form submission or providing visual structure, color is an incredible tool. It’s important, however, to make sure that color is not the only way an element is unique (some people have color blindness) and that the color of your elements has enough contrast with the background.

Look at the difference between these two React date pickers below:

A Tale of Two Date Pickers: Above are two screenshots of React UI date pickers, React Toolbox-UI DatePicker (left) and rc-datepicker by buildo (right). Note, I did shrink the React Toolbox-UI screenshot down for use in this blog post, so follow the link for a more accurate image!

In the screenshots above, React Toolbox-UI DatePicker, left, has a great design, but the lack of color contrast means users with lower vision may not be able to easily read the numbers. On the right, rc-datepicker by buildo delivers great color contrast for selectable dates.

The great thing about open-source libraries is that you can customize them as you please — and color contrast can be a quick aspect to tweak. However, it’s helpful to evaluate the original library so you’ll know whether you need to budget time to make the components more accessible.

One tool I love for measuring color contrast — and for checking accessibility in general — is Deque Systems’ free Chrome Extension, aXe. This extension runs through Chrome Developer Tools and even links to outside resources so you can learn the thinking behind various accessibility guidelines.

3. If I’m Using Modals, Where Is The Keyboard Focus?

Whether you call them modals, dialogs, overlays, or popup windows, these cool boxes that open in front of your web content can create some accessibility headaches.

Many of these headaches have to do with keyboard focus. What is “focus”? I like this definition from WebAIM.org:

When an item has keyboard “focus”, it can be activated or manipulated with the keyboard … A basic focus indicator is provided automatically by the web browser and is typically shown as a border (called an outline) around the focused element.

Can you see where the keyboard focus is in this screenshot of a modal from Bootstrap 4.0?

The above Bootstrap screenshot shows an open modal with the keyboard focus on the “Save changes” button (you can tell by the lighter blue border outside the dark blue button). If you had this modal open right now, pressing the ‘Enter’ key would have the same result as clicking “Save changes.”

Managing keyboard focus is a complex topic (the MDN docs on focus are a great primer; Emily Mears wrote a great intro to Web Accessibility in React that covers focus).

But if you are quickly evaluating UI components in order to pick a library, you can check to see if the modals have these qualities: (guidelines from the W3C)

  1. Can the user press ‘Escape’ to close them immediately?
  2. When the modal is opened, is keyboard focus automatically set (so the user does not have to tab through the modal to get to an actionable element)?
  3. When the modal is closed, does keyboard focus return to the original element that the user clicked to open the modal?

Google’s Material Components For The Web is a big winner here — see the below screenshot, and even better, go to the Dialog demo to try it out for yourself:

Screenshot of a modal from Google’s Material Components For The Web

When you visit the demo link, did you notice how the modal closes with the ‘Escape’ key, opens with focus automatically on a clickable element, and after it’s closed, restores focus to the element that was clicked to open it? Awesome!

4. And Beyond

This is just a starting point for evaluating UI component libraries. If you want to go deeper, I recommend:

P.S. What’s My Favorite?

I’m really excited about Material-UI Version 1, which was just released and addresses some of the accessibility issues that were spotted in Version 0. However, it is brand new as of this writing and may have some kinks to work out (you can contribute to the project on GitHub!).

With that said, my personal favorite is Grommet, which I find beautiful, easy to use and was made with an explicit focus on accessibility.

Happy coding, and let me know your favorite UI component library in the comments!

Interested in what GDISF is doing? Check out their workshops on Meetup and follow them on Twitter @gdisf.

--

--