Website Accessibility Audit: Automated, Manual, or Both?

A website accessibility audit can produce very different results depending on how it is conducted. For teams in the United States researching ADA website compliance, the important question is not simply which tool to buy. It is which barriers each testing method can detect—and what remains unknown after the tests finish.

Automated checks are useful for finding repeatable, machine-detectable problems. Human review is necessary to evaluate meaning, interaction, and whether people can actually complete tasks. A serious audit combines both, with a clearly defined scope and evidence that developers can use.

What a website accessibility audit should establish

An audit should explain what was tested, which requirements were evaluated, what failed, and what could not be determined. A dashboard score alone does not provide that picture.

For a WCAG 2.1 AA audit, ask how the assessment addresses the applicable requirements across the agreed scope. That scope should include more than a collection of URLs: a page can behave differently when a menu opens, a form fails validation, or a customer reaches checkout.

Useful audit evidence connects a requirement to a specific observation. For example, a report might identify a form field without an accessible name, explain how that affects someone using a screen reader, and describe how to reproduce the problem.

The crucial distinction is between verifying a particular condition and evaluating accessibility across a complete experience. Automated tests can do the former for some conditions. Neither a clean scan nor a quick human inspection establishes the latter.

What automated accessibility checks can genuinely prove

Automated tools examine information such as page markup, accessibility properties, and computed styles. They apply rules to conditions that software can evaluate reliably within the content and state it can access.

Common examples include detecting certain controls without accessible names, images missing alternative-text attributes, and text contrast failures where foreground and background colors can be determined reliably.

These checks are valuable because they are repeatable. Teams can run them during development, compare results after changes, and detect some regressions before release.

Machine-verifiable does not mean comprehensive

Consider an image. A tool can check whether an alternative-text attribute exists. Its presence does not prove that the description communicates the image's purpose. An attribute containing a filename might satisfy a structural check while providing little useful information.

The same distinction applies to controls. Software may establish that a button has an accessible name. Determining whether that name accurately describes the action often requires context.

Read automated results as evidence about specific checks on specific content at a specific moment. A passed check is not a verdict on the whole page. An inconclusive result needs review, and an empty issue list may reflect limited coverage rather than an absence of barriers.

Coverage depends on what the tool reaches

A scanner visiting public pages may never encounter account settings, an expanded navigation menu, or an error message shown only after submission. Even a broad crawl can miss important interactions.

Before relying on results, establish which pages and states were reached, whether authenticated areas were included, and which checks required human confirmation. This is a question of testing design, not a reason to dismiss automation.

What human review adds

Human review evaluates context and behavior that a rule engine cannot reliably resolve. It also checks objectively testable interactions that a basic scanner may not exercise. Manual testing is not simply an opinion about whether a website feels accessible.

• Keyboard interaction: Can someone reach and operate controls, follow a sensible focus order, and leave components without getting trapped?
• Screen reader experience: Do names, roles, states, reading order, and announcements communicate what is happening?
• Content meaning: Do image descriptions, headings, instructions, and link labels make sense in context?
• Visual adaptation: When content is enlarged or the available space changes, does essential information remain available and usable?
• Error recovery: Can someone identify a problem, understand how to correct it, and complete the task?

A dialog illustrates why these methods belong together. Automation might detect a missing name. A reviewer can open the dialog, inspect where keyboard focus moves, check whether background content remains inappropriately reachable, and confirm what happens when the dialog closes.

Testing with people with disabilities can add valuable evidence about real-world usability. It complements structured technical review rather than replacing it: a successful task completion by one participant does not establish that every applicable requirement is met.

How this relates to ADA website compliance

The relevant law is the Americans with Disabilities Act (ADA). The federal enforcement authority is the U.S. Department of Justice, Civil Rights Division.

For United States businesses, exposure is primarily private litigation, including lawsuits and demand letters from plaintiffs' firms, typically referencing WCAG. Defendants can face injunctive relief and attorneys' fees. Department of Justice enforcement can additionally seek civil penalties.

These risks make clear documentation useful, but they do not turn an automated report into a legal determination. A WCAG 2.1 AA audit is a technical assessment; it identifies accessibility issues and supports remediation, without guaranteeing legal outcomes. Keep the technical question—what barriers exist—separate from requests for legal advice.

A practical workflow that combines both methods

Define the experience before running tests

List key templates, shared components, and important user journeys. Include forms, navigation, account access, and transaction steps where relevant. Record interactive states such as expanded menus, validation errors, and confirmation messages.

For a large website, representative sampling can make the work manageable. Document the selection and its limits rather than implying that untested pages were assessed.

Use automation early, then investigate

Run automated checks across the agreed scope. Validate findings, group repeated problems by their underlying component, and flag results that need judgment. A shared navigation defect may appear on many pages but require one coordinated component fix.

Next, manually test the important journeys and applicable requirements that automation cannot resolve. Use keyboard and assistive technology testing alongside visual and content review. Record the environments used so that others can reproduce the findings.

Report, fix, and retest

A useful finding includes the affected location, observed behavior, user impact, relevant requirement, reproduction steps, and remediation guidance. Separate confirmed failures from questions that still need investigation.

After changes, repeat the relevant automated and manual checks. A code change is not evidence that the barrier has disappeared. Retest the original interaction and check nearby behavior for regressions.

How to choose the right testing approach

Use automation for fast feedback and ongoing detection of machine-checkable issues. Add targeted manual testing when changing interactive components. Choose a combined audit when you need a broader, documented assessment of important pages and journeys.

When comparing providers, ask what their deliverable actually covers:

• Which pages, components, and states will be tested?
• Which requirements receive human review?
• Will findings include reproducible evidence and practical fixes?
• Are limitations and untested areas explicitly documented?
• Is remediation retesting included or separately scoped?

Professional audit services such as geta11y are one option, but the same questions apply to internal teams and external providers.

The strongest approach is not automation versus people. It is automation for repeatable checks, human review for context and interaction, and retesting to verify that fixes work. That combination produces something more useful than a score: a defensible account of what was checked and a practical plan for removing barriers.