Process

How to Conduct an Accessibility Audit: A Step-by-Step Guide

By EZUD Published · Updated

How to Conduct an Accessibility Audit: A Step-by-Step Guide

An accessibility audit is a systematic evaluation of a digital product against established standards, most commonly the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. It identifies barriers that prevent people with disabilities from using your product effectively. Whether performed in-house or by an external firm, a well-executed audit provides the foundation for meaningful accessibility improvements.

Define the Scope

Before testing begins, clearly define what you are auditing.

  • Pages or screens. For websites, select a representative sample: the homepage, key landing pages, forms, interactive features (search, checkout, media players), and at least one page of each template type. WCAG-EM (Website Accessibility Conformance Evaluation Methodology) from the W3C provides a structured sampling approach.
  • Conformance target. Most organizations target WCAG 2.2 Level AA, which covers the broadest range of accessibility requirements. Government-facing products in the U.S. must also meet Section 508 requirements, which reference WCAG 2.0 Level AA.
  • Platforms and technologies. Specify browsers, operating systems, and assistive technologies included in the evaluation (for example, Chrome with NVDA on Windows, Safari with VoiceOver on macOS and iOS).

Choose Your Testing Methodology

A thorough audit combines three approaches.

Automated Testing

Automated tools scan code for detectable violations. Popular options include:

  • axe DevTools (Deque): Browser extension and CI integration that catches a wide range of WCAG issues
  • WAVE (WebAIM): Visual overlay highlighting errors, alerts, and structural elements
  • Accessibility Insights (Microsoft): Guided manual assessments alongside automated checks
  • Pa11y: Open-source command-line tool for CI/CD pipelines

Automated testing identifies approximately 30-40% of WCAG issues, according to research from Deque. It reliably catches missing alt text, insufficient color contrast, missing form labels, and improper heading structure. It cannot evaluate whether alt text is meaningful, whether focus order is logical, or whether custom widgets are operable.

For a deeper comparison, see our article on automated vs. manual accessibility testing.

Manual Expert Testing

An accessibility expert navigates the product using:

  • Keyboard only. Every interactive element must be reachable, operable, and dismissible with keyboard alone. Focus must be visible at all times.
  • Screen readers. NVDA or JAWS on Windows, VoiceOver on macOS/iOS, TalkBack on Android. The expert verifies that all content is announced correctly, interactive elements have appropriate roles and names, and dynamic content updates are communicated.
  • Magnification. Content should reflow at 200% and 400% zoom without loss of functionality (WCAG 1.4.10 Reflow).
  • Voice control. Dragon NaturallySpeaking or Voice Control (macOS) to verify that interactive elements are operable via voice.

Usability Testing with Disabled Users

No audit is complete without feedback from people who use assistive technology daily. They identify real-world barriers that tools and experts may miss. See our detailed guide on user testing with people with disabilities.

Document Findings

For each issue, record:

  • WCAG success criterion (for example, 1.1.1 Non-text Content)
  • Severity (critical, major, minor, best practice)
  • Location (page URL, component, or screen)
  • Description of the barrier
  • Steps to reproduce
  • Recommended fix
  • Screenshots or screen recordings where helpful

Use a consistent template so findings can be triaged systematically. Our article on accessibility bug triage and prioritization covers how to rank and schedule fixes.

Prioritize Remediation

Not all issues carry equal weight. Prioritize by:

  1. Impact on users. Issues that block task completion for assistive technology users are critical.
  2. Number of users affected. Issues on high-traffic pages or core workflows have wider impact.
  3. Legal risk. Issues tied to established legal requirements (Section 508, ADA Title III case law) carry compliance risk.
  4. Effort to fix. Quick wins build momentum and demonstrate progress.

Feed priorities into a remediation plan with clear timelines and ownership.

Report and Communicate

The audit report should be actionable and audience-appropriate.

  • Executive summary for leadership: conformance level, risk areas, and recommended investment
  • Detailed findings for designers and developers: per-issue guidance with code examples
  • Metrics dashboard for ongoing tracking: issue counts by severity, conformance percentage, trend over time (see accessibility metrics and dashboards)

If the product is sold to government agencies or enterprises with procurement requirements, the audit may inform a VPAT/ACR.

Schedule Recurring Audits

A single audit is a snapshot. Products change with every release. Establish a cadence:

  • Automated scans on every build via CI/CD
  • Manual expert audit quarterly or after major releases
  • Usability testing at least annually, or when introducing significant new features

For ongoing monitoring approaches, see continuous accessibility monitoring.

Key Takeaways

  • Scope the audit carefully using WCAG-EM sampling methodology.
  • Combine automated, manual expert, and user testing for comprehensive coverage.
  • Document each issue with its WCAG criterion, severity, and recommended fix.
  • Prioritize by user impact, reach, legal risk, and effort.
  • Make audits recurring, not one-time events.

Sources

More in Process

Inclusive Design Process Guide: Building Accessibility Into Every Stage Guide Continuous Accessibility Monitoring Accessibility in Design Reviews Nothing About Us Without Us: The Principle That Shapes Inclusive Design

View all Process articles →