React isn’t accessible? Megan Zlock on why that is far from the truth
Megan Zlock explains why React and accessibility can go hand in hand
As an accessibility advocate and React developer, it makes me sad when I hear statements like this. Especially about a technology so widely used and multipurpose. React is just a library for rendering and re-rendering a dynamic data-driven UI. It does not auto-generate HTML or enforce flawed opinions to your markup structure. Not on its own, anyway. It doesn’t matter which framework you might prefer – any of these can produce accessible websites.
The accessibility concerns you hit aren’t all that different than a typical website, either. However, there are some unique challenges and some steps that you can take to drastically improve the accessibility of your client-side application.
Using semantic HTML is a great general accessibility tip, but it applies a little more here. When you can apply a click event handler to any HTML element with incredible ease, it can lead to some bad habits in your markup. I can’t name all of the keyboard behaviours on a select input, so I prefer to use a semantic select input. Links and buttons are a huge pain point here as well. Don’t add a click event to a div when you can use a button. And if there’s any change to the URL as a result of a click, then that should be a link instead.
ARIA (Accessible Rich Internet Applications) is a specification for assistive HTML attributes which can be applied to your HTML. The implementation of the specification is split into two concerns: roles and state attributes. The role attribute announces and provides assistive navigation to speciality elements and wrappers. There are many state attributes, but the one I use most often is aria-hidden=”true”. This blocks a screen reader from reading anything within that element. This sounds destructive, but it’s really helpful when hiding collapsed content.
One big difference between a client-side app and a typical site is the frequent change of content. This is fabulous, but only when you can see (and expect) the change. For screen reader users, losing the page refresh means losing a clear division between new pages and data. To make this better, announce when data is changing. Create an element toward the top of your app with the attribute aria-live=”polite” and constantly push new messages into that element.
An application may also have more moving elements, like modals or slide-out navigations. As you are opening and closing these things, make sure that you’re managing the user’s focus. I’ll use a modal as an example. When you open a modal, move the focus to the first item in the modal; “trap” the focus within the modal while it’s open; and, on close, move the focus back to the button that triggered the modal. This helps maintain a predictable, usable keyboard and screen reader experience.