Why automated accessibility checkers can’t make your website accessible

Say Yeah!
Say Yeah!
May 6 · 5 min read
Two women look at a computer screen; one points at code displayed on the screen
Two women look at a computer screen; one points at code displayed on the screen

When your team first begins to work on the accessibility of your site, you might start with automated accessibility checkers like AxE, Firefox inspector, Lighthouse, SiteImprove, or WAVE. These tools can be solid starting points to find quick fixes and identify problems if you’ve never looked to improve accessibility on your site, or if it’s been a long time since you’ve last audited your site’s accessibility.

However, accessibility checkers have a significant gap: they are focused on code and strict technical compliance, not on usability, design, and content, and can’t truly identify how real people understand and interact with your website.

Accessibility checkers aren’t able to mimic how real people will interact with your website and content.

Here are some areas where automated tools will let you down.

They’re incomplete

Although you can meet many accessibility objectives with automated tools, a full manual review will take you much further. Through a manual review, you can build a site that can be enjoyed by a much wider audience than just those whose needs are covered by compliance standards.

They can be inaccurate

Automated tools may flag issues taken care of in an alternate way-for example, for our forms, input elements like text boxes don’t have a focus state, because, in Javascript, we focus on the element surrounding the input. This implementation causes the checker to fail on that element, but the accessibility requirement is still being met based on WCAG criteria.

They can’t make choices

On our site, we’ve made it so that the menu uses the tab key to move to each of the top-level items, and arrow keys to access the sub-menus. Still, WCAG also provides examples where the tab key only accesses the first menu item, and arrow keys to move left/right between the other elements.

Both of these ways are technically accessible, but one or the other might make your site or specific design more or less usable.

Automated accessibility checkers aren’t able to help you make a judgement call.

Another example of this is adding labels to items to supplement what screen readers say out loud. For instance, adding a page header label to banner landmarks in order to be more descriptive and clear.

Automated accessibility checkers aren’t able to help you make this judgement call. You’ll need real users to test to see which one is more intuitive to use. Or an expert to take a look and evaluate your design.

They can’t see

This gap is because automated checkers can’t see your images and designs to determine whether you’ve met these requirements or not. In essence, they can’t know the context and content to make this judgement call.

So, instead, a manual review of images is necessary to make sure that text is not in any of your images, and alt tags explain the content of an image in a way that provides proper context.

Additionally, an accessibility checker can’t tell you how screen readers are reading out your content in real life beyond a simple “is it reading something” check.

For instance, if SVG settings aren’t set up for screen readers by setting the inline SVGs to have a role=”img” tag, the screen reader will try to announce the tags inside it, which results in announcing repetitive “IMAGE” tags over and over. This example is a terrible experience for people who use screen readers, and it’s unlikely an automated checker would let you know that this is occurring.

They can’t read

Automated accessibility tools do not consider an inclusive lens, which can leave your site open to alienating potential users or inadvertently making content that excludes people. No automated tool can determine how your site makes users feel, or if they are feeling excluded by your content or the feel of your website.

The words and images you use on your website impact how a user feels, and an accessibility checker can’t analyze those words and images.

The combination of the words and imagery you use have context associated with them that makes users feel a certain way, from a spectrum of delighted to offended. A purely-automated accessibility tool can never understand this.

A more suitable process

The best process is a comprehensive design, code, and content process, where you and your team work to ensure your site is as usable, accessible, and inclusive as possible. Then plan to review, improve, and test these items continually (internally or, preferably, with users). Using this process will help you holistically improve not just your site’s accessibility, but the general usability and performance of your website.

Most importantly, moving beyond automatically checking code-and embracing design, interaction, and usability considerations, alongside inclusive content-will open up your site to more potential users and help convert more of the users who are currently visiting.

Go beyond automated accessibility checkers with the Essential Website Audit

Get started from $499

Originally published at https://sayyeah.com on May 6, 2020.

Digital Insights from Say Yeah!

Essential insights on achieving digital excellence and…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store