Accessibility Audit Services vs Automated Tools: 2026 Guide

Quick answer: An accessibility audit service is a manual evaluation by trained testers who use a keyboard, screen readers and zoom to test your site against WCAG 2.2 Level AA, then deliver a report mapped to each success criterion, often with a VPAT/ACR. Automated tools scan every page in minutes for machine-checkable failures like contrast and missing labels, but can't judge everything. Most organisations need automated scanning continuously and a manual audit periodically.

If you're comparing "accessibility audit services" with "accessibility audit tools", you're really choosing how much of WCAG gets tested and by whom. This guide explains what each covers, uses data from 219 real websites to show where automated testing stops, and gives a decision table for picking the right mix.

Services vs Tools at a Glance

What Automated Tools Miss: Data From 219 Sites

We ran axe-core 4.10.2 with WCAG 2.0/2.1/2.2 A and AA rules on 219 randomly sampled homepages (Tranco ranks 1,001–50,000, seed 20261003), then ran a keyboard test: 40 Tab and 40 Shift+Tab presses, checking whether each focused element was visible.

Three lessons for anyone choosing between a tool and a service:

1. A clean automated scan isn't a pass. 25 of the 27 sites with zero violations still had elements axe flagged for human review, most often colour contrast over images or gradients it couldn't measure.
2. Keyboard problems are common and invisible to rule engines. A third of sites hid the keyboard focus behind their own header, cookie banner or pop-up. No standard automated rule set tests this.
3. The most common automated failures are cheap to fix. Colour contrast (64.4% of sites) and unnamed links (42.5%) are fixed in CSS and markup. Fix those with a tool before paying auditors to find them.

Full numbers are in our website accessibility statistics and what automated accessibility testing misses.

What a Professional Accessibility Audit Includes

A credible audit service should cover all of the following. Ask for each in the proposal.

1. Scope and sample. Which templates, user journeys (sign-up, checkout, account), documents and platforms. Most audits test a representative sample, not every URL.
2. Standard. WCAG 2.2 Level AA is the current baseline. Some contracts still name 2.1 AA; the W3C's WCAG overview lists the versions.
3. Automated pass. A rule engine over the sample to catch the machine-testable failures quickly.
4. Manual keyboard testing. Every interactive element reachable and operable, visible focus, logical order, no keyboard traps.
5. Screen reader testing. Typically NVDA or JAWS on Windows and VoiceOver on macOS/iOS, checking names, roles, states and announcements.
6. Zoom and reflow. Content usable at 200% text size and 400% zoom (320 CSS px width) without horizontal scrolling.
7. Content checks. Meaningful alt text, headings, link purpose, error messages and instructions.
8. Findings report. Each issue with the WCAG success criterion, location, severity, user impact and recommended fix.
9. Retest. A second pass after you fix the issues, to confirm conformance.
10. Documentation. Optionally a VPAT-based Accessibility Conformance Report (ACR) for procurement.

What drives the price of an audit service

Providers quote per project. These are the factors that move the quote:

Ask for the price per template rather than per URL; it's the unit that reflects the real work.

Help Your Auditors: Run a Keyboard Walk First

Before (or between) manual audits, this script tabs through a page and lists every focus stop, whether it has a visible focus indicator and whether something hides it. A human still judges whether the order and names make sense; the script gives them the list to judge.

"""Keyboard walk: the part of an accessibility audit most scanners skip.

Tabs through a page and, for every focus stop, records what got focus, whether a
focus indicator is visible (WCAG 2.4.7) and whether a fixed or sticky element
completely hides it (WCAG 2.2, 2.4.11 Focus Not Obscured). A human still has to
judge the order and the labels; this gives them the list to judge.

Usage:
  pip install playwright && python -m playwright install chromium
  python keyboard_walk.py https://example.com/ [tab_count]
"""
import sys
from playwright.sync_api import sync_playwright

STOP_JS = r"""() => {
  const el = document.activeElement;
  if (!el || el === document.body) return null;
  const cs = getComputedStyle(el);
  const indicator = (cs.outlineStyle !== 'none' && parseFloat(cs.outlineWidth) > 0) ||
                    cs.boxShadow !== 'none' || cs.textDecorationLine.includes('underline');
  const r = el.getBoundingClientRect();
  const pts = [[r.left + 2, r.top + 2], [r.right - 2, r.bottom - 2], [r.left + r.width / 2, r.top + r.height / 2]]
    .filter(([x, y]) => x >= 0 && y >= 0 && x < innerWidth && y < innerHeight);
  const hidden = pts.length > 0 && pts.every(([x, y]) => {
    const hit = document.elementFromPoint(x, y);
    return hit && hit !== el && !el.contains(hit) && !hit.contains(el);
  });
  const name = (el.getAttribute('aria-label') || el.innerText || el.getAttribute('title') ||
                el.getAttribute('alt') || el.tagName).trim().replace(/\s+/g, ' ').slice(0, 40);
  return { tag: el.tagName.toLowerCase(), name, indicator, hidden };
}"""


def main(url, tabs=30):
    with sync_playwright() as p:
        browser = p.chromium.launch()
        page = browser.new_page(viewport={"width": 1366, "height": 768})
        page.goto(url, wait_until="load")
        page.wait_for_timeout(1500)
        start, stops = page.url, []
        for _ in range(tabs):
            page.keyboard.press("Tab")
            page.wait_for_timeout(80)
            if page.url != start:
                break
            stop = page.evaluate(STOP_JS)
            if stop:
                stops.append(stop)
        browser.close()
    print(f"{'#':>3}  {'element':<8} {'focus ring':<11} {'hidden':<7} name")
    for i, s in enumerate(stops, 1):
        print(f"{i:>3}  {s['tag']:<8} {'yes' if s['indicator'] else 'NO':<11} {'YES' if s['hidden'] else 'no':<7} {s['name']}")
    no_ring = sum(not s["indicator"] for s in stops)
    hidden = sum(s["hidden"] for s in stops)
    print(f"\n{len(stops)} focus stops: {no_ring} without a visible indicator, {hidden} fully hidden")


if __name__ == "__main__":
    main(sys.argv[1], int(sys.argv[2]) if len(sys.argv) > 2 else 30)

Example output:

  #  element  focus ring  hidden  name
  1  a        yes         no      Skip to content
  2  a        yes         no      Pricing
  3  button   yes         no      Features
  4  input    NO          no      Email address
  5  a        yes         YES     Privacy policy

5 focus stops: 1 without a visible indicator, 1 fully hidden

The focus-ring check is a heuristic: it looks for an outline, box shadow or underline, so a design that shows focus through a background or border change will read as "NO". Treat those rows as "check by eye".

Which Do You Need? A Decision Table

⚠️ Overlays aren't a substitute for either. In our on/off tests, overlay widgets didn't remove the underlying failures. See do accessibility overlays work?

How BugViso Fits Into an Accessibility Programme

BugViso is the automated half, not an audit service. A BugViso scan runs axe-core 4.10.2 with the WCAG 2.0, 2.1 and 2.2 A/AA tags (62 rules in Chromium) on every crawled page, groups failures by rule with a page count and sample selectors, suggests compliant colours for contrast failures, and checks mobile viewport, overflow and tap targets on the entry page.

Use it before a manual audit so your auditors don't spend paid hours logging contrast errors, and on a schedule afterwards so fixed issues stay fixed. For the manual half, our WCAG 2.2 checklist marks which criteria need human testing, and our comparison of WCAG compliance tools covers the automated options.

More detail is on the automated WCAG 2.2 audit feature page.

Mistakes When Buying Accessibility Testing

• Buying a manual audit before fixing the obvious. You pay auditors to log hundreds of contrast and label failures a tool finds for free.
• Treating an automated score as conformance. It covers machine-testable rules only.
• Auditing once and never again. Each release can reintroduce failures; schedule automated scans between audits.
• Testing only the homepage. Forms, checkout and account pages are where users get stuck.
• Skipping the retest. Without it, you have a list of problems, not evidence they're fixed.

FAQ

What should I expect from a professional accessibility audit of my website?

A defined scope of templates and journeys, testing against WCAG 2.2 AA with automated tools plus manual keyboard, screen reader and zoom testing, a report with each issue mapped to a success criterion with severity and fix, a retest, and optionally a VPAT-based ACR.

Are automated accessibility tools enough?

No. They catch machine-testable failures on every page, which is valuable, but can't judge things like alt-text meaning, reading order or whether focus is visible and logical. In our sample, a third of sites hid keyboard focus behind their own UI, which automated rule sets don't test.

How much does an accessibility audit service cost?

It's quoted per project, driven mainly by the number of unique templates and journeys, the platforms tested, depth (including user testing), retests and whether you need an ACR.

What's the difference between a VPAT and an accessibility audit?

An audit is the testing. A VPAT is a template, and the completed version (an Accessibility Conformance Report) documents how a product conforms to each criterion, usually based on an audit.

How often should we run an accessibility audit?

Automated scans continuously or on every release; a manual audit at least once a year and after any redesign.

The Takeaway

Automated tools find the failures fast and services find the rest, so start with a free BugViso accessibility scan to clear the bulk before your auditors start the clock.