Are automated accessibility services and features really all that accessible? Let's explore that idea in Access & Allies' thirteenth episode.
00:00 | Introduction
00:36 | Automation is cool, but it isn't everything
01:05 | Audits
01:51 | Alt text
02:51 | Overlays
04:10 | Captions
05:01 | Is it all that bad?
05:36 | Conclusion
Twists & Turns | The Paul Dunlea Group
This is the All Access podcast Access and Allies. My name is Rowan; I’m the co-Founder of All Access and a web accessibility auditor for the government of British Columbia’s Digital Government team.
The goal of Access and Allies is to attempt to break down any digital accessibility topic under the sun to answer any and all of your questions around making digital tools more accessible. Thanks for tuning in, and if you prefer to read along, make sure to find this episode’s transcript in the notes — along with any resources I mention.
Now, let’s get started with today’s topic: The Myth of Automated Digital Accessibility
There are a lot of cool things automation can do. And that extends to cool things automation can do to make stuff more accessible. Like programming a morning latte. Sure you have to have the money for it, but let’s say you do! An automated latte in the morning doesn’t just help night owls, new parents, and the over-worked. It can be great for people with rheumatoid arthritis or other mobility-related disabilities as well who love a fancy shot of espresso first thing.
But automation isn’t always the answer. In fact, I’d go so far as to say it’s the antithesis to digital accessibility.
There are a lot of marketed solutions out there that purport to make accessibility easy, thoughtless even. As though a company has waved it’s magic wand and all your accessibility requirements are met.
I hate to break it to you, but it’s never that easy.
Accessibility requires a human lens. Sure there are automatic checkers but they don’t catch everything, and sometimes the things they do catch require context to determine if they really are errors.
We need to know what we’re looking for when using automatic checkers, and we can’t neglect manual testing just because Lighthouse says we got 100% on our accessibility check (which is rare, by the way).
When I’m auditing, I use a couple of automated checkers to get an idea of where the site or app may be at. But then I run through keyboard navigation and screen reader tooling, as well as screen magnification to 200%. These are things automation just can’t account for.
That’s the auditing side, but where else do we find automation pitfalls in accessibility?
I was looking around posts on A11y Project and this one from 2021 by Eric Bailey caught my eye: “Alternate text and automation”.
I’ve seen countless automated alt text that was so far off base it was in space. Or it was technically correct but didn’t provide the context that we were really looking for.
And there’s that word again: context. Context is key. Alt text is about providing people with low or no vision the information sighted users infer by looking at an image. In two to three sentences, why is this chosen picture important in relation to the text?
I’ll link the post I mentioned in the notes section, and I highly recommend checking out the section “Be wary of false promises”. On top of working to convince organizations that accessibility is essential, a lot of us are working to de-bunk false advertising by other companies promising “quick and easy” accessibility solutions.
That’s not to say accessibility is always hard, but it is never thoughtless.
That brings me to my next point. And to reiterate the point in the article on being wary of false promises: Overlays!
Another good resource for this topic is by The A11y Project Team and the publication is called “Should I use an accessibility overlay?” The quick answer is “no”. Honestly, I feel like the moral of this story is if it sounds too good to be true, it probably is.
But here’s a little more detail on overlays and why they aren’t the answer to all our problems…
Overlays are JavaScript that aims to fix accessibility issues on websites and web apps. There are temporary bandage solution overlays, and permanent plugins.
The bandage solution is obviously meant to be a temporary measure and should be removed as soon as the underlying accessibility issue is fixed.
Permanent plugins, on the other hand, have a slew of problems which is it’s own podcast episode. I recommend checking out the article linked in the notes section because it’s a really interesting read.
Without going into too much detail, it talks about why plugin overlays are ableist, don’t provide quality solutions, are unsustainable, disallow user autonomy (contrary to the essence of accessibility), lack privacy measures and are susceptible to malware, and lowers overall site performance making it all the more inaccessible. Not to mention the fact that overlay plugins have been known to compromise a screen reader’s ability to navigate sites.
One more example of where automation fails is with captions. There are so many more, but this episode has to end at some point. There are a ton of services out there that provide auto-captions, not all created equally. But we’re not at the point yet where I’ve ever seen good auto-captions.
The difference here is that I would actually recommend using one of these services. Why? Because it gives you a good framework to start with and will save you hours of your time. That said, the work has to go into fixing them or there is no point in having them a lot of the time.
YouTube’s auto-captioning is probably one of the better ones, but it’s only about 60-70% accurate from what I could find out. So if you are putting together video-audio media for work, captions must be considered in the budget. In my experience, after auto-captions, a two hour video is around 8 hours of captioning time, give or take depending on the sound quality and other varying factors.
So there you have it: unfortunately, automated accessibility is not the answer. We still need to consider accessibility when we’re putting together budgets, teams, and work schedules. It must be built in at every stage.
But if you see a really cool accessibility service out there and are thinking of trying it out for your user base, I highly recommend what people in the community are saying about it. Check out digital accessibility forums! I relied on the A11y Project for this episode’s resources and they are a great source of information. Look up what people using screen readers are saying about the service, or what people in the Deaf community are saying.
The information is out there, you just have to go looking for it.
Thank you for listening to this episode of Access and Allies on digital accessibility and automation. I hope this has provided you with some new information, or at least confirmed some old knowledge. Just remember: meaningful accessibility takes time, expertise, and context!
Make sure to check out the resources provided in the notes section. And if you have any questions or comments, please feel free to reach out at info@allaccess.dev or through LinkedIn.
Want your site assessed for accessibility, or looking for consultation on your site plan? Make sure to reach out about that as well — we want to know how we can support you.
It’s been fun talking at you and until next time on Access and Allies.