Sophie Au

Software Developer, Web Designer, Tea Enthusiast

Accessibility in React

02 July 2020

The good news is that since React is a library and pretty mcuh forces you to to write vanillla html when it comes down to it, you don't really need to remember many React-specific a11y rules. The bad news are that just because staying accessible isn't hard doesn't mean that there aren't any pitfalls.

Try to avoid divs (especially for interaction)

Now, divs are great and theny have their use cases of grouping element together (for styling or ARIA live regions) but they shouldn't be the default element. In many cases there is a semantic element that has a11y built in. And the argument of 'There's so much native styling on this' (hello buttons) is a bad one, sorry.

Don't make non-interactive elements interactive

React allows you to add onClick handlers to every element. While this is really nice, it can (and often is) muisused terribly. The only elements you should give an onClick to are buttons. With a really good reason maybe inputs and links (the latter only for the non-js fallback). Everything else is off-limits. Unless you want to make sure you've

  • set the related keyboard handler
  • added the tabindex
  • ensured the accessibility labels the user the element is interactive
  • set all states properly

Focus managment

Focus management is a general problem but using a framework/library such as React only makes the problem more obvious. The prime example for where you need to pay attention is fullscreen overlays (e.g. modals): You have your 'normal' app running, the user is happily tabbing through but then an overlay pops up. When that happens you want to set the focus onto that overlay (and announce it with aria live regions). And then when the user the that overlay you want to restore the focus to where it was before the overlay popped up.