Can Web Accessibility Rely on Automated Tools?

You did a lot of research into web accessibility compliance and how to make it doable. You saw a ton of tools out there that can help “check” what you do, which is how you ended up with SiteImprove or AccessiBe. Now imagine getting a perfect score on that dashboard, only to find out someone with a visual impairment still cannot navigate your new landing page.

This is the reality of web accessibility right now. There is so much focus on compliance, treating it like a checklist, making sure we get all the green checkmarks. The problem? You forgot there’s actually a human being on the other side of your website.

Don’t get me wrong: web accessibility tools have a place in your process. They can help you find those simple, easy-to-address items that content teams miss. But a high score from Siteimprove, Wave, Axe, or Lighthouse does not mean you have a compliant, usable website.

Real digital accessibility requires human judgment, a core understanding of how your website affects real people, and a robust process.

In this article, we are breaking down what SiteImprove and other tools do well, what they miss, and how you can actually move towards compliance.

There are a ton of automated web accessibility tools on the market right now. Some are better than others, but most focus on identifying a standard list of potential errors.

While I would tell you all day, every day to avoid overlay tools (like accessiBe) like the plague they are, some of these actually help. Tools like SiteImprove can help you catch errors and save time and manual labor. They don’t try to fix the problem (incorrectly). Instead, they help you see what’s wrong and give you the things you need to fix.

These kinds of automated tools can be great assets in your overall content process because they can double-check your work and help prevent:

• Missing image alt tags
• Color contrast issues
• Broken links
• Missing page titles

Checker tools like Siteimprove can be expensive, but they help you keep an eye on your entire website. And even alternatives like Accessibility Checker, DubBot, SkillTide, and Deque are great additions to your content strategy.

But they are just one piece of creating accessible content.

The reality of web accessibility is that while you can “technically” check all of the right boxes, what you create may not actually be accessible.

Any great automated tool can scan thousands of pages on your website and tell you if a technical rule is met, but it cannot tell you if the human aspect of that makes sense.

There are a lot of things tools miss because they are simply focused on compliance, not the human experience. Let’s dive into a few.

One of the best examples of this issue? Alternative text. These tools are checking whether something is in the “box” for alternative text. They help you catch that you didn’t leave it blank. What they cannot tell is whether or not that alternative text actually provides the context and purpose of the image (the actual WCAG rule).

Worse, your website platform can automatically add the image’s junk file name like DSC00135.jpg to the ALT text or a long set of keywords embedded from a stock photo’s metadata. None of that helps actual real humans using screen readers. But your automated tool will pass it because something exists in the box.

When an editor goes and adds a blog post, there’s a 99% chance they are linking to something within the text. I know that a lot of my clients add new resources through these links, too. Automated tools help you catch vague link text like “Click Here” or “Learn More” and will tell you to change it. But there will be plenty of times it misses links with missing context.

Most of these automated tools are looking for patterns; phrases that we’ve gotten too comfortable using throughout the internet. That’s why they will flag “Click Here” but may not flag it if you have linked “Read This.”

When someone is navigating with a screen reader, they can jump from link to link. That means they don’t get the context of everything else on the page, and they will have no idea what they are clicking on unless the link text is clear.

As marketers and even coders learn more about web accessibility, we’ve gotten better about fixing small things. But headings are often woefully misunderstood. Siteimprove and alternative tools can tell you that you skipped a heading level, but it won’t help you organize your content correctly. Headings should have meaning, introducing a new topic or subtopic. This code and visual hierarchy is incredibly important to the overall readability and user experience of your web pages.

Perhaps worse, those tools can’t see if you have made the sizes of your headings inconsistent. Your H1 functions as the page title and there’s only one of a page. It should be the largest font on the entire page. But a scanner won’t catch if you have increased the font size of one H2 or an H3 is randomly wholly different from others throughout your website.

Believe me, I love Hemingway to help me get my overall readability down. There are lots of tools that can help you flag your content and improve it. But they won’t tell you if the layout of your page, use of jargon, or other complexities are hard for people to understand.

While “reading levels” are a WCAG Level AAA standard (and therefore not necessarily required to be compliant), complex text is a barrier to all of your customers. No one wants to work to understand what you do, how you help, or how to buy from you. Bringing down that readability and using your customers’ language is more than an accessibility fix. It’s key to getting actual conversions and sales.

Automated tools can help you check current pages on your website, not just when you are adding content. But there can be accessibility issues throughout your website causing problems that a scanner won’t catch. One of those things? Keyboard focus. Some of your customers will need to navigate through your website using a keyboard instead of a mouse. Can they tell what part of the page they’ve selected, or are they guessing what they are hitting Enter on?

Buttons, links, form fields, and other interactive elements need to have some kind of design to show where the keyboard is focused on your page. This gets missed a lot in general and while it can be included in your site’s code, may not be visible.

And this is something that people care about. Over 88% of lawsuits in a recent AudioEye study cited keyboard navigation issues.

A huge part of the governing principles of web accessibility is understanding. We promote understanding with keeping our website consistent throughout. But when you let multiple people edit the site, it can become a confusing mess really quickly. Your automated tool may flag a color contrast or a link text issue, but it can’t tell you that that should actually be this style of button.

It’s important that design elements across the website are consistent and convey the same meaning. Inconsistent design can make your website super confusing for everyone.

It can be all too enticing to pay for a subscription and think this magic tool is solving all of your problems. (But really, when has that ever worked the way they say it’s supposed to?) I get that chasing that green checkmark or “pass” can feel like chasing a new high. But what we are actually trying to accomplish gets lost in that race for compliance.

While it can miss the red flags we have already talked about and more, you feel like you are doing great work! The reality? Automated web accessibility scanners find around 30% of actual accessibility errors. That’s a huge gap when you are paying a lot of money for a tool.

Worse yet, a lot of these tools will tell you that something is broken, maybe even what rule it’s violating. Rarely do they tell you how to fix them or explain what you can do better.

When you are only fixing 30% of the problem, your website is still actively excluding some of your customers. I’ll acknowledge that, yes, plenty of web accessibility lawsuits are brought by attorneys using scanners. But many of them are filed by real people who really are trying to use your website and can’t. And when they have a bad experience, you best believe they are telling all of their friends and family to avoid you, too.

How can you create an actual accessible experience? You can still use SiteImprove or alternatives, but you also need to have a process in place.

Paints certainly don’t work as well in my hands; they need a skilled artist to turn them into something great. SiteImprove is the same. It’s a tool we use, but we need real humans who understand the accessibility shortfalls involved in the process.

Real web accessibility requires a process that starts before the first word of content is written. When we train teams to create accessible content, we teach them to:

• Think about accessibility first, not when they are hitting publish. It can take more time when we backload the work.
• Learn accessibility basics. Using software to double-check for mistakes is great, but when editors understand the nuances, they can create better content.
• Incorporate manual testing. This doesn’t need a bunch of tools, but try at least navigating with your keyboard or turning VoiceOver on your Mac.

When you can combine accessibility tools with real human understanding (and empathy), you can create actual inclusive websites.

Not sure how to set that process up? I give you the exact process we follow to create accessible content – every single time – in my new course. Sign up to join the waitlist now. You’ll not only get our exact process and checklist, but also learn the meaning behind the “compliance” checks.