Getting Started with Accessibility in React

There are a few basic steps you can take to ensure that your web application is as accessible as possible, as quickly as possible. I will provide some further resources if you want to take this one step further at the end of this post.

Keyboard Focus

Keyboard focus is something that is key to note when implementing accessible sites. Users who cannot use other input mechanisms will struggle to interact with your site if you don’t ensure that keyboard focus is properly managed.

The keyboard focus is the current element in the DOM “which is currently receiving keyboard input”. A standard example of a focused element is the blue outline we see around buttons regularly. It is standard practice never to remove this default outline, unless you are replacing it with an alternative implementation.

The ‘google search’ button being keyboard focused.

Due to the regular DOM changes made in React applications, this can lead to problems with keyboard focus. This can include keyboard focus being lost, unexpectedly changed to a different element, leading to frustration of the user, as well as users relying on assistive technologies being disoriented. The React team, therefore, provides guidance on how to programatically control keyboard focus.

React provides Refs in order to modify child components or elements outside of the typical update- and data-flow. These can be used to manage keyboard focus. The ref attribute can be placed on any React component, with a function value. This function will be “executed as soon as the component is mounted or unmounted”. The first parameter of the function will be a reference to the element or the component the ref is on (http://bit.ly/2CfdKPa).

Below I have slightly modified an example of the usage of Refs from here to use React component syntax. This example outlines how the Ref attribute means the keyboard focus is maintained on the text input field after the button is clicked.

While this is a very important accessibility feature, it is also a technique that should be used judiciously. Use it to repair the keyboard focus flow when it is disturbed, not to try and anticipate how users want to use applications. — React Documentation

ARIA

Accessible Rich Internet Applications (ARIA) is a set of attributes that define ways to make Web content and Web applications more accessible for users with disabilities. There is a large set of built-in HTML attributes to define ‘roles’ for an element, to provide more information to users using assistive technology, or providing nice ways to split a page up.

ARIA HTML attributes are fully supported in JSX, and therefore can be used as attributes for elements and components in React. Unlike most attributes, ARIA attributes should be lowercased when declared, but the fundamental usage remains the same as in traditional web development.

You can also use ARIA roles and landmarks to provide programatic access to sections or ‘landmarks’ of a webpage. This will further facilitate keyboard accessibility, as well as allow for skip links to be used. Skip links are hidden links that are only exposed to keyboard users, allowing them to navigate to or past a certain part of your page.

Fragments

Fragments are a pattern used in React which allow a component to return multiple elements, without an encompassing <div> component. Using <div> elements in certain contexts in React may break HTML semantics, leading to difficult-to-understand page structures, or invalid HTML.

Lets say you are building a <ul> (unordered list) where, for every bullet point in the list, you want to return multiple components. You may try to do this:

In this example, <ListItem> would need to return 1 or more <li> elements to be valid. If a parent <div> element was used inside the render function of ListItem then the generated HTML of List would be invalid:

A Fragment would, instead, hold the <li> elements , just like a <div> but without adding another element to the DOM. The example would end up looking like this:

And the output would be valid HTML:

Fragments help keep the HTML valid and understandable, especially to users without access to the visuals of the page, and who may be reliant on screen reader technologies for example.

Setting the Title

Due to the fact that React applications are Single Page Web Applications, the same title value will be used throughout the user’s journey in the application, which isn’t necessarily ideal.

Typically, you can set the title element value in the public/index.html file. This would never change unless you programatically update it throughout the users browsing experience. A popular solution is using react-document-title , an NPM package providing a declarative way to set the title value.

The package allows you to define app- and page-specific titles, which gives the user a better experience, without inserting any DOM element.

As is noted on the w3c site ‘Easy Checks’ article, the page title is shown in the tab bar on most browsers, shown in search engine results, and read by screen readers. You should check that your title is correctly describing the content of the page, and that it is different from other pages on the website as to distinguish the page from other web pages.

Good page titles are particularly important for orientation — to help people know where they are and move between pages open in their browser. The first thing screen readers say when the user goes to a different web page is the page title. — w3c

Usage of this feature is quite simple. Below is the example from the react-document-title documentation (assuming you are using React router).