An accessible carousel sounds a bit like oxymoron — while there are plenty of scripts that provide the functionality, only few of them are accessible. Now there are, of course, accessible range sliders, but carousels are a slightly different component. As Alison Walden notices in her article on "If you must use a carousel, make it accessible", the sighted person is not forced to use the carousel at all, but keyboard users are forced to navigate through the carousel in its entirety. At the very least, a hidden "skip" link could appear on keyboard focus. Also, once the person has tabbed through all the panel sets, focus should move to the next interactive element that follows the carousel.
Data visualizations often contain important information that users have to act upon. While sometimes we can use large numbers with short sentences instead, visualizations can help understand developments and large amount of information faster. But that means that the information has to be easy to understand, and that refers especially to the selection of colors, the way information is presented, labels, legends as well as patterns and shapes. In their series of articles on accessibility in data visualizations, Sarah L. Fossheim highlights useful guidelines and resources around the topic, along with examples, do's and don'ts to keep in mind when designing accessible data visualizations.
Sarah suggests to not rely on color to explain the data, and avoid bright and low-contrast colors in general. Using patterns and shapes in addition to color is useful, and clear language, labels and legends can help clearly explain the data visualization.
In their essence, footnotes aren't much more than jump-links — links to the description of a source, either placed at the bottom of the document, or in the sidebar, or appearing inline, a little accordion. However, as footnotes are jump-links, we need to ensure that screen reader users understand when links are references to footnotes — and we can do it with the
aria-describedbyattribute. The counter for every link would be implemented via a CSS counter. With
:target, we then highlight the row which the reader has jumped to, and we provide a back-link back to the actual footnote place in the content.
Kitty Giraudel goes into detail explaining how to build accessible footnotes, and you can also check how to build accessible footnotes with React and use react-a11y-footnotes to build them in React with Eleventy (thanks to Kitty Giraudel for the tip!).
Whenever our forms provide a binary selection to our customers — on/off, dark/light mode etc. — we could use a toggle switch. The switch needs to serve a couple of purposes: it needs to clearly explain the current selection (and that's clear not that often at all!), it needs to explain that there are two options, and it needs to be obvious enough for customers to understand how to switch between them. When Sara Soueidan was looking into how to build a toggle switch, she of course spent quite a bit of time looking into how to build an accessible toggle switch.
Sara's solution uses two radio buttons, each with its own label, announced to assistive technologies as a couple of separate options, accessible via keyboard, and has no additional ARIA or JS requirements to function. The outcome is a theme switching toggle code example, and you can also take a look at Scott O'Hara's code example.
It's important to note that Sara's radio button toggle switch is accessible because of its two labels. So if a toggle switch does not have two labels, this would not be a pattern to use. You can find markup patterns for toggle switches in Scott's repo. (thanks to Scott O'Hara for the tip!).
It's not uncommon to see viewers frequently using captions when watching a short clip or a lengthy movie these days. We might be consuming the video in a noisy environment, or perhaps we can better understand written language, or perhaps we are currently busy with something else and need to look up something quickly without having to resort to headphones. Beyond that, how often do we use keyboard's
<space>to prompt a pause, or key arrows to move back and forward? Still, many video players and custom solutions don't provide this functionality out of the box.
Accessible HTML5 Media Players provides an overview of accessible audio and video players. [...]
Libraries and frameworks try to fix, or at least fill the gaps, where platform APIs are lacking. Because they fill gaps, that's a kind of tacit acknowledgement that native web APIs aren't sufficient.
Having modern browser APIs lag behind modern libraries and frameworks is how we've chosen to build for the web. I think it's worth explicitly acknowledging the downsides to that approach, one being: because web APIs don't always provide what people need, they're more likely to use a framework. This leads people to think "framework-first" as they build, which means they tend to think "platform-last".
[...] It increasingly feels like all web languages—HTML, CSS, and JS—are compile targets.
HTML is a compile target from authoring in WYSIWYGs, Markdown, or some other raw data source compiled through templating.
JS is a compile target for almost anything these days. You can author in next generation ECMAScript and compile. Or author in a JS superset like TypeScript and compile. Or author in a different language altogether like Ruby and compile. And I haven't even got to compiling framework-specific syntax yet, like JSX for React or SFCs (single file components) for Vue. [...]
[...] Christian Hielman covers ground on this whole topic in his article about teaching HTML and CSS:
The information [about] what an HTML document needs to even allow the browser do its thing isn't exciting.
But it is important. Not teaching HTML by explaining what it means and does results in people re-inventing it.
We've all seen DIV/SPAN constructs that are, in essence, an anchor. And they fail to be keyboard accessible. Then people add some ARIA and a tabindex to make them accessible. Well, not really. It is more important to not flag an automated accessibility test fail than making it accessible.
In this post, I will warn you about blindly trusting accessibility claims and share some questions to ask with each third party component you consider for your project.
Sometimes, 'accessible' means only partially accessible. That's a problem, as accessibility is about making interfaces work for people with a broad range of disabilities (see Diverse abilities and barriers). For instance, what to think of a widget that was made to work with a keyboard, but breaks badly when zoomed in? It has perfect colour contrast, but no HTML semantics? The screenreader experience is excellent, but it is tricky for users who control their system with voice?
Sometimes, 'accessible' means 'has a bunch of ARIA attributes'. In the best case 'has ARIA attributes and keyboard behaviours that exactly meet the ARIA standard'. Sometimes that it is a 1:1 implementation of the ARIA Authoring Practices Guide (APG), a set of examples (not a standard) written by a subgroup of the ARIA Working Group. The APG is an excellent resource if you want to know how to write technically correct ARIA. But… it does not make claims about screenreader compatibility, see ARIA-AT and/or a11ysupport for that. It also does not make claims about user experience, so always be sure to test the patterns with people, or read blog posts from others who tested with people. Lastly, it also does not recommend whether to use ARIA or go HTML-only… it is just about using ARIA. Sometimes, HTML-only patterns are easier to understand for end users. More ARIA does not mean more accessibility.
Testing accessibility is ultimately not about technology, though, it is about making sure the pattern works for people with disabilities. If we look at a component, can we find whether they specifically included people with disabilities? Was a broad range of disabilities included?
Representation matters; accessibility often requires testing a broad range of people, disabilities and assistive devices. When Marcy Sutton user tested patterns for accessible routing, users of screenreaders, voice navigation and switch controls had varied experiences and comments (see What we learned from user testing accessible client-side routing).