Accessible front-end components: claims vs reality

My mission in web accessibility is to make it easier for people who want to create accessible interfaces. There are many means to that end, from building good understanding of how people with disabilities use the web to providing clear and well-tested code examples.

I mean, if you understand how people use the web with a mouse, it is easier to design a mouse cursor that works for them, or write the code to implement one. This also applies to keyboard, switch controls, voice navigation, touch and screenreaders.

I like the power of reusable components, as they allow for baking accessibility into components, whether in frameworks or vanilla. One day there may be better UI controls in the web platform and/or more accessible defaults in browsers. Now, teams often build their own components (see Smashing’s guide for tips). Of course, not all project teams can always build their own components every single time. This is not ‘Nam, there are deadlines. And so, we commonly use third-party components like custom selects, autocompletes and date pickers.

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.

“Accessible” doesn’t say it all

As accessibility-aware developers, we may look specifically for components that are accessible. Maybe we search the web for ‘accessible X’. If you do that, be aware that there are more components that claim to be accessible than components that actually are usable or great to use for people with disabilities.

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.

Sorry, I realise none of this makes it particularly easy to find accessible components, but I want to be honest. In any case: don’t give up. Remember what Léonie Watson once said about accessibility: “it doesn’t have to be perfect, it just has to be a little bit better than yesterday”. The more research we do, the better informed our choice will be.

Some questions to ask

If we want to have a little more certainty about the accessibility of a component, there are some checks we can do.

How did they test?

It’s good news when a component’s website explains how a component was tested. Usually browser support is listed, sometimes support for assistive technologies like screenreaders is included, too. Maybe they’ve done formal WCAG testing or they have some sort of checklist. They may be running only automated tests, which are good and useful, but limited to things that can be automatically tested (most of WCAG cannot be). Information about the type(s) of testing can help inform us about the accessibility of a component.

Who did they test with?

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).

Are they open about pros and cons of their approach?

Accessibility is not always one size fits all, sometimes there may be caveats to an approach, there may be things that may still be experimental. It’s a good sign if the component developer is open about this. Sometimes there will be an accessibility statement with known issues and planned fixes.

Who created them?

Sometimes I put extra trust if the people or organisations that created components work for the public good and/or in accessibility. Government-backed component libraries like the gov.uk design system, the New Zealand government design system and the US government’s design system contain gems. So do pattern libraries created by accessibility practitioners like Deque’s Cauldron and Tenon UI.

More indicators

I also asked around on social media! Below are some of the tips that were shared there (❤️ thanks all!)

Look at GitHub issues

Marcus recommended to look at GitHub issues about WCAG or accessibility, “their presence would be a warning sign”. Thea said it can also be a “sign that people care”, she suggests looking at activity and discussions on issues. Mitchell agreed: “the quest for optimal usability and interoperability is never done”. Mallory +1’ed too and looks at how authors respond.

Accessibility as an integral part

Sara warned to be wary of treating accessibility as a separate feature rather than an integral part of the work. If there is an accessible version and a non-accessible version, they’ve probably failed that test!

Find specifics

Bogdan would look for specifics of the accessibility claim: which version and level of WCAG are we talking? He and Weston also said to look for which specific screenreaders were tested.

Perform basic checks

Various people said basic checks can give away a lot: do the docs even mention accessibility (Oscar), is there sufficient colour contrast (Martin), does it work with just a keyboard (Brent and Eric)?

Find out about committment

Heather recommended to look at the website of the component; obvious accessibility issues there say something about the claimed commitment to accessibility.

Yakim said we should look at the testing method to gauge how sustainable accessibility efforts are: “are they ongoing and proactive, or are they reactive?”

In his blog post Be wary of accessibility guarantees of accessibility vendors, which is more about accessibility of tools in general, Adrian recommends going on Twitter and searching the company name combined with the #a11y hashtag.

Customisability

If nothing is perfect, why not improve one of the most promising candidates? Martin mentioned licensing: with a permissive license, we could fix any accessibility barriers ourselves. He and Jason mentioned this too: if the component has easy to use APIs and hooks for customisability, we can take matters into our own hands..

Wrapping up

To sum up: not all ‘accessible components’ are created equal, some will work a lot better for our end users than other. In this post I have listed a number of things you can look at if you are considering third-party components.

Thanks Kilian and Bram for feedback on earlier drafts.

Comments, likes & shares (149)

Gerrit Berkouwer, Kilian Valkhof, Sami Keijonen, Johan Ronsse, Steve Lee, Yung Flavor Gravy AKA Chad Farthaus, Frederic Marx, Dannie Vinther, John Kemp-Cruz, Steve Faulkner, Gaël Poupard, Eric Bednarz, Stephanie Eckles, Mike Gifford, Bregt, Rochellyn, Jens Grochtdreis, Colin, Matthias Ott, Alicia Jarvis (She/Her/Hers), CPACC, CSM 🇨🇦, Rik Schennink, Phil Wolstenholme, DevPablo, Rafa Romero Dios, Michelle Barker, Michael Hastrich, Nadhim Orfali, Heather Gray, Martin Berglund, Ian Lloyd, Wes Chang, Paul Smith, Alex James, Sandra, Paul J. Adam, Matt Hobbs, Jake Dohm, Derek, Jake, carokero, Paul Grenier, Ryan Mulligan, Alaa Manchester, Sam Vloeberghs, Paweł Jacewicz, Peter Antonius, Fotis Papadogeorgopoulos, CHRS, Kashkin, Eric Eggert, Nikrooz 👨🏻‍💻, Ivan Wilson, PritiRohra, Nicolas Steenhout, Kasper Kamperman, Alex, Sandrina Pereira, Marcel, Sandra Kallmeyer, Thomas Jaggi, Dhaval Shah, jake 👨🏻‍💻, Peter van Grieken, Marek Lenik, jalbertbowdenii, Joe Lanman, Nikolay Cholakov🙏4❤, Laura Whitehead 💙, nick endle, Alvaro, Tristan, Herman Eberstadt, Ashley Bischoff, Martin J, Rufus Witt, Sibylle Solange, nic, Tamer Aydın, zwergschwein, Manuel Matuzović, Bruce Lawson, Melanie Sumner, anatom5 GmbH, Sigismund Freudenthal, Meagan Eller, Devon Govett, razh, Eric Eggert, Phil Sherry, Simon Willison and Brice G liked this

Steve Lee, Marcus Herrmann, Sami Keijonen, Daniel Mclaughlan 🥰 Moving to Badgetown 🥰, DevPablo, Alicia Jarvis (She/Her/Hers), CPACC, CSM 🇨🇦, de Oostfreese, Heather Gray, Paul J. Adam, Eric Eggert, Sandra Kallmeyer, Dhaval Shah, Peter van Grieken, Joe Dolson, Web Axe, Nikolay Cholakov🙏4❤, Alvaro, Implement the Dis Co., pctgrass, Herman Eberstadt, mallory, alice & bob and Manuel Matuzović reposted this

Eric Bednarz wrote on 2 April 2021:
This topic needs so much more attention. 👍 In my experience the claim "fully accessible" usually just means "ARIA comformance", or with a bit of luck "WCAG compliance". Probing the issue tracker feedback loop for indifference or even hostility is not for the faint of heart. 😑
Dan Denney wrote on 2 April 2021:
Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0…
Bram Smulders wrote on 2 April 2021:
@hdv talking about what to look for when selecting accessible front-end components for your projects 👇🏼
Accessabilly wrote on 2 April 2021:
Must read for my follow webdevs! 📖 What do you ask to find out if the component you want to use from the web is really accessible? 😎
Stephanie Eckles wrote on 2 April 2021:
"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?"
Matthias Ott wrote on 2 April 2021:
Accessible front-end components: claims vs reality, by @hdv 👏 hiddedevries.nl/en/blog/2021-0…
Matt Hobbs wrote on 2 April 2021:
"Sometimes I put extra trust if the people or organisations that created components work for the public good and/or in accessibility. Government-backed component libraries like the GOV.UK Design System ...contain gems." ♥️😍👏
Sigismund Freudenthal wrote on 3 April 2021:
I have the complete same discussions all days. "We tried to make the custom drop down/type ahead/overlay/form to be as much as accessible" and then they wonder why Screenreader users fail. hiddedevries.nl/en/blog/2021-0…
Sara Soueidan wrote on 3 April 2021:
"be aware that there are more components that claim to be accessible than components that actually are usable or great to use for people with disabilities" 👏🏻 Thank you ⁦@hdv⁩ for writing this! (Just saved me so many Twitter rants 😄) #a11y hiddedevries.nl/en/blog/2021-0…
Roberto Scano wrote on 3 April 2021:
Accessible front-end components: claims vs reality. hiddedevries.nl/en/blog/2021-0…
Chris Heilmann wrote on 3 April 2021:
👉🏼 “Accessible front-end components: claims vs reality” 🔗 hiddedevries.nl/en/blog/2021-0…
Baldur Bjarnason wrote on 3 April 2021:
“Accessible front-end components: claims vs reality” hiddedevries.nl/en/blog/2021-0…
Stoyan Delev wrote on 4 April 2021:
Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0…
Pinboard Popular wrote on 4 April 2021:
Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0…
/tmp wrote on 5 April 2021:
Qu'est-ce qu'un composant "accessible" ? @hdv donne quelques pistes (en anglais). #a11y #accessibilité hiddedevries.nl/en/blog/2021-0…
COMMENTSENSE wrote on 6 April 2021:
Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0…
Sarah Federman wrote on 6 April 2021:
This is also great hiddedevries.nl/en/blog/2021-0…
Rogier Barendregt wrote on 6 April 2021:
Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0…
Rian Rietveld wrote on 6 April 2021:
Are you looking for an accessible web component? Do your research! @hdv tells how to check accessibility claims: hiddedevries.nl/en/blog/2021-0…
dailydevlinks. wrote on 7 April 2021:
📝 Accessible front-end components: claims vs reality 🔗 hiddedevries.nl/en/blog/2021-0… #html #css #javascript #webdev
TPGi wrote on 7 April 2021:
‟Accessible front-end components: claims vs reality” hiddedevries.nl/en/blog/2021-0… Questions to ask, and experience from others, on evaluating the claimed accessibility of some front-end tooling.
Adrian Roselli wrote on 7 April 2021:
hiddedevries.nl/en/blog/2021-0… @hdv hits some important points about how and whether to trust the accessibility claims (lies?) from front-end components. He gathers feedback from readers as well. Everyone reading this knows how little I trust all claims, so I approve of this piece.
Frontend Daily 🚀 wrote on 9 April 2021:
Accessible Front-End Components: Claims Vs Reality - hiddedevries.nl/en/blog/2021-0…
Sitemorse wrote on 9 April 2021:
ALL | Accessible front-end components: claims vs reality …if you understand how people use the web with a mouse, it is easier to design a mouse cursor that works for them,... hiddedevries.nl/en/blog/2021-0… #Accessibility #DigitalConfidence #DigitalCompliance
Front-End Front wrote on 10 April 2021:
Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0…
Michael Mathews wrote on 11 April 2021:
'Remember what Léonie Watson once said about accessibility: “it doesn’t have to be perfect, it just has to be a little bit better than yesterday”' #a11y hiddedevries.nl/en/blog/2021-0…
Web Axe wrote on 14 April 2021:
Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0… #webdev #a11y
CSS Basics wrote on 20 April 2021:
Accessible front-end components: claims vs reality, by @hdv hiddedevries.nl/en/blog/2021-0…
ATACNJ wrote on 20 May 2021:
Interesting read hiddedevries.nl/en/blog/2021-0…
Women Who Code BOS wrote on 30 May 2021:
Not all ‘accessible components’ are created equal, some will work a lot better for our end users than others. Here is a number of things you can look at if you are considering third-party components: hiddedevries.nl/en/blog/2021-0…
Pablo Lara H wrote on 31 August 2021:
Accessible front-end components: claims vs reality by Hidde de Vries @hdv #accessibility #frontendcomponents #webcomponents hiddedevries.nl/en/blog/2021-0…
The A11Y Project wrote on 10 September 2021:
"To sum up: not all ‘accessible components’ are created equal, some will work a lot better for our end users than other. In this post I have listed a number of things you can look at if you are considering third-party components." @hdv hiddedevries.nl/en/blog/2021-0…
Web Axe wrote on 1 October 2021:
Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0… #webdev #a11y
This is great, thank you!
For a deep dive into this topic, check out @hdv's blog post: hidde.blog/accessible-fro…
Reading… Accessible front-end components: claims vs reality | hidde.blog hidde.blog/accessible-fro…