React accessibility: making your React app accessible

Accessible apps and web pages are a requirement for commercial software. But for developers starting out with the popular React framework, the content on React accessibility can look daunting to learn, before the end of the first sprint. So, here’s an entry point into the patterns, structures, do's and don'ts for React accessibility.

This article introduces the key React accessibility concepts, and answers many of the essential questions you might have, so you can start building your knowledge base.

If you're developing a React app with content creation as a requirement, TinyMCE provides a reliable and easy-to-integrate React rich text editor integration, as well as useful accessibility compliance plugins for a familiar rich text editing experience.

How React supports accessibility

React apps run on JSX, a syntax extension of JavaScript. It's part of the fundamental design of the React framework, where the markup that forms the app and the logic that controls it are more closely connected, rather than separated into HTML and JavaScript files.  

Running JSX means that React supports essential accessible design elements like WAI-ARIA attributes. React also makes extensive use of semantic HTML, which is vital to accessibility in web applications (there’s more on semantic HTML in the following sections).

React and web accessibility standards

The essential React accessibility standards and guidelines to know are the: 

• WAI-ARIA standards for designing the JSX structure of your app,
• WCAG guide for making the content of the app more accessible.

WAI-ARIA for React accessibility structure

Web Accessibility Initiative – Accessible Rich Internet Applications (WAI ARIA) is a set of standards to follow to ensure that people with disabilities can access and use web applications. They prevent the exclusion of anyone living with motor, cognitive, audio, or visual differences.

For web designers and app developers, the standards provide useful roles and properties. You can use role and property attributes to introduce React accessibility by using:

• Roles for page structure and types of widgets
• Properties and states to designate objects on the page or parts of the page structure that can change (a checked or unchecked selection for instance)
• Providing keyboard navigation capability around the page structure.

WCAG and React for accessible app content

The Web Content Accessibility Guidelines (WCAG) are a guide designed to improve online content accessibility. Following the guidelines does not guarantee complete accessibility, but when a React app’s content is checked against each guideline, it delivers a consistent experience. The essential accessibility guidelines recommended to know are the following:

1. Use unique page titles – each page needs a unique title. Check on the section React a11y do’s for specific instructions
2. Use Landmark elements to specify important regions – you can use attributes like roles and properties and align with the ARIA standards outlined in the previous section
3. Avoid autofocus on an attribute – and essential step for React apps when setting up keyboard navigation

How to support ARIA in React

There are some specific ways that WAI-ARIA support can work within your React app structure. The following are some introductory standards to consider:

For accessible page structure, use semantic HTML

Without semantic markup, there’s significant risk that screen readers will ignore sections of the React web pages. Screen readers need to be given a sense of meaning from the elements, to determine the relationship between them, and communicate the structure of the page.

For example, a span element could contain a variety of content from a button, to a paragraph, to a heading. Using a specific element (h1, p, button) screen readers can understand the purpose of each page element. React supports semantic HTML, and supports this essential ARIA requirement.

Make use of WAI-ARIA attributes 

You can add specific ARIA HTML attributes for elements and components in React apps. Using ARIA roles provides access to different landmarks of the page structure for screen readers. They make it easier for keyboards to navigate the page.

Choose specific libraries, like react-aria-modal, for focus control

Modals can be the least accessible of elements in the page structure. Making use of a library like react-aria-modal, can create a modal that has useful features such as returning focus to the element focused on just before the modal opened. You can try out the demo to see how the library creates accessible modals in React.

Accessible React components

In react development, a component is an independent code snippet that performs a specific function. They can be reused throughout the application. For example, when building a navigation menu, the nav element has semantic significance. You can add ARIA attributes to the nav to improve accessibility:

1. Applying a role:

<nav role="navigation">

2. Provide additional descriptions:

<nav role="navigation" aria-describedby="A navigation element for the home page">

The nav component is a small example of how a component can be made accessible in React. For more complete examples, there are existing examples of accessible React components you can explore. As another example, developer Andrew James created an accessible menubar component that you can also explore and test out to see how accessible React components can work in production.

React a11y do's

The following are some introductory points to work on when starting out with React accessibility, and are included here to help you start building your knowledge base. More information can be found in the following section on resources for accessibility.

1. Set the document title to convey the nature of the page – the title should answer early questions about concept or action. Some important questions to ask are:
   1. What is this page's purpose?
   2. What do I need to do on this page, what will this page describe to me?
      
      
2. Every form needs to have labeling – similar to the role and ARIA attributes in the previous section, every form must have a label added to meet accessible name conventions.
   
   
3. Creating clear error messaging that can be understood globally – apart from making sure the word choice is clear, contrasting color and easily readable font choices can add to the accessibility of the error messages.

React a11y don'ts

If you’re stuck trying to apply more accessibility standards to your React app, the following items provide a different perspective on accessibility:

1. Don't create modal or dialog components without including a method of returning the focus to where it was in the structure once the modal window closes – React dynamically rebuilds parts of the DOM, and modal components open windows or galleries that move focus around.
   
   
2. Don’t use a generic HTML element when a semantic element exists – when an HTML element has a semantic option available, select that option, and don't use a generic HTML element in your React component.
   
   
3. Don't assume that focus will work effectively for all React app components when keyboard navigation is enabled – while enabling keyboard navigation is a good first step, there are React components that need further configuration beyond basic tab navigation. The following are three examples of such elements:
   
   
   1. Grids of interactive elements – these design elements allow viewers to interact with the content by moving with the arrow keys (directional navigation). While the description and use of a grid in practice evokes a table, using a grid ARIA role does not mean that the grid is necessarily a table. Grid widgets in React apps can take other forms.
   2. Dialog popups – similar to the Modal component mentioned in the earlier section on how React supports WAI-ARIA. There are some nuances involved, such as non-modal dialogs, that can be navigated with the Tab key, as well as alert messages.
   3. Feeds, or infinite scroll pages – these are not a widget, but a structure, and they work by loading new content in response to the scroll event detected from the viewer.

How to test React accessibility

When it comes to checking and testing accessibility in your React app, there are recommended tools available. 

• In your text editor, you can install linters such as eslint-plugin-jsx-a11y to catch any accessibility concerns as you are writing the JSX components of your React App. 
• Later in development, the developer console in your browser combined with the aXe DevTools project can help diagnose and fix any issues. 
• You can also manually test your app in phases with screen readers such as NVDA and the JAWS screen reader.

NOTE: In essence, catch accessibility issues early by using linters, and verify fixed accessibility issues using both the dev console in your browser and aXe DevTools for a faster and more efficient debugging process.

What's the next step for React accessibility?

There are significant resources available, and here’s several to check on next:

• The ARIA authoring practices guide – contains an extensive list of patterns with more guidance on configuring keyboard navigation.
• The React documentation on Accessibility – a complete list of accessible instructions for React apps, expanding on the content explained in the previous sections.
• An a11y compliance checklist – for reviewing and checking accessibility in a systematic way.

If you'd like to find out more about providing accessibility checking for customers creating content within your app, TinyMCE has a powerful plugin available – the Accessibility Checker. It can scan and report on any accessibility issues found within the rich text editor contents. It offers suggestions for improvement, and is regularly updated to keep pace with evolving compliance guidelines.

TinyMCE also has a dedicated React integration available, helping you get TinyMCE integrated into your React app in minutes. Contact our Sales and support team for more information on Accessibility Checker, and TinyMCE for your React app.