May 24, 2022 Smashing Newsletter: Issue #354
This newsletter issue was sent out to 175,541 subscribers on Tuesday, May 24, 2022.
Editorial
We often get entangled in conversations about all the fine details of interface components. And we should! We need to have conversations about the right buttons, the right icons, and the best typographic pairings. Yet perhaps sometimes, we jump into these conversations a bit too quickly.
Like everything else, accessibility is expensive when it’s brought up late in the process, but it’s quite straightforward if we design and build with accessibility in mind from the start. In fact, we’ve even published an evergreen Complete Guide to Accessible Components, which hopefully gives all of us a great headstart for any kind of project.
In this issue, we look into some fine aspects of front-end accessibility — from accessible autocomplete and custom radio and checkboxes to hiding content responsibly, accessibility linter, and how to make content accessible to everyone with purchasing power parity.
On the Smashing side of things, we’ll dive deeper into accessibility at our upcoming SmashingConf SF in-person this June. We still have a few tickets left!
Ah, and of course, accessibility and usability are always a cornerstone of our online workshops and video courses. And we’d be absolutely thrilled to welcome you there as well.
Until then, let’s make the web a bit more accessible, everyone!
— Vitaly (@smashingmag)
1. Accessible Autocomplete
A combobox (also known as “autocomplete”) might seem like a rather straightforward thing to do, but it contains quite some complexity, especially if you want to make sure it is fully accessible and caters for a flawless experience on mobile devices. The team at Adobe created an accessible autocomplete experience for the React implementation of their Spectrum design system. Daniel Lu shares some valuable insights into the component and the problems it solves.
The ComboBox component and React Aria useComboBox hook were tested with screen readers across desktop and mobile devices and with different input methods including mouse, touch, and keyboard. On small screens, the React Spectrum ComboBox is automatically displayed in a tray to give users a larger area to scroll. The autocomplete suggestions can be loaded asynchronously and on demand through infinite scrolling. Furthermore, the React Aria hooks give full control over the rendering and styling of the component. Let’s make autocomplete better — for good. (cm)
2. Hiding Content Responsibly
Sometimes you might want to make something invisible but still accessible for screenreaders. Widgets, offscreen navigation, closed dialogs, or icons, for example. But what’s the best way to do so? It depends on your use case. Kitty Giraudel looks in detail at different techniques to hide something responsibly and when to use which.
In a nutshell, Kitty recommends the following roadmap for hiding content. If you need to hide something both visually and from the accessibility tree, use display: none or the hidden HTML attribute. If you need to hide something from the accessibility tree but keep it visible, use aria-hidden=“true”. And last but not least, if you need to visually hide something but keep it accessible, use the visually hidden CSS declaration group. Be cautious when hiding content, though, to avoid too many discrepancies between the visual content and the underlying content exposed to the accessibility layer. (cm)
3. Pixels, rems, And Accessibility
Should you use pixels or ems? Well, it’s an emotionally-charged question with a lot of conflicting options. Some say, rems are better for accessibility, others say pixels are just fine. According to Josh W. Comeau, it’s not an either/or situation. If you want to build the most accessible product possible, he suggests to use both pixels and ems/rems. In some instances, rems are more accessible, in others, pixels will deliver better results as Josh points out. But how to decide when to use which?
Josh wrote a handy tutorial that teaches you to use your intuition to figure out which unit to use in which scenario. It covers how each unit works, looks at what the accessibility considerations are, and how the units can affect these considerations. To make switching between both as smooth as possible, Josh also shares his favorite tips and tricks for converting between units. A fantastic breakdown of a heavily-discussed topic. (cm)
4. Radio Buttons And Checkbox Styling
In the past, creating custom radio buttons and checkboxes usually involved quite some workarounds due to inconsistencies with Firefox, Internet Explorer, and pre-Chromium Edge. Luckily, Firefox quirks have been ironed out, Edge is now Chromium-based, and Internet Explorer support is being dropped. So with styling limitations largely lifted, what’s necessary if we want to directly restyle radio buttons and checkboxes today? Scott O’Hara takes a closer look.
Good news: There are very few reasons to continue using the good old visually hidden workaround today. It has far too many gotchas to be aware of as Scott points out. To help you style your radio buttons and checkboxes, he explains what you need to account for in your CSS and how to add additional effects like animation without causing accessibility issues. Good to know! (cm)
5. Upcoming Online Workshops
You might have heard it: we run online workshops around frontend and design, be it accessibility, performance, navigation, or landing pages. In fact, we have a couple of workshops coming up soon, and we thought that, you know, you might want to join in as well.
With online workshops, we aim to give you the same experience and access to experts as in an in-person workshop from wherever you are.
As always, here’s an overview of our upcoming workshops:
- Pushing CSS to The Limit Dev
with Amit Sheen. May 25 – June 2 - Designing Better UX With Top Tasks UX
with Gerry McGovern. June 1–15 - DevOps Masterclass Dev
with Denys Mishunov. June 21 – July 5 - Figma Workflow Masterclass UX
with Christine Vallaure. July 7–22 - Effective Usability Testing UX
with Steph Troeth. July 11–25 - Smart Interface Design Patterns UX
with Vitaly Friedman (7h video + UX training) - Jump to all online workshops →
6. Automating Web Accessibility Testing
Maybe it’s a missing alt attribute or a heading structure that isn’t semantic, often it’s little accessibility issues like these that slip our attention and make it into production. The GitHub app AccessLint is here to prevent this from happening by bringing automated web accessibility testing into your development workflow: When you open a pull request or make edits to an existing one, AccessLint is already there, automatically reviewing the changes and commenting with any new accessibility issue before the code goes live.
But what about end-to-end testing with real assistive technology? To make it easier for developers, PMs, and QA to perform repeatable, automated tests with real assistive technology — without having to learn how to actually use a screen reader — Cameron Cundiff built Auto VO. Auto VO is a node module and CLI for automated testing of web content with the VoiceOver screen reader on macOS. If you want to dive deeper into how it works, Cameron summarized everything you need to know in an article. Happy testing! (cm)
7. Purchasing Power Parity
While globalization and technology bring the world closer together, they also highlight the gap in privilege and purchasing power. But we all can make a difference. We can optimize our sites and apps for slow connections and devices with limited capabilities, we can offer alternative payment options apart from the common online payments, and, as independent creators, we have Purchasing Power Parity at our disposal. If you haven’t heard of Purchasing Power Parity yet, Sophia Lucero wrote a fantastic blog post that dives deeper into what it is all about.
Purchasing Power Parity means that you offer variable pricing depending on a country’s purchasing power, i.e. you give a discount to customers based on their location. The calculation could be based on personal reasoning, but there also are SaaS and APIs that generate discounts that ensure that all customers have a fair chance to afford your product. In her post, Sophia shares interesting insights into the current state of Purchasing Power Parity, helpful resources, and ways to implement PPP. By the way, the concept also brings along benefits for the creator: By making your product more accessible and affordable, you might experience higher sales and a growing customer base. A win-win situation for everyone involved. (cm)
8. Ethical Design Resources
As professionals in the tech industry, we all have the responsibility to put ethics at the core of the products we build. If we don’t, we risk that they cause serious harm. Think of predictive policing software that’s biased against Black people, products that reinforce gender stereotypes or exclude non-binary folks, or websites that simply aren’t accessible. But what do we need to consider if we want to do better?
In their Ethical Design Guide, Sarah Fossheim collects resources on how to create ethical products that don’t cause harm. The topics that the books, articles, courses, and tools cover range from bias in AI and inclusive design to LGBTQIA+ and race. More links will be added continuously.
Another fantastic resource is the Ethical Design Network. Founded by Trine Falbe, it is a space for digital professionals to help them share, discuss, and self-educate about ethical design. The network features a growing library of tools, software, and other resources focused on, and built with, ethical design. There’s also a Slack community and a monthly event to inspire and empower each other. Two wonderful initiatives. (cm)
That’s All, Folks!
Thank you so much for reading and for your support in helping us keep the web dev and design community strong with our newsletter. See you next time!
This newsletter issue was written and edited by Cosima Mielke (cm), Vitaly Friedman (vf) and Iris Lješnjanin (il).
Smashing Newsletter
Front-end, design and UX. Sent out 1× a week.You can always unsubscribe with just one click.