Accessible front-end components: claims vs reality

Published 02 April 2021 category: thoughts

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 & mentions (132)

Mallory 07 Apr 2021 11:32:49

Another note, and maybe the only thing I would add to this article: sometimes a component (or other software) will call themselves “accessible” but are using the meaning most people do: availability.
I’ve encountered software whose whole purpose seemed to be accessibility claims, but it was 100% about users in poverty, with crappy networks and low-CPU devices, or people with English as a Second Language (app was geared towards English-speakers) and worked hard to be available in several formats (as an app in both main App Stores as well as 3rd-party app stores; as an app running on a website) and instructions available as text AND videos AND audio-only (literacy reasons).
If we’re accessibility people living in the accessibility bubble, we may look at something like that with big “accessibility” claims, try to keyboard through it once and declare “what liars!” :P
Since disabled populations often intersect with the “availability” or “low-(computer)-literacy” populations though, these companies and organisations are, I believe, perfect for introducing disability-accessibility to!

Gerrit Berkouwer likes this
Kilian Valkhof likes this
Sami Keijonen likes this
Johan Ronsse likes this
Steve Lee likes this
Yung Flavor Gravy AKA Chad Farthaus likes this
Frederic Marx likes this
Dannie Vinther likes this
John Kemp-Cruz likes this
Steve Faulkner likes this
Gaël Poupard likes this
Eric Bednarz likes this
Stephanie Eckles likes this
Mike Gifford likes this
Bregt likes this
Rochellyn likes this
Jens Grochtdreis likes this
Colin likes this
Matthias Ott likes this
Alicia Jarvis (She/Her/Hers), CPACC, CSM 🇨🇦 likes this
Rik Schennink likes this
Phil Wolstenholme likes this
DevPablo likes this
Rafa Romero Dios likes this
Michelle Barker likes this
Michael Hastrich likes this
Nadhim Orfali likes this
Heather Gray likes this
Martin Berglund likes this
Ian Lloyd likes this
Wes Chang likes this
Paul Smith likes this
Alex James likes this
Sandra likes this
Paul J. Adam likes this
Matt Hobbs likes this
Jake Dohm likes this
Derek likes this
Jake likes this
carokero likes this
Paul Grenier likes this
Ryan Mulligan likes this
Alaa Manchester likes this
Sam Vloeberghs likes this
Paweł Jacewicz likes this
Peter Antonius likes this
Fotis Papadogeorgopoulos likes this
CHRS likes this
Kashkin likes this
Eric Eggert likes this
Nikrooz 👨🏻‍💻 likes this
Ivan Wilson likes this
PritiRohra likes this
Nicolas Steenhout likes this
Sandra Kallmeyer likes this
Thomas Jaggi likes this
Dhaval Shah likes this
Kasper Kamperman likes this
Alex likes this
Sandrina Pereira likes this
Marcel likes this
jake 👨🏻‍💻 likes this
Peter van Grieken likes this
Marek Lenik likes this
jalbertbowdenii likes this
Joe Lanman likes this
Nikolay Cholakov🙏4❤ likes this
Laura Whitehead 💙 likes this
nick endle likes this
Alvaro likes this
Tristan likes this
Herman Eberstadt likes this
Ashley Bischoff likes this
Martin J likes this
Rufus Witt likes this
Sibylle Solange likes this
nic likes this
Marcus Herrmann reposted this
Sami Keijonen reposted this
Steve Lee reposted this
Daniel Mclaughlan 🥰 Moving to Badgetown 🥰 reposted this
Alicia Jarvis (She/Her/Hers), CPACC, CSM 🇨🇦 reposted this
DevPablo reposted this
de Oostfreese reposted this
Heather Gray reposted this
Paul J. Adam reposted this
Eric Eggert reposted this
Sandra Kallmeyer reposted this
Dhaval Shah reposted this
Peter van Grieken reposted this
Web Axe reposted this
Nikolay Cholakov🙏4❤ reposted this
Joe Dolson reposted this
Alvaro reposted this
Implement the Dis Co. reposted this
Herman Eberstadt reposted this
pctgrass reposted this
mallory, alice & bob reposted this
Accessabilly replied: 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? 😎
Eric Bednarz replied: 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. 😑
Bram Smulders replied: @hdv talking about what to look for when selecting accessible front-end components for your projects 👇🏼
Dan Denney replied:
Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0…
Stephanie Eckles replied: "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 replied:
Accessible front-end components: claims vs reality, by @hdv 👏 hiddedevries.nl/en/blog/2021-0…
Matt Hobbs replied: "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." ♥️😍👏
Sara Soueidan replied:
"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…
Sigismund Freudenthal replied: 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…
Chris Heilmann replied:
👉🏼 “Accessible front-end components: claims vs reality” 🔗 hiddedevries.nl/en/blog/2021-0…
Baldur Bjarnason replied: “Accessible front-end components: claims vs reality” hiddedevries.nl/en/blog/2021-0…
Roberto Scano replied:
Accessible front-end components: claims vs reality. hiddedevries.nl/en/blog/2021-0…
Stoyan Delev replied: Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0…
Pinboard Popular replied: Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0…
/tmp replied:
Qu'est-ce qu'un composant "accessible" ? @hdv donne quelques pistes (en anglais). #a11y #accessibilité hiddedevries.nl/en/blog/2021-0…
COMMENTSENSE replied: Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0…
Sarah Federman replied: This is also great hiddedevries.nl/en/blog/2021-0…
Rogier Barendregt replied: Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0…
Rian Rietveld replied: 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. replied: 📝 Accessible front-end components: claims vs reality 🔗 hiddedevries.nl/en/blog/2021-0… #html #css #javascript #webdev
Adrian Roselli replied:
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.
TPGi replied:
‟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.
Frontend Daily 🚀 replied: Accessible Front-End Components: Claims Vs Reality - hiddedevries.nl/en/blog/2021-0…
Sitemorse replied:
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 replied: Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0…
Michael Mathews replied:
'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 replied: Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0… #webdev #a11y
CSS Basics replied: Accessible front-end components: claims vs reality, by @hdv hiddedevries.nl/en/blog/2021-0…
ATACNJ replied:
Interesting read hiddedevries.nl/en/blog/2021-0…
Women Who Code BOS replied:
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 replied:
Accessible front-end components: claims vs reality by Hidde de Vries @hdv #accessibility #frontendcomponents #webcomponents hiddedevries.nl/en/blog/2021-0…
The A11Y Project replied: "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 replied: Accessible front-end components: claims vs reality hiddedevries.nl/en/blog/2021-0… #webdev #a11y
Leave a comment
Posted a response to this?

This website uses Webmentions. You can manually notify me if you have posted a response, by entering the URL below.