This week is a Smashing Magazine special! It’s a great publication – which I’ve written for a few times – and I’ve had some of their a11y articles sitting in my bookmarks for a while. These articles are long and full of useful info, so it’s sure to be a bumper week. Let’s dive in!

Making Sense Of WAI-ARIA: A Comprehensive Guide

An article by Kate Kalcevich, Head of Accessibility Innovation at Fable. She recaps how HTML is parsed into two structures: the DOM and the Accessibility Tree. Assistive technologies access the accessibility tree nodes to understand the element role, state and name. Native HTML elements such as <input> populate both structures automatically, but custom components made up of <div>s and <span>s need extra markup to fill the accessibility tree properly. This markup is called ARIA (Accessible Rich Internet Applications).

ARIA gives extra information about an element, but doesn’t give extra behaviour. For example, adding role="button" to a div won’t make it respond when you press the Enter key, but it does tell the accessibility tree what it’s claiming to be. The ARIA Authoring Practices Guide includes a list of what interactivity should be added to various components such as accordions, buttons, carousels, and the MDN web docs has a complete list of available roles.

Kate cherry-picks some key ARIA states and properties:

• aria-checked ("true" or "false") to indicate whether checkboxes and radio buttons are currently checked
• aria-current ("true" or "false") to indicate the current page within breadcrumbs or pagination
• aria-describedby – used with the id of an element containing extra information for a form field beyond just its label, e.g. examples of the required format for a field
• aria-expanded ("true" or "false") to indicate if pressing a button will show more content (e.g. accordion)
• aria-hidden ("true" or "false") to hide something that is visible, but you don’t want assistive technology users to know about it, e.g. a card component with image and text linking to the same place, but structured as two links; use aria-hidden="true" on one of the links.
• aria-required ("true" or "false") to indicate if a form element has to be filled out before the form can be submitted

And Kate rattles off some of the most common ARIA-related mistakes:

• Using an aria-labelledby attribute with an ID that doesn’t exist
• Adding roles unnecessary (<button role="button">)
• Using child roles without parent roles (e.g. <li role="option"> without a direct parent with role="listbox")
• Using role="menu" for navigation; it’s intended for things like custom menus on right click, not for general site navigation, which is more of a table of contents than a menu. For the latter, use <nav aria-label="Main menu">. Read Heydon Pickering’s Building Accessible Menu Systems for more.

Finally, there’s a section on focus management, how to validate ARIA, and resources for frameworks and component libraries.

Prefer longer newsletters? You can subscribe to week11y, fortnight11y or even month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.