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.

---

Originally posted as Accessible front-end components: claims vs reality on Hidde's blog.

Reply via email