Skip to content

How to Conduct a Professional Accessibility Audit and Report Findings

Plan, test, document, remediate, validate, and report a manual accessibility assessment with a traceable WCAG record.

A professional accessibility audit is a structured investigation of how people with disabilities can use a product. It requires more than running a scanner or listing visual defects. The auditor must define representative scope, use suitable test methods, connect observations to the right requirements, explain user impact, and preserve enough evidence for another person to understand and retest the issue.

The problem this guide solves

Accessibility work often loses quality between discovery and delivery. A tester may record a short bug title but omit the affected flow, actual result, expected behavior, or assistive-technology context. Developers then cannot reproduce the issue, managers cannot prioritize it, and a later report cannot explain conformance. Another common failure is treating every automated alert as a confirmed violation while overlooking criteria that require human judgment.

Understand the standard and the boundary

WCAG 2.2 is organized under the principles perceivable, operable, understandable, and robust, with success criteria at Levels A, AA, and AAA. W3C explains that WCAG criteria are technology-neutral testable statements and provides supporting Understanding and technique resources. A complete evaluation still requires knowledgeable human testing. The selected version and target level must remain consistent across scope, requirement choices, automated candidates, and reporting.

Read the W3C WCAG 2 overview

Who this workflow helps

  • Students and educators teaching practical accessibility evaluation.
  • Independent auditors and agencies delivering paid assessments.
  • Design, engineering, quality, and content teams fixing accessibility barriers.
  • Schools, public bodies, procurement teams, and organizations with accessibility responsibilities.

A professional workflow

A dependable assessment does not begin with a report button. It begins with a clear question, defined scope, the correct standard, suitable test methods, and a record that another authorized reviewer can follow. The sequence below is designed to preserve that chain. Adapt its depth to the engagement, but do not remove the review decisions merely to make the process appear faster.

  1. Agree on the product, environments, pages, user flows, technologies, exclusions, and target WCAG level.
  2. Choose representative content and states rather than testing only the home page.
  3. Test keyboard behavior, focus, structure, names and roles, text alternatives, contrast, zoom, reflow, forms, errors, media, and relevant assistive technologies.
  4. Use automated tools to find candidate issues, then validate each candidate manually.
  5. Write one clear finding for a coherent problem and map only the criteria it actually affects.
  6. Assign remediation, answer questions in context, and retest the changed experience.
  7. Generate a reviewed findings export or ACR that accurately states methods and limitations.

What to record

Record enough information to support reproduction, assignment, remediation, validation, and reporting. Each field should have one clear purpose. Keep identifiers and quoted evidence exact, distinguish observations from recommendations, and avoid collecting secrets or personal information that the work does not require. A smaller complete record is more useful than a large collection of disconnected text and files.

  • A concise summary that names the user-facing failure.
  • Description, affected page or component, actual result, and expected result.
  • Steps or conditions needed to reproduce the behavior.
  • Severity based on user impact and project policy, not scanner labels alone.
  • The most precise WCAG success criterion and valid W3C reference.
  • Practical remediation guidance without prescribing unsupported code.
  • Retest evidence, validation result, owner, status, and due date.

How voiqq supports the work

voiqq uses one project and finding foundation across Programs while each Library controls its own requirements, fields, metrics, mapping, automation boundary, and report rules. That means teams can reuse assignments, comments, evidence, validation, history, permissions, imports, exports, and recovery without pretending that every standard reaches the same kind of conclusion.

voiqq gives accessibility projects canonical WCAG libraries, project-level version and level filtering, structured findings, comments, assignments, evidence, validation, spreadsheet import, and local axe-core candidate collection. The same reviewed project can produce a formatted spreadsheet, a controlled share view, or a template-preserving VPAT or ACR snapshot. Automated candidates remain visibly Pending until an auditor validates them.

Quality checks before sharing

  • Sample enough pages and states to represent the product, including authenticated and error flows where authorized.
  • Check that each criterion mapping matches the actual failure rather than a broad topic.
  • Remove technical selectors and raw tracker language from client-facing remarks unless needed as evidence.
  • Verify that fixes work for the affected user interaction and did not create a new barrier.
  • State excluded areas, testing constraints, and untested criteria plainly.

Before distribution, ask a second question beyond whether the file generated: can the intended reader understand the scope, trace important statements to project evidence, distinguish active and resolved work, and see the limits of the conclusion? Review permissions and attachments as carefully as report wording. Preserve an approved snapshot when the deliverable must remain stable after the live project changes.

A practical next step

Start with one representative user flow and document it completely. That small example should show the level of evidence, mapping, remediation, and validation expected for the rest of the engagement. A consistent record is easier to review, easier to fix, and far easier to convert into a credible report.

Treat the first result as a review draft. Check it with the people who perform the work and the people who receive the outcome. Their questions will reveal missing context, confusing terminology, weak permissions, and report assumptions sooner than another decorative dashboard will. Improve the project model, then repeat the same disciplined workflow.


Start free with voiqq

Open the WCAG 2.2 library guide