Best practices for building accessible React apps
In recent years many companies have started giving importance to building accessible apps. Open-source libraries like Headless UI are gaining a lot of popularity for their accessibility support.
In this blog, I will explain the aesthetics of design, a brief introduction about Accessibility and its necessity before diving into the best practices of Accessibility. A short table of contents is as follows:
- Characteristics of Good design
- Why is Accessibility important?
- Web Accessibility standards
- Checklist for building accessible apps
- Accessibility tools and library
Characteristics of Good design
All companies want their products to reach as many users. The primary factor that one should mainly consider while designing an app is user-friendliness. If an app is easy to use, then the chances to retain or engage the users in the app would be more.
Some key characteristics of good design include:
- Clear, Simple and Consistent workflow
- Good color theming
- Good error/exception handling
- Every user feels comfortable using the app (Accessible to everyone)
- Responsiveness
The list grows bigger and bigger. One could write a separate blog to speak about the characteristics of good design.
Why is Accessibility important?
As we have seen above, building accessible apps is a primary characteristic of good design. But what exactly is Accessibility? And the first answer that popup in most of our minds is “Making the app readable with screen readers”. But it’s not just that.
Web accessibility means designing a product such that every user has equal access to information and functionality irrespective of their ability. It includes people with the following disabilities:
- Visual (Blindness, Low vision, Color blindness)
- Cognitive (Dyslexia, Development disabilities)
- Seizures
- Auditory (Deafness, Hearing impairments)
- Motor (tremors, Muscle slowness etc.)
Building accessible apps have the following additional benefits as well.
- The accessibility guidelines promote writing semantic HTML which in turn boosts SEO (Search Engine Optimization) for your website.
- Your product can also comply with Government laws.
Web Accessibility standards
Web Content Accessibility Guidelines (WCAG) is a set of recommendations published by the Web Accessibility Initiative (WAI) of W3C to make Web content more accessible for all kinds of people.
The accessibility guidelines principle says the content must be “POUR” which means:
Perceivable (By everyone)
Operable (Accessible with both keyboard and mouse)
Understandable
Robust — App works well in current and future user tools (Technologies and devices within reasonable limits)
There are three levels of accessibility compliance in WCAG 2.1. Each of these levels has a set of guidelines which is catered into three buckets like “Must have, should have and could have”
- A: Essential
- AA: Ideal Support
- AAA: Specialized support
An app must adhere to at least level A to be minimum accessibility compliant.
Checklist for building accessible apps
The following is a summary of noteworthy points that one should bear in mind while building a web app.
Root HTML tag with lang attribute
The lang attribute is used to denote the language of the content on the website. It helps search engines to show language-specific results and the screen readers to switch language profiles to provide correct accent and pronunciation.
The lang attribute can be set as follows:
<html lang="en"> <!-- content --></html>
Unique title for every page
The title tag within the head tag should have an appropriate title for every page. The websites should change the title accordingly when users navigate to different pages.
Tools like react-helmet allow you to dynamically change thetitle tag on every page.
Keyboard navigation
Keyboard navigation is a fundamental characteristic for providing accessibility. Many users with disability use the keyboard to access the UI elements. There are also users without accessibility who prefer the keyboard over the mouse to control elements.
If your website has UI elements that are not easily accessible with the keyboard, then your users may get annoyed and leave the website early. Therefore, test your UI with a keyboard always when building components.
The following are some important points that need to be tested when it comes to keyboard testing.
Focus state
The UI elements should have a clear focus state. So if you mark an element with outline:none or outline:0 in CSS, make sure you provide a better focus indicator than the one provided by browsers. You can change the default focus style using :focus attribute.
Keyboard keys
All the interactive elements must be activated by the keyboard as per their semantics. If you have defined event handlers for touch or click events, then the same handler should be triggered for the corresponding keyboard keys.
That is, for example: If you have defined a handler for a button click, then the same should be triggered for pressing Enter or Space key. Apply proper semantics for arrow keys, Tab, Shift + Tab etc.,
Avoid focus traps
Tab through the content of your website to ensure the focus is not trapped within any content.
Tab order — Avoid tabindex greater than zero
The tab order should be in coherence with the logical flow/order of a web page.
- A
tabindex of 0allows elements other than links and form elements to receive keyboard focus. These DOM elements receive focus in the order they are arranged in DOM. This tabindex value is handy when you want to make elements like div or li to be accessible with the tab key. - A
tabindex of -1means an element is not accessible via sequential keyboard navigation but could be focussed with Javascript or using the mouse. - Avoid using a positive value of tabindex because this value determines the order in which the element would be accessed while pressing the tab key. If an element down the page is set with a higher tabindex, it will receive focus before the one at the top of the DOM tree. It creates confusions and must be avoided
Writing semantic HTML
Never use <div> for everything. HTML 5 has several useful tags like aside, main, nav, section, header, footer etc. It helps screen readers and also the search engines to effectively crawl and display search results.
Heading tags
A page must have only one h1 tag and, the heading tags should have a logical sequence in the HTML. For example, an h4 shouldn’t appear before h2 in a webpage.
Hide content correctly
Do not use display:none, or visibility:hidden or hidden attribute because they remove the content from the accessibility tree, making it inaccessible to screen readers. You can create a visually-hidden CSS that hides the element visually without removing it from the accessibility tree.
.visually-hidden {
position:absolute;
border: 0px;
clip: rect(0px, 0px, 0px, 0px);
height: 1px;
width: 1px;
margin: -1px;
white-space: nowrap;
word-wrap: normal;
}Icons
Every icon should have aria-label to describe its purpose. For example, a thumbs up icon should have an aria-label or label tag with the value like “Like post”. If you are using a label tag, make sure you hide it with the visually hidden CSS seen above.
Image with alt text
All images must have meaningful alternative text that is displayed when its loading fails.
Form input controls
- Every
inputortextareamust have alabeltag or anaria-labelattribute associated with it for screen readers to read the inputs. - The
input elementshould have bothrequiredandaria-requiredattributes for the required fields and there should also be a visual indication to imply it. - Invalid inputs must have an
aria-invalidattribute when it is invalid. - Use
aria-describedbyto provide instructions for controls. For example, if your input element should provide the date in a specific format, then the code should provide the instruction as follows:
- The validation errors should always be mapped to the field it describes so that the assistive devices can read the information when an error is encountered.
aria-describedbycan be used in conjunction withrole='alert'to denote errors.
The example binds the input element with the error component using aria-describedby. The aria-describedby holds the idof the error component that is “nameError”
Here is a blog that describes the difference between aria-label, aria-labelledby and aria-describedby.
There are a lot more to explain about input controls. React Spectrum’s Aria has much useful information about Accessibility with form controls.
Provide skip link
Several websites have something similar to this below.
These skip links would be visible only when they are focused using the keyboard. They allow users to quickly navigate to the main content without pressing Tab several times. For example, one would want to avoid traversing through each of the navigation bar items. In such cases, the skip links are pretty handy.
A webpage could have skip links to its most significant sections. For example, Twitter has skip links for “Skip to recommended content”, “Skip to secondary content” etc.,
You can learn more about skip links here
Animations
Some people face problems like nausea, dizziness, and malaise because of animations used on websites. The operating system offers a solution to this problem to opt-out of animations and this value can be read by browsers.
For example, Apple exposes this value to the browser using a media query: prefer-reduced-motion. Websites can read this value and disable the animation.
Here is a detailed article about prefer-reduced-motion and how to use it in React applications to create accessible animations.
Accessibility tools and library
Having known the best practices, it is always easier if a tool verifies at least some of these. Let’s look at some of the tools and extensions that offer support.
Static analysis tools
eslint-plugin-jsx-a11y is a static AST checker for accessibility rules on JSX elements. Since static analysis tools cannot check the values that change at runtime, this plugin alone cannot ensure whether a web app is completely compliant with accessibility guidelines.
Libraries for React components
Use some version ofaxe-core to automate A11y testing. The following tools depend on axe-core
- @axe-core/react allows you to test accessibility at runtime. You can run
axein the development environment like below.
if (process.env.NODE_ENV !== "production") { const axe = require("@axe-core/react"); axe(React, ReactDOM, 1000);}
- jest-axe can be used with both
Enzymeand@testing-library/react. But, I highly recommend using@testing-library/reactoverEnzyme. - cypress-axe can be used to test Accessibility in the entire application for different user actions
Extensions
Deque Axe is also very handy to test accessibility on applications.
Although these tools automate/reduce the efforts of some manual testing, this alone does not ensure a website is 100% accessibility compliant. We should put ourselves in the shoes of an end-user and test each page/component when we develop.
Finally, here is an excellent video from Sara Soueidan where she explains how one could manually test accessibility using the Voiceover tool and how one should layout elements effectively.
Conclusion
Building accessible website is gaining a lot of traction and there are also laws enforcing the importance of accessibility. So, let’s make the web accessible to everyone irrespective of their ability :)
