
Last Updated: August 1, 2026
As GovWebworks reports, citing a Gov.uk study, running automated accessibility tests on your website is similar to running your document through spell check. It will catch obvious spelling errors, but if you wrote the word ‘cat’ when you actually meant to write the word ‘bat,’ spell check won’t flag that as an error. That’s because spell check isn’t built to scan your writing for context or clarity.
So, unless you proofread your documents manually, you could end up with some nonsensical sentences.
When testing your site for accessibility, automated testing can be useful for analyzing large chunks of code and can provide a baseline of issues that need to be investigated further.
However, like spell check, automated testing for accessibility will not ensure that your website is translating the context of your content clearly to those with a disability.
Here are some of the reasons why automated testing for accessibility is not enough.
The primary purpose of alt text is to describe the images on a page to users who are visually impaired. Adding alt text to your HTML code provides a text alternative to images that can be read out loud by screen readers.

For example, for the image above, alt text could look something like this:
1 | <img src="puppy.png" alt="puppy"> |
Technically you’ve written alt text for the image, but the word “puppy” doesn’t fully describe it. Instead, you might write something like:
1 | <img src="puppy.png" alt="Brown puppy sitting in green grass"> |
This alt text is better than the first example because it’s much more descriptive. However, if you were to run the first line of code through an automated accessibility testing tool, it would not be flagged.
Automated testing isn’t intelligent enough to know whether the alt text is descriptive; it only checks to see that it exists.
An accessible online form is crucial. Within the site’s code, labels can easily be associated with form fields so that users with visual disabilities know what each one is asking for. By including labels within HTML, you allow those who use screen readers to navigate the form easily.
However, similar to alt text, it’s important that labels are both descriptive and accurate. While automated testing tools can determine whether labels are missing, they’re not sophisticated enough to judge whether those labels are actually helpful.
It’s also important to consider users who will navigate your site with a keyboard. As a user tabs through a form, sections should be highlighted so it’s obvious where they are within the form. This is especially true for complex forms that contain multiple options like checkboxes and drop-down menus.
Rich or interactive media is best described as media that can be downloaded or embedded into a webpage. Videos and online games are both examples.
This type of dynamic content cannot be scanned using automated accessibility testing tools and requires human testing to ensure it’s accessible.
Videos should include closed captioning for viewers who are deaf or hard of hearing. Audio files should include text transcripts for individuals who are visually impaired and rely on screen readers.
Automated testing for accessibility can speed up the QA process by analyzing large quantities of code while identifying major issues, but you should never rely solely on automated testing. It doesn’t account for issues that are subjective in nature, which is why a thorough accessibility audit requires manual testing as well.
Finding a balance of automated and manual testing ensures that your website meets current accessibility standards and is equally accessible to all individuals.

Your first month is on us. When you sign up for a Probo.CI, every new account starts with a full month free on any of our plans. For more information on how to get started, click here.
LEARN MORE ABOUT PROBO.CI'S PRICING