Website Accessibility Audit Process: From Finding to Retest

Start with scope and an identifiable version

A website accessibility audit turns an agreed evaluation scope into findings that a team can investigate, repair and retest. The technical target should name the WCAG version and level. Calling a service an “ADA audit” does not identify that target or resolve legal applicability; confirm legal and contractual requirements separately.

Before testing, agree on the product boundary, representative views, complete processes, important states, technologies and exclusions. Record the release or build being evaluated. Our audit scope guide covers that planning decision; this guide follows what happens after a reviewer finds something that needs attention.

W3C’s WCAG-EM 2.0 methodology provides a framework for scope, exploration, sampling, evaluation and reporting. The completed example below is narrower: maintenance of a tool we own. It demonstrates finding and retest evidence, not completion of a whole-site conformance evaluation.

Choose checks that answer different questions

Automated checks can identify some issues and support repeatable regression testing. They do not establish all aspects of accessibility. W3C’s guidance on evaluation tools also warns that outputs can be misleading and require human judgment. A universal detection percentage hides differences in the rules, pages, states and issue counts being measured.

Combine methods according to the scope:

• Automated checks: retain the tool/version, rules, pages and states evaluated. Review failures and items requiring judgment; an empty result is meaningful only within the tool’s actual coverage.
• Structural and content review: compare visible meaning with programmatic structure. Check whether headings describe their sections and controls have appropriate names and instructions. A level-counting heuristic cannot judge the meaning of a heading.
• Keyboard and assistive-technology tasks: follow the relevant journey, including errors and recovery. Record commands, focus, spoken output, settings and technology versions separately. Select environments for the product and audience; do not imply that one session covers every combination.
• Presentation checks: evaluate the applicable contrast, resizing, reflow and other visual requirements in the relevant states. User research with people with disabilities contributes a different kind of evidence and should have its own tasks and method.

Two distinctions prevent common reporting mistakes. 1.3.1 Info and Relationships concerns conveyed structure and relationships; 2.4.6 Headings and Labels concerns description of topic or purpose. An “exactly one H1” rule is not the wording of 2.4.6.

Likewise, 1.4.4 Resize Text addresses enlargement up to 200%, subject to its exceptions. 1.4.10 Reflow addresses presentation without loss and two-dimensional scrolling at specified equivalent dimensions, including 320 CSS pixels wide for vertically scrolling content, with exceptions. Recording only “zoom checked at 200%” does not describe both evaluations.

Write a finding another person can reproduce

A useful finding connects an observation to a decision. Include:

• Identity: stable issue ID, URL/component, release, test date and owner.
• Starting state: input, account state or preceding steps needed to reproduce it; use safe synthetic data where possible.
• Method and environment: tool versions, browser, operating system, assistive technology and relevant settings.
• Expected and observed behavior: what should happen, what actually happened and the evidence supporting each statement.
• Classification: a substantiated criterion failure, a question requiring review, a tool limitation or a product defect. Explain any criterion mapping instead of assigning one merely because the issue involves HTML.
• Impact and priority: who may be affected, how a task is obstructed, and what remains inferred rather than observed with participants.
• Repair and acceptance: the proposed change, responsible team, retest steps and conditions for closing the issue.

Keep sensitive records out of public examples. A screenshot can show a visible result, but it cannot establish what a screen reader announced. Preserve the evidence that fits the claim, along with any missing information.

Completed example: a misleadingly incomplete heading outline

On October 19, 2026, we repaired input handling in the heading validator we maintain. Our internal example ID is GW-HV-001: unsupported input could produce an incomplete outline. This is an owned-tool correctness issue, not a client case or an adjudicated WCAG violation.

What we observed before the repair

We executed the original parser extracted from revision e354f31 with three synthetic inputs. This was source execution, not a recording of an old browser or screen-reader session:

1. <h1>Store</h1><h2>Products</h2> returned only the first heading, “Store.”
2. <h2>Products</h3> was accepted as an H2 despite the mismatched closing tag.
3. <h2><span>Products</span></h2> returned no headings.

The parser did not return a list of unrecognized lines. The practical concern was incomplete coverage: a reader could mistake a partial outline for a review of everything supplied. That is a plausible consequence of the output, not a measured participant outcome.

The repair and its acceptance condition

We kept the tool deliberately line based. The repair requires supported whole-line syntax and matching simple HTML heading tags, and reports unsupported nonempty lines by number. Nested markup and full HTML documents remain outside its supported input; the tool explains how to supply a heading level and its text instead.

For each of the three original inputs, the acceptance condition became zero recognized headings and line 1 identified as unrecognized. Rejecting unsupported input clearly was the chosen behavior; extracting every possible HTML structure was not the implemented repair.

The repair was released in revision 0ff411a on October 19. The original nine-fixture browser check matched the expected counts and placed focus on the results heading. The retained input examples describe their expected outputs and limits.

Retest evidence and what it closes

For this article we replayed the archived parser and compared its output with the retained original results. They matched. We then ran the same three inputs against the current parser at revision 40d36a8; all three returned the required unrecognized-line result. All 11 existing parser regression tests passed. The downloadable record gives the full revisions, execution environment and timestamp.

That closes the defined parser repair against its acceptance condition. It does not establish that the whole tool or site conforms to WCAG, and it does not convert source execution into a fresh browser test.

Later, separate keyboard and real-NVDA sessions checked error recovery. In the NVDA record, the captured automatic output announced the results heading; explicit reading exposed the counts and correction instructions. Those sessions add task evidence after the repair. There is no before-state NVDA record here, so we do not claim a measured before-and-after screen-reader improvement.

Download the completed finding

• Completed maintenance finding, revisions, outputs and limitations (JSON)
• Three input cases with before and current source results (CSV)

Use these as examples of an evidence trail. They contain synthetic text from our own project and are separate from the blank WCAG evidence template. For a different product, record its own observations and criteria; do not copy our result as proof.

Prioritize repairs and retest the affected task

Agree on a severity scale rather than treating a tool’s labels as a universal ordering. Consider whether a task is blocked, how often the component occurs, whether a usable alternative exists and which users may be affected. Keep engineering effort and commercial scheduling separate from the observed barrier.

Before implementation, write an acceptance condition precise enough to test. After implementation, repeat the relevant steps and check affected shared components and nearby states. Preserve both the original and retest records. Use outcomes such as verified for the stated condition, still reproducible, blocked by access, or not retested. A changed code line or a closed ticket alone is not verification.

If the product or environment changes, identify the difference and decide what needs another check. Our parser comparison used identical inputs across versions; the keyboard and NVDA sessions used different environments and remain separately labelled. VoiceOver/Safari speech, mobile assistive technology and participant usability remain outside those completed records.

Ask for a report that supports the next decision

Before engaging a provider, ask to see a sample finding and how it connects to remediation and retesting. The report should make its evaluated scope, versions, methods, evidence and unresolved questions easy to inspect. Confirm who fixes issues, who can resolve third-party dependencies, and which retest rounds are included.

Compare price and timing only against that written scope. This page does not present a market survey or a fixed turnaround promise. Membership, course completion and professional certification are different claims; ask what experience and evidence the proposed team brings to your actual work.

Grow Wild publishes the completed owned-project work above so readers can inspect the method. To prepare your own evaluation, use the scope builder and scope checklist. For help, request a preliminary review; agree on the work and deliverables before treating an enquiry as a full audit engagement.

Editorial update

The October 19 revision replaces unsupported fixed detection percentages, generic price and duration ranges, broad legal assertions and blanket service promises with scoped technical guidance and inspectable project evidence. The original URL and publication date are retained. This article does not determine legal compliance or promise a whole-site conformance result.