Skip to main content
7 min read

WCAG Scanner for Small Business: What Automated Tests Can and Cannot Find

A practical guide to using automated accessibility scans without overclaiming compliance: what scanners catch, what still needs human review, and how to turn findings into fixes.

A WCAG scanner is useful because it turns invisible accessibility problems into a list your team can act on. It is not useful when it is sold as a compliance certificate, a legal shield, or a replacement for human judgment.

The practical way to use automated scanning is narrower and stronger: find common machine-detectable issues, fix the ones that block users, then use manual review for the parts of accessibility that require context.

Why small businesses should scan first

Most small teams do not have an accessibility specialist on staff. A scan gives them a fast starting point: which pages have clear failures, which issues are repeated across templates, and which fixes are likely to have the biggest user impact.

The need is not theoretical. WebAIM's 2026 Million report found detected WCAG failures on 95.9% of home pages in its sample. The most common detected issues were familiar, fixable problems: low contrast text, missing image alternatives, missing form labels, empty links, empty buttons, and missing document language.

That is exactly where a scanner earns its place. It helps you spot the repetitive issues that are easy to miss when you are updating products, publishing new pages, or changing a theme.

What automated WCAG scanners can catch

ClearSite uses axe-core powered automated checks to find common issues that can be assessed from the page's rendered HTML, styles, ARIA, and accessible names. Depending on the page, automated checks can surface problems such as:

  • Missing form labels, so screen reader users may not know what information a field expects.
  • Low colour contrast, where text may be difficult to read for people with low vision or situational visibility limits.
  • Missing alternative text, especially image elements that expose no useful text alternative.
  • Broken accessible names, such as icon-only buttons without a readable label.
  • Invalid or risky ARIA patterns, where ARIA markup conflicts with what assistive technologies expect.
  • Document structure issues, including missing language, duplicate landmarks, or heading problems a tool can identify reliably.

Deque's automated accessibility coverage report found that, in its audit data sample, automated tests identified 57.38% of total recorded issues. That does not mean every site gets the same coverage. It does mean automation can catch a meaningful share of the work if the results are treated as a remediation queue, not as the whole answer.

What scanners cannot decide

W3C WAI is clear that evaluation tools cannot automatically check every accessibility aspect, and human judgment is required. That matters for small businesses because the most dangerous product claim is the one that sounds easiest: "Run this tool and you are compliant."

Some accessibility questions require context that a scanner cannot fully understand:

  • Whether alt text is meaningful, a tool can detect that text exists, but a person needs to judge whether it describes the right thing for the page.
  • Whether a keyboard workflow actually makes sense, especially in menus, modals, carts, calendars, and multi-step forms.
  • Whether instructions are understandable, including error recovery, payment flows, and complex product options.
  • Whether focus order follows the experience, not just the DOM order a tool can inspect.
  • Whether PDFs, videos, and third-party widgets are accessible, especially when they sit outside your normal page template.

A scanner can reduce uncertainty. It cannot replace user testing, specialist review, or legal advice where you need a formal compliance position.

A sane workflow for small teams

The mistake is treating scanning as a one-time pass or fail. The better workflow is continuous and evidence-based:

  1. Scan the most important pages first, start with your home page, product pages, booking flow, contact form, checkout, and account pages.
  2. Fix critical and serious findings, especially anything that blocks navigation, form completion, reading, or purchasing.
  3. Look for repeated template issues, one header, footer, form component, or theme pattern can create the same barrier across many pages.
  4. Retest after each fix, do not assume a theme edit or plugin setting solved the problem until the page has been checked again.
  5. Add manual review where it matters, use human judgment for key journeys, rich interactions, copy clarity, media, and legal-risk decisions.
  6. Monitor for regressions, because new content, app embeds, tracking scripts, and design changes can reintroduce issues.

How ClearSite fits

ClearSite is built for the first half of that workflow: fast scanning, prioritised findings, plain-English explanations, and platform-specific fix guidance for teams that need to make progress without becoming WCAG specialists overnight.

We do not claim a free scan proves compliance. The value is more useful: it shows likely source-level issues, explains why they matter, and gives you a practical route to start fixing them.

For many small businesses, that is the highest-leverage first step. Find the common barriers, fix the ones that affect real tasks, keep a record of the work, and bring in manual expertise when the decision needs a full accessibility assessment.

Sources: WebAIM Million 2026 report, W3C WAI evaluation tools guidance, W3C WAI Easy Checks, and Deque automated accessibility coverage report.