By Kate Kalcevich — Interactions on the web are notorious for being inaccessible to people with disabilities and are often part of the most critical functions, such as:
- submitting a job application,
- purchasing from an online store, or
- booking a healthcare appointment.
When you use HTML form elements like <input>, <select>, and <button>, information about the element is passed to the DOM (Document Object Model) and into an Accessibility Tree. Assistive technologies that disabled people use to interact with websites and apps can access the nodes of the accessibility tree to understand:
- what kind of element it is by checking its role, e.g., checkbox;
- what state the element is in, e.g., checked/not checked;
- the name of the element, e.g., “Sign up for our newsletter.”
The other thing you get with HTML elements is keyboard interactivity. For example, you can access a checkbox using the TAB key and select it using the SPACEBAR.
When you build your own custom components or use ones from a framework, you need to provide information about the element using ARIA and build keyboard interactivity for assistive technology users. Static elements like <div> and <span> that are commonly used to create components from scratch have no role, state, or keyboard access.
Accessible Rich Internet Applications (ARIA) is a technical specification that includes roles and attributes that help make web content and applications more accessible.
A role tells an assistive technology user what an element is. A button is very different from a banner. Choose a role that matches the function of the component you’re building.
ARIA roles override an HTML element’s inherent role. <img role="button"> is no longer an image but a button. Use with extreme caution.
If an element has a state (e.g., hidden, disabled, invalid, readonly, selected, and so on) or changes state (e.g., checked/not checked, open/closed, and so on), you need to tell assistive technology users what its current state is and its new state whenever it changes.
While ARIA attributes tell a user what the state is, you still have to write code to make it true. aria-checked="true" doesn’t actually check a checkbox; it just tells the user the checkbox is checked.
Anything interactive on a website or application must be able to receive focus. Every element you can click on should also be accessible using the keyboard.
There are three concepts to remember if you use static elements like <div> and <span> to build interactive components:
- You need to add
tabindex="0"so that a keyboard or emulator can focus on them. - For anything that accepts keyboard input, you need to add an event listener to listen for key presses.
- You need to add the appropriate role so that a screen reader user can identify what element you’ve built.
When you’re building a custom component, check the W3C ARIA Authoring Practices Guide to figure out what ARIA attributes and keyboard interactions to add.
You can validate the ARIA you’ve written by using:
- Accessibility browser extensions like axe or WAVE
- Accessibility linters like axe for Visual Studio Code or ESLint for JSX elements
- A screen reader to listen to the component
- Assistive technology users to test it
Testing with users with disabilities should be a standard practice in any large organization. The users we build digital products for are the experts in what works for them and what doesn’t when it comes to accessibility.
A longer version of this sidebar appeared in Smashing Magazine.
From Horton, S., & Sloan, D. (2024). What Every Engineer Should Know About Digital Accessibility. CRC Press, Boca Raton, Florida.
Know About Accessibility 