week11y issue 141

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.

Accessible Front-End Patterns For Responsive Tables (Part 1)

Adrian Bece writes two in-depth articles about implementing responsive tables.

He shares Adrian Roselli’s JavaScript snippet that applies the correct ARIA roles to table elements, which are to ensure that browsers continue to keep good table semantics even when certain CSS styles are applied. The snippet is from 2018, but an update in December 2022 suggests it is still needed for Safari. Note that the JS itself isn’t needed, but the resulting markup, which you could add to your HTML manually or in a preprocessor.

Tables should have a <caption> element as the first child, with a nested heading describing the contents of the table. If it can’t be the first child – e.g. because you’ve added a wrapper element to make the table scrollable – you’ll need to include the table in a <figure> element, use a <figcaption> for the title, and apply a aria-labelledby to the table’s wrapper.

Small / simple tables can be made neatly responsive with table { width: fit-content }, to remove any unnecessary space when viewing on larger screens. For tables with lots of columns, it becomes necessary to horizontally scroll, by applying an overflow: auto to the wrapper element, alongside a tabindex="0" to make it usable for keyboard users.

Some OS’s hide scrollbars by default (I’m looking at you, macOS!), so you may want to consider adding a shadow gradient to indicate the table is scrollable. With background-attachment: local, local, scroll, scroll;, you can subtly hide and show the shadow on either ‘edge’ of the table depending on the direction you scroll. Another visual cue to let the user know a table is scrollable is to force a crop of the last visible column. You may want to consider making the table headers sticky, to keep them in view as you scroll.

Adrian then discusses the stacking approach; useful for tables where the data isn’t supposed to be ‘compared’, e.g. a table of people and their contact information. In the demo, each ‘row’ gets pulled into its own ‘block’ on smaller screens. But this can make pages very tall on mobile. An alternative is the accordion pattern, where you may choose to only show the primary data column (e.g. user’s name) on smaller screens, with a button to expand and reveal the other columns as needed (see demo). Another space-saving option is to give users the ability to show/hide columns.

In Part 2, Adrian looks at patterns for much larger tables, including how to improve their rendering performance by either paginating the results, virtualising the rendering (i.e. keeping the table in memory but only rendering the number of DOM nodes you need in view), or exploring the CSS contain: strict property. Adrian also touches on JavaScript libraries for enhancing tables, and some other special use cases such as rendering calendars.

When CSS Isn’t Enough: JavaScript Requirements For Accessible Components

Stephanie Eckles shares those scenarios where you need a sprinkling of JavaScript to make components accessible. The TLDR is that these include “tooltips, modals, tabs, carousels, and dropdown menus”. Components marketed as “CSS-only”, that use methods like the “checkbox hack“, often do more harm than good.

As a quick sense check, ask yourself the following:

Does the feature include showing and hiding of content? If so, you need JS to at minimum “toggle aria and enable closing on Esc“
Is the natural focus order the most ideal? “If the natural order loses the relationship between a trigger and the element it triggered, or a keyboard user can’t even access the content via natural tab order, then you need JS to assist in focus management”
Does the effect rely on hover and/or focus? You may need JS to make an alternative solution “for touch screen users and those using desktop zoom of 200%+ or magnification software”

Tooltips should be used as a last resort. Ask yourself why you’re adding this text to the UI, and where else it could go. But if you do use one, make sure it’s dismissable without moving hover or focus, that its contents can be hovered without it disappearing, and that it doesn’t disappear based on a timeout.

Modals, as we’ve covered in previous frequent11y issues, would ideally be implemented with a HTML native <dialog> element, but it isn’t currently accessible. Custom solutions need JS because it should be dismissable with the Esc key, and the keyboard focus should be trapped inside. As to what to focus on when opening the modal, Stephanie’s presented a decision tree.

Tabs need to toggle aria-selected to true for the current tab, create a roving tabindex to “distinguish tab selection from focus”, and move focus by responding to arrow key events, all of which require JavaScript. NB: a roving tabindex is a way of programmatically controlling the focus order of elements, e.g. by setting the selected tab to tabindex="0" and all the others to -1.

Dropdown menus need JS, even though we now have CSS’s :focus-within property, because we still need to toggle aria-expanded, be able to close the open menu button with Esc and implement arrow keys for navigating between menu items.

Carousels are notoriously considered a bad design pattern, but if you’re going to build one, you’ll need JS to provide paginated and prev/next controls, as well as auto play.

“I Used The Web For A Day…” series

I said earlier that I’d written some articles for Smashing Magazine in the past. As this issue is a Smashing Mag special, I thought I’d share those articles with you now! Mine was a short series on using the web for a day, but with a limitation: to highlight barriers to accessibility and provide tips on how to build a better web.

You can read the articles below:

Did you know that you can subscribe to dai11y, week11y, fortnight11y or 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.