Semantics & ARIA in JS Apps

For any discussion on JavaScript-heavy apps and accessibility, we have to include semantic HTML and ARIA.

It’s pragmatic to use HTML, as it’s less functionality for developers to recreate. Have you seen how many cool things native <select> elements can do? Even the button element is a perfect example of powerful simplicity. Which manager wouldn’t appreciate saving time and money by using built-in functionality?

Create structure and use the right element for the job

Learn the default HTML elements, attributes and properties. I love MDN (opens in a new tab) for this!

Use headings, landmarks, lists, figures, data tables and more to add semantic structure to your pages. These are essential for users of Assistive Technology to navigate and digest web page content.

Use buttons and links for their intended purposes. For buttons, this means toggling UI components and being part of forms. Links are for navigation! Links also require an href attribute to be keyboard accessible.

There are plenty of other elements, too. As tech leads, you should encourage your teammates to use HTML to its fullest potential.

Keep the rendered output in mind

Components are so easy to create in JavaScript these days. Depending on the library, you can become quite detached from HTML rendering in the browser. Don’t forget that your rendered markup has to be accessible. Use web standards, check your output in the browser, run a browser extension like Axe (opens in a new tab), and improve things before they ship to production.

Make sure you understand ARIA before using it

Developers frequently fall into a trap of using ARIA before understanding what it does (been there myself!). It’s easy to get ARIA wrong when it isn’t tested in a screen reader.

Support isn’t always great for some ARIA attributes, either. Heard of ARIA drag & drop, aria-grabbed? (It was never supported and is now deprecated.)

It helps to follow the rules of ARIA (opens in a new tab) and test it regularly:

1. If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

2. Do not change native semantics, unless you really have to.

3. All interactive ARIA controls must be usable with the keyboard.

4. Do not use role="presentation" or aria-hidden="true" on a focusable element.

5. All interactive elements must have an accessible name (hey, we know that one!).