Component libraries, accessibility and transparency
A couple of weeks ago, Manuel Matuzović wrote
UI component libraries are using the term “accessible” too freely. Adding focus styles and copy-pasting some ARIA roles doesn’t make your library accessible, neither does adding an “accessibility” page where you claim to conform to WCAG just because you ran a Lighthouse test.
I think right now today they could *all* switch to simply listing what they did and tested, without claims starting with “a”. Followed by a link to their gh tickets w the “accessibility” label. More useful tbh
By coincidence, my boss had asked to write up how to evaluate third party libraries (indeed, any third party software). Here’s some of what I wrote:
The first rule is don’t unquestioningly believe vendors’ claims. This isn’t to say that they are lying (although some are); perhaps they made their components believing them to be accessible, but didn’t know how to test; perhaps they started off accessible but subsequent contributors/ maintainers let bad code into the product.
Nothing replaces thorough testing with actual devices, but that’s time-consuming, so it’s useful to draw up a shortlist, which is as much an art as it is a science.
- Is the marketing website accessible? (Give it a quick test with the Tota11y tool. If yes, it doesn’t mean the components are, but if the site lacks alt text, can’t be used with keyboard and has bad contrast, can we really trust the components?)
- Does the project website/ repo mention a11y prominently, e.g. is it featured?
- If they do, do they indicate what they tested (WCAG 2.1 A, AA?), on what (JAWS, NVDA, VoiceOver? etc), and when (3 years ago, yet there have been 6 subsequent releases)?
- Do they have a named person looking after a11y? (If “no”, this isn’t necessarily a problem; if yes, it’s a good sign)
- Does a web search for the project name + “accessibility” come up with positive or negative results?
- Do recent PRs suggest that code reviewers took a11y into account? (An original dev may have been a11y-minded, but moved on, so any a11y promises might be stale.)
Hidde de Vries (of W3C) recommends asking the following questions:
- How did they test? (e.g, automated tests only? Against WCAG? With screen readers? If so, which ones?)
- Who did they test with? (e.g., did real screen reader users test? Was a broad range of disabilities included?)
- Are they open about pros and cons of their approach? (Do they claim to be a magical fix-all? Or is there an accessibility statement with known issues and planned fixes?)
- Who created them? Is it a reputable org with a public service remit, eg GDS, BBC? Or well-respected a11y practitioners, eg Tenon, Tertralogical?
Today, Erik Kroes wrote
I wrote a quick blog for #LionComponents about accessibility in design systems, and specifically what it means in the context of Lion.
Lion is an open-source set of “white label” UI Web Components, developed and tested with assistive technologies on behalf of ING Bank. Erik’s blogpost The Accessibility of Lion is an excellent transparent statement of accessibility. It says what it does, doesn’t over-promise, and is transparent about what it doesn’t do:
Using Lion does not ensure an accessible outcome. Sorry, it doesn’t work like that. What it does provide is a solid base for you to build your own design systems and/or components with. It covers things like keyboard accessibility, UX design and semantics but a bad visual design can still ruin a lot.
It also tells me what testing has been done, and with what assistive technology (although not which browsers and operating systems; for example, is Talkback on Android tested?):
It’s thoroughly design, built and tested for you to meet (and exceed) WCAG 2.1 AA. Components are based on the theoretic ARIA Design Pattern Examples but made practical by automated testing, extended manual testing, heavy scrutiny and testing across platforms with screen readers like VoiceOver, NVDA and JAWS.
It also transparently points to any accessibility-related Github issues, so I can see how quickly things get resolved, the rationale behind any decisions, and whether there are any issues that might prohibit my adoption of it.
More of this stuff, please, component library creators!
(Update 8 Dec 2021):
- Also see glamorous Adrian Roselli’s post Be Wary of Accessibility Guarantees from Vendors which is 4 years old, because he’s so far ahead of the curve, he’s like sultry yankee tachyon.
- The Business Disability Forum created an Accessibility Request for Proposal that you can use within your organisation.
- Disability:IN has an Accessible Technology Procurement Toolkit