February 23, 2021 Smashing Newsletter: Issue #289
This newsletter issue was sent out to 180,930 subscribers on Tuesday, February 23, 2021.
Editorial
Building accessible pages and applications isn’t easy. We have to keep in mind how our sites and applications work with a keyboard alone, whether navigation landmarks are properly assigned, how updates are announced by a screen reader, and whether we avoid any inaccessible libraries or third-party scripts. And then, for every component we are building, we need to ensure that we keep them accessible over time.
In this issue, we’ve collected a couple of useful libraries and case studies to get accessibility just right: from accessible modals, tabs, and autocomplete to keyboard navigation and accessible icon links. Our sincere hope is that they will help you improve the accessibility and usability of your products, so next time you have to find a solution, it will be less daunting and more straightforward than before you opened this very newsletter.
And if you are looking for a deeper dive into psychology and usability, we have some online workshops on UX & front-end that you, or your wonderful colleagues, may find useful as well.
Stay smashing, everyone!
— Vitaly (@smashingmag)
- Accessible Modals
- Accessible Tabs
- Implementing App-Wide Keyboard Navigation
- Upcoming Front-End & UX Workshops
- Find And Fix Accessibility Issues
- Support User Preferences With
prefers-reduced-* - Accessible Autocomplete
- Making Icon Links Accessible
1. Accessible Modals
You might have a simple modal or overlay on the page, perhaps to confirm the customer’s input, or to show a couple of photos in a gallery, or just to confirm the user’s preferences. In all these cases, building an accessible modal will turn out to become quite an adventure, also known as a focus trap.
As Eric Bailey explains in detail, you’ll need to identify the bounds of the trapped content, including the first and last focusable item, then remove everything that isn’t within it, move focus into the trapped content, listen for events that escape the boundary, restore the previous state and move focus back to the interactive element that triggered the trapped content.
Ideally, we’d use something as simple as the dialog element in HTML, but unfortunately, it has massive accessibility issues. We’ll soon be able to use the inert attribute to remove, and then restore the ability of interactive elements to be discovered and focused. For the time being though, we can look into Kitty Giraudel’s a11y-dialog, a lightweight (1.6 KB) script that traps and restores focus, toggles aria–* attributes, closes dialog on overlay click and Escape, and even allows you to leverage the native dialog element if desired. (vf)
2. Accessible Tabs
If you’ve been looking for a responsive and accessible solution for tabs, TabPanelWidget might be just what you need. It relies on plain old semantic HTML, is keyboard-friendly and turns into an accordion whenever the tabs cannot fit entirely (thanks to ResizeObserver but there’s a polyfill for browsers that don’t support it).
The script is not only a semantic and accessible solution, but also a responsive and versatile one to help you create Tabpanel and accordion widgets for the web. It is available as a vanilla JS library (or as a widget for View, React and Angular). (vf)
3. Implementing App-Wide Keyboard Navigation
A well-thought-out concept for keyboard navigation benefits everyone: It enables people who can’t comfortably use a mouse, assists screen reader users in interacting with an application, and it provides power users with more keyboard shortcuts to work as efficiently as possible. Usually, keyboard support is limited to specific shortcuts, but the team at Discord decided to go a step further with their application and expand keyboard support to, well, everything.
The case study “How Discord Implemented App-Wide Keyboard Navigation” shares valuable insights into how they tackled the task — and the challenges they faced along the way, of course. One turned out to be particularly difficult: How to consistently indicate where the focus is on the page? As existing solutions for Focus Rings didn’t work out, the team had to build their own solution from scratch and made the code open source. If you’re facing a similar challenge, this one’s for you. (cm)
4. Upcoming Front-End & UX Workshops
The web is beautifully diverse and fragmented, but it provides incredible opportunities, and we want to keep it this way. So as it happens, we have some friendly online front-end & UX workshops dedicated to design systems, web performance, and front-end in 2021.
Our workshops are packed with practical examples, video recordings and friendly Q&A sessions. Each and every workshop has been a truly smashing experience with wonderful folks from all over the world. There are still some early-birds left, with a lil’ friendly discount. Perhaps you’d like to join us and recommend to others — just sayin’! ;-)
5. Find And Fix Accessibility Issues
Does your text have enough contrast? Does your site work well in bright sunlight? And is it usable for people who prefer reduced motion? Built with a focus on accessibility, the Polypane browser offers a number of tools to make finding and fixing potential accessibility issues like these more effective.
If you are already using Polypane, the team published a great blog post that shows you how to use Polypane to audit and fix common accessibility bottlenecks such as contrast issues, page structure, code quality, and more. And even if you aren’t a Polypane user, the post is still worth a read as the tips are universal and bound to help you create accessible experiences no matter which tools you use. (cm)
6. Support User Preferences With prefers-reduced-
Not every user is the same, and while some users love animations, others may have medical issues concerning motion. The prefers-reduced-motion media query lets you toggle animations on and off, but there are even more solutions to manage animations depending on a user’s preference. In his blog post, Elijah Manor addresses different techniques such as @media, matchMedia, and a custom React hook to address CSS, SVG SMIL, and JavaScript animations.
When it comes to making your content accessible to everyone, there’s another prefers-reduced- media query that is worth knowing about — even though it isn’t supported by browsers yet (but you can emulate it in Polypane, Firefox and Chromium browsers): prefers-reduced-data. It indicates when a user wants to use as little data as possible — if their connection is slow, for example, or if data is limited. The Polypane team summarized what you need to know about the media query to future-proof your site already today. (cm)
7. Accessible Autocomplete
Every time you have to deal with a larger data set, be it a map, a data visualization, or just a country selector in checkout, autocomplete can speed up customer’s input massively. But just as it helps with the input, it needs to help with announcing the options and the selection to the screen reader users as well.
AlphaGov, the team behind the Government Digital Service in the UK, has open-sourced accessible-autocomplete (among many other things), a JavaScript component that follows WAI-ARIA best practices. You can choose when to start displaying suggestions, and allows you to display the menu as an absolutely positioned overlay, or select the first suggestion by default. The team also provides a demo page, with a dozen of accessible autocomplete examples and implementations. (vf)
8. Making Icon Links Accessible
It’s not uncommon to have a link or button that visually has no text but consists only of an icon — a compact navbar, for example, or social icons. But how do you make sure that these kinds of icon links are fully accessible? As it turns out, it’s not as straightforward as one might think.
To show how we can do better, Kitty Giraudel dedicated an article to the issue. He uses an icon link consisting of an SVG with the iconic Twitter bird to illustrate the point, and shows step by step how to make it accessible: with a descriptive text that is visually hidden, then removing the SVG markup from the accessibility tree with aria-hidden, and, finally, correcting the fact that svg elements can be focused on Internet Explorer by adding the focusable attribute. At the end of the article, Hugo also shows how to turn all of this into a little React component. A detail that will make a huge difference for a lot of users. (cm)
Smashing Newsletter
Front-end, design and UX. Sent out 1× a week.You can always unsubscribe with just one click.