Run an automated accessibility scanner on almost any website and you will get a report within seconds: a score, a list of errors, perhaps a reassuring green badge. It is tempting to treat that report as the answer. A clean scan feels like proof that the job is done.

It usually is not, unfortunately. Automated tools are genuinely useful, but they can only check what a machine can measure. Many of the barriers that stop real people from using a site require human judgment to find. The most reliable approach combines automated scanning with manual checks and, where possible, feedback from people who use assistive technology. This article explains what each part of the mix does well, where each falls short, and how a small business can put them together without a large budget.

What automated scanners are good at

Automated tools read a page’s code and apply rules. They are fast, consistent and tireless, which makes them excellent at certain tasks:

  • Finding missing attributes, such as images with no text alternative or form fields with no label.
  • Measuring color contrast between text and its background.
  • Spotting structural errors, such as skipped heading levels or duplicate IDs.
  • Covering many pages quickly, which helps on large sites where manual review of every page is impractical.
  • Catching regressions, when run regularly, so new problems are noticed soon after they appear.

The W3C’s Website Accessibility Conformance Evaluation Methodology, known as WCAG-EM, recognizes this role. It notes that tools can scan entire websites to help identify relevant pages for manual evaluation, and that tools can also assist during manual, human evaluation. In other words, the methodology treats tools as helpers to human reviewers rather than replacements.

Where scanners fall short

A scanner can tell that an image has alternative text. It cannot tell whether that text is accurate. A description reading “image123.jpg” or “photo” passes a presence check while helping nobody. The same applies to link text, headings and form instructions: a tool can confirm they exist, but not whether they make sense.

The UK Government Digital Service put numbers to this gap. In a 2017 test of automated accessibility tools, the team built a deliberately inaccessible web page containing 143 barriers across 19 categories, then ran 10 tools against it. Their findings:

  • 42 of the 143 barriers, or 29%, were not found by any of the tools.
  • The best-performing tool found 37% of the barriers in their tests; another reached 41% when counting issues it flagged for manual checking.
  • Even all the tools combined found 71%.

Barriers missed by every tool included things like text in italics, empty table cells and links identified only by color. The team compared a testing tool to a spellchecker: helpful for catching some problems, but no substitute for a careful human read. They also noted that some tools might not work on password-protected pages, and some might not test mobile pages.

Those results are from one test page in 2017, and tools have developed since. The underlying point still holds: some accessibility questions are about meaning, context and experience, and those need people.

Hands in navy sleeves rest on a refreshable braille display in front of a laptop beside a red notebook and green plant pot.

What the U.S. Department of Justice says about tools

The Department of Justice’s guidance on web accessibility and the ADA, published in March 2022, addresses the same issue. It says automated accessibility checkers and overlays can be helpful tools but need to be used carefully, and that a “clean” report does not necessarily mean everything is accessible. It goes on to say that pairing a manual check with automated checkers can give a better sense of whether a site is accessible.

The guidance also encourages providing a way for the public to report accessibility problems. It notes that businesses have flexibility in how they comply with the ADA, and that the Department does not have a regulation setting out detailed standards, but businesses must still make sure the goods and services they provide online are accessible to people with disabilities. This is not legal advice; obligations depend on your circumstances, so consult a qualified professional about yours.

What manual checks add

Manual testing does not require expensive equipment. Much of it can be done by a careful person with a keyboard, a browser and a checklist. Core manual checks include:

Keyboard-only navigation. Put the mouse aside and use Tab, Shift+Tab, Enter and the arrow keys to move through the page. Can you reach every link, button and form field? Can you see where you are at all times? Can you close pop-ups and menus? Do you get stuck anywhere?

Meaningful text alternatives. Read the alternative text for important images. Does it convey what a sighted visitor would understand from the image? Decorative images should be marked so screen readers skip them.

Link and button clarity. Read your links out of context, the way some screen reader users scan a page. “Click here” and “Read more” repeated ten times tell nobody anything.

Zoom and reflow. Enlarge the page to 200% and beyond. Does text remain readable without horizontal scrolling? Do elements overlap or disappear? This is closely tied to how responsive designs handle different screen sizes.

Forms and error messages. Submit a form with mistakes. Are errors explained in text, not just color? Does the message say how to fix the problem? Is focus moved to the error?

Media. Check that videos have accurate captions and that audio content has a transcript. Automatically generated captions are a starting point, but names, technical terms and numbers often need correcting by hand.

Screen reader spot checks. Free screen readers are built into most operating systems. Even a basic run-through of a key page reveals whether headings, landmarks and labels make sense when heard rather than seen.

Choosing what to test by hand

Manual testing takes time, so it helps to be deliberate about which pages get it. WCAG-EM describes a process for this: define the scope of the evaluation, explore the website, select a representative sample, audit that sample, and report the findings.

For the sample, the methodology describes a structured selection of common pages and page types, a randomly selected set of additional pages, and complete processes, such as a full checkout from start to finish. For a small business, that might mean:

  • Templates: the home page, a typical service or product page, a blog post, the contact page.
  • Key journeys: booking an appointment, requesting a quote, buying something, creating an account.
  • A few random pages to catch problems that would otherwise be missed.

Testing a full journey matters because barriers often appear between pages: a confirmation step that traps keyboard focus, or a payment form loaded from a third party.

WCAG-EM also notes that large-scale evaluation relying mainly on automated tools can cover many pages but lacks the qualitative depth of human evaluation. That tradeoff is the reason to use both.

A woman in a red sweater holds a phone close to read it while a researcher in navy takes notes on a clipboard.

Testing with real users

The GDS team recommended combining automated tool testing with manual checking, an accessibility audit and user testing. User testing with people who have disabilities shows how a site works in practice, including issues no checklist anticipated. A person who uses a screen reader every day navigates differently from a sighted tester trying one for the first time.

Even small-scale user testing helps. Watching two or three people attempt a key task, such as booking an appointment, often reveals the most serious problems quickly. Pay participants fairly for their time and expertise, and focus sessions on real tasks rather than general impressions. Ask them to think aloud as they work. Thoughtful UI/UX design work often already includes usability sessions; including participants with disabilities extends that practice naturally.

Who should do the testing

Automated scans can be set up by a developer and run on a schedule. Manual checks are best done by someone who knows the accessibility guidelines well but was not the person who built the page, since builders tend to test the way they expect the page to be used. If nobody on your team has that experience, a short training session on keyboard and screen reader testing goes a long way.

For a formal audit, such as before a major launch or in response to a complaint, an experienced external reviewer brings independence and a structured report. Many small businesses combine the two: routine internal checks throughout the year, with a professional audit every so often.

How much effort to expect

An automated scan of a small site takes minutes to run and an hour or two to review. A careful manual check of one template might take an hour or so, and a full journey such as a checkout can take longer, especially the first time. User testing sessions usually run under an hour per participant, plus preparation and follow-up. Because fixes to shared templates apply everywhere, the effort tends to fall over time as the most common problems are solved at the source.

Putting the mix together

A practical routine for a small or medium business might look like this:

  1. Run an automated scan across the site to find common, measurable issues and identify problem templates.
  2. Fix the clear errors the scan finds, especially in shared templates and components.
  3. Manually test a representative sample of pages and full journeys using the checks above.
  4. Do user testing on the most important tasks, at least occasionally, such as before a redesign launches.
  5. Provide a feedback channel so visitors can report problems, and act on reports promptly.
  6. Repeat automated scans regularly, for example monthly or after every significant update, to catch regressions.
  7. Repeat manual testing when templates, navigation or key processes change.

Keep a simple log of what was tested, how, when and what was found. Over time, it shows which kinds of problems keep recurring and where training or design changes would prevent them.

A note on overlays

Some products promise to make a site accessible by adding a single line of code that modifies the page automatically. As the DOJ guidance notes, overlays and automated checkers need to be used carefully. In our experience they do not replace fixing the underlying code and content, and they should be tested with assistive technology like any other part of the site. Treat any such tool with the same caution as a scanner: it may help with some issues but does not settle whether the site works for people.

The bottom line

Automated scanners are fast and useful for measurable problems. Manual checks catch issues of meaning, context and operation that tools miss. User testing shows how the site works for the people who depend on accessibility most. None of the three is enough alone; together they give a far more accurate picture.

If you want help building a testing routine that combines all three, Motta Industries’ website accessibility team can review your site, prioritize findings and help fix them.