August 31, 2021 Smashing Newsletter: Issue #316

Editorial

Front-end accessibility lies at the very heart of the work we all, designers and developers, do on the web. Although we’ve learned a lot throughout the years, there is still so much that remains to be learned.

In this newsletter, we highlight some of the less-known accessibility issues that are worth highlighting. How do we document accessibility? How do we assess how accessible a component is? How do we design in Figma and code in VS Code with accessibility in mind? Well, let’s find out!

If you’d like to dive deeper into accessibility, we’ve got a few useful workshops coming up soon:

• free online workshop on how to find, fix and prevent accessibility issues, powered by our friends at Deque.
• Join Carie Fisher’s Accessible Front-End Components Masterclass with accessibility best practices, guidelines, testing tools and front-end techniques,
• Join Deep Dive On Accessibility Testing with Manuel Matuzović to learn how screen readers work and how to run automated and manual accessibility tests.

Let’s make the web more inclusive, everyone!
— Vitaly (@smashingmag)

1. Documenting Accessibility As A UX Designer

Accessibility is still an afterthought in a lot of UX design teams. An easy but very efficient strategy to help you adopt an accessibility mindset comes from Elise Livingston and her team at Qualtrics. They started to add accessibility docs to all design documents before handing them over to engineering. Not only to improve product accessibility but also to see potential accessibility issues much earlier in the design process.

Elise suggests tackling accessibility documentation in two steps: first, defining keyboard behavior, then, specifying semantic labels that can be understood by assistive technology. If you want to give it a try, Elise summarized everything you need to know about the approach in an article. A great opportunity to rethink your current process. (cm)

2. Third-Party Component Accessibility

Reusable components like custom selects, autocompletes, or date pickers are powerful helpers. However, a lot of third-party components that claim to be accessible turn out to be only partially accessible once you dig a bit deeper. As Hidde de Vries points out, even components that implemented the ARIA Authoring Practices Guide 1:1 can be critical because the guide doesn’t make claims about screenreader accessibility or user experience. So how do you find those components that are truly accessible?

Hidde published a checklist of questions you can ask to have a little more certainty about the accessibility of a component: How did they test? Who did they test with? Are they open about pros and cons of their approach? And who created the component? He also shares some valuable tips from the community that help you assess whether a component that claims to be accessible will live up to its promise. (cm)

3. Automating Accessibility Testing With GitHub Actions

Have you ever considered automating the accessibility tests of your source code with GitHub Actions? No matter if you haven’t gotten around to wrap your head around GitHub Actions yet or just need a little bit of help setting up a proper workflow, Adrián Bolonio’s tutorial is for you. It shows you step by step how to automate your accessibility tests with libraries like axe, pa11y, Lighthouse, and unit tests directly in your GitHub repository.

You’ll learn how to configure your repository so that GitHub Actions are executed as soon as you create or update a pull request to the main branch. If any of the GitHub Actions find accessibility vulnerabilities, the pull request will crash and disable merging until you’ve resolved the found errors. A small detail that makes a big difference. (cm)

4. Upcoming Front-End & UX Workshops

You might have heard it: we run online workshops around front-end 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.

As always, here’s an overview of our upcoming workshops:

• Designing The Perfect Navigation UX
  with Vitaly Friedman. August 31 – Sep 1.
• Vue.js: The Practical Guide Dev
  with Natalia Tepluhina. September 14-28.
• Building Modern HTML Emails Dev
  with Rémi Parmentier. September 16–24.
• Jump to all online workshops →

5. Accessibility In Figma

We all want to design better and inclusive experiences, but sometimes we might be forgetting about just the right color contrast or a proper tab order. Luckily, there are plenty of Figma plugins for accessibility.

Stark, for example, is a full powerhouse on everything accessibility. It includes contrast checking and vision simulators and it also allows you to reorder your sequences in focus order. It also displays the contrast ratio for any two objects that you select. Alternatively, you can use Contrast as well.

For accessible color palettes, Geenes.app is a reliable and sophisticated tool that lets you create, maintain, sync, and test color palettes and their variations. It’s really difficult to imagine any Figma setup that doesn’t have this plugin installed!

And if you need to test how a different font size will impact your layout, Text Resizer helps you see what exactly happens with increased or decreased font sizes.

6. Accessibility Linter For VS Code

If you’re a VS Code user, you might want to give the free axe Accessibility Linter extension a try that the team at Deque Systems created. To help you avoid common accessibility bottlenecks, it checks React, Vue, HTML, and Markdown files for you.

Consistent with the open-source axe-core rule engine, the linter won’t show false positives, so you don’t have to worry about writing ignore flags. To get you up and running immediately, there’s no configuration required, but you can select the accessibility standard and individual rules you want to use, of course. By the way, there’s also a free axe browser extension to expand your test coverage by testing in the browser. (cm)

7. Little Helpers To Pronounce Names Correctly

Business partners, clients, people you got in touch with over the Internet — when meeting them in real life or in a call for the first time, there’s often that awkward little moment when you hesitate to call them by name because, well, you’re not quite sure how to pronounce it correctly. If you want to be well-prepared in situations like these, technology is here to help.

The service NameShouts, for example, works with native speakers and linguistic experts to record name pronunciations for more than 20 languages. Their database already counts over 400K names, so if you are looking for a name, just type it in, select its language of origin, and the search engine will find the audio and phonetic pronunciation for you.

The site Pronounce Names works similarly. You can enter a name to search for its pronunciation, browse the alphabetic list, or add names that are missing in the database yourself.

Another approach to the topic comes from Atif Azam. To remove the initial friction of having to clear up his name when introducing himself, he built Vocalizer, a JavaScript library that you can use on your website to show how to pronounce your name correctly. A clever solution. (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

Useful front-end & UX bits, delivered once a week. Subscribe and get the Smart Interface Design Checklists PDF — in your inbox. 🎁

Your (smashing) email Subscribe →

Front-end, design and UX. Sent out 1× a week.
You can always unsubscribe with just one click.