Accessibility Audits Demystified: Tools and Techniques for Inclusive Design

Accessibility audits are the diagnostic backbone of inclusive design. Without them, even well-intentioned teams can launch products that exclude millions of users—people who rely on screen readers, keyboard navigation, or high-contrast displays. Yet many teams avoid audits because they seem complex, time-consuming, or overly technical. This guide breaks down the audit process into practical steps, tools, and decision points, so you can start identifying and fixing barriers in your own projects.

We'll walk through who needs an audit and what goes wrong without one, the prerequisites you should settle before starting, a core workflow that works for most projects, and how to adapt when constraints force trade-offs. Along the way, we'll highlight common pitfalls and answer frequent questions. By the end, you'll have a concrete plan for running audits that produce real improvements—not just a checklist of issues.

Why Audits Matter and What Happens Without Them

An accessibility audit is a systematic evaluation of a digital product against established guidelines—most often the Web Content Accessibility Guidelines (WCAG). The goal is to find barriers that prevent people with disabilities from using the product effectively. But audits are not just about compliance; they are about understanding the user experience from perspectives different from your own.

Without regular audits, teams often rely on assumptions. A developer might test with a mouse and assume keyboard users are fine. A designer might use a color palette that looks clean but fails for someone with color blindness. These gaps accumulate. Over time, the product becomes a patchwork of inaccessible features, frustrating users and increasing support costs. Many industry surveys suggest that fixing accessibility issues after launch costs significantly more than addressing them during design—yet many organizations still skip audits until a legal complaint or public backlash forces their hand.

The Ethical and Business Case for Audits

Accessibility is fundamentally about equity. The web was designed to be universal, and every barrier we leave in place excludes someone from information, services, or community. Audits help us honor that original promise. But the business case is equally strong: accessible products reach a larger audience, improve SEO, and reduce legal risk. In many regions, accessibility is a legal requirement under laws like the Americans with Disabilities Act (ADA) or the European Accessibility Act. Audits are the primary way to demonstrate due diligence.

What Goes Wrong Without an Audit

Consider a typical scenario: a team launches a new e-commerce site without an audit. A user who relies on a screen reader tries to purchase an item. The checkout button is not labeled properly, so the screen reader announces nothing. The user cannot complete the purchase. They leave frustrated, possibly never to return. Multiply that by thousands of users, and the business impact is clear. But the human impact is deeper: that user feels excluded, reminded that the digital world was not built for them. Audits prevent these moments by catching issues before they reach production.

Another common failure is reliance on automated tools alone. Automated checkers can catch about 30% of WCAG failures—things like missing alt text or low color contrast. But they miss contextual issues like unclear form instructions or keyboard traps. An audit that relies only on automation gives a false sense of security. Teams may think they are compliant when they are not.

This guide is general information only, not legal advice. For specific compliance requirements, consult a qualified professional or refer to official regulatory guidance.

Prerequisites: What to Settle Before Starting an Audit

Before you dive into testing, you need to establish a foundation. Skipping these steps leads to disorganized audits that miss critical issues or produce results that are hard to act on.

Define the Scope and Standards

First, decide what you are auditing. A full site audit might be overwhelming; many teams start with high-traffic pages or critical user flows (like sign-up, checkout, or search). Also decide which version of WCAG you are targeting. WCAG 2.1 is the current standard for most regulations, but some organizations have already adopted WCAG 2.2. Choose one and stick with it for the audit. Document the scope in a brief charter that includes the pages, user flows, and assistive technologies you will test.

Assemble the Right Team

An effective audit requires diverse perspectives. Include people with disabilities when possible—they bring lived experience that no tool can replicate. If your team lacks internal expertise, consider hiring a consultant or contracting with a digital accessibility firm. At minimum, the audit team should include someone familiar with WCAG criteria, someone who can test with assistive technologies (like screen readers), and a developer who can interpret findings and estimate fixes. Avoid the common mistake of assigning the audit to a single junior developer who has no training in accessibility.

Gather Baseline Information

Collect existing accessibility reports, user feedback, and any previous audit results. If the product has a design system, review its accessibility documentation. Understanding what has already been tested helps you avoid redundant work and focus on new or unresolved issues. Also gather analytics data: pages with high bounce rates or low conversion among users with disabilities (if you have that data) can indicate problem areas.

Set Up Your Testing Environment

You will need a consistent environment for manual testing. Use a standard browser (Chrome or Firefox) with developer tools, a screen reader (NVDA on Windows or VoiceOver on Mac), and keyboard-only navigation. For mobile testing, use the built-in screen reader (TalkBack on Android, VoiceOver on iOS). Document the versions you use, because assistive technology behavior changes with updates. Also prepare test accounts or sample data if the site requires login.

Finally, set expectations with stakeholders. Explain that an audit will uncover issues, some of which may require significant rework. Get buy-in to allocate time for fixes after the audit. Without that commitment, the audit becomes a waste of effort.

Core Workflow: Step-by-Step Guide to Running an Audit

This workflow works for most web projects. Adapt the steps to your scope and timeline.

Step 1: Automated Scan

Start with an automated tool like axe DevTools, WAVE, or Lighthouse. Run it on the pages in your scope. Automated tools flag issues like missing alt text, insufficient color contrast, and missing form labels. Export the results as a CSV or JSON file. These results give you a quick baseline, but remember: automation catches only a fraction of problems. Treat this as a triage step, not a final verdict.

Step 2: Manual Keyboard Testing

Disconnect your mouse and navigate the entire page using only the keyboard. Use Tab to move through interactive elements, Shift+Tab to go backward, and Enter/Space to activate. Check for visible focus indicators—every interactive element should have a clear outline when focused. Watch for keyboard traps: situations where focus gets stuck and you cannot move away. Also test all custom widgets (like dropdowns, sliders, or modals) to ensure they are keyboard accessible.

Step 3: Screen Reader Testing

Use a screen reader to navigate the same pages. On Windows, NVDA is free and widely used. On Mac, VoiceOver is built in. Listen to how the page is announced. Check that headings are read correctly, that images have meaningful alt text, and that form fields have proper labels. Pay attention to dynamic content: when a modal opens or an error message appears, does the screen reader announce it? Test both linear navigation (arrow keys) and navigation by headings or landmarks.

Step 4: Visual and Content Review

Check color contrast using a tool like the Colour Contrast Analyser. Verify that text meets WCAG AA contrast ratios (4.5:1 for normal text, 3:1 for large text). Test the page with a zoom of 200% and 400% to ensure content does not overlap or disappear. Check that text can be resized without losing functionality. Also review content for clarity: are instructions easy to understand? Are error messages helpful? Are links descriptive (not just 'click here')?

Step 5: Document Findings

Record each issue with its WCAG criterion, the page and element affected, the severity (critical, major, minor), and a suggested fix. Use a spreadsheet or an accessibility issue tracker. Include screenshots or screen recordings to help developers understand the problem. Prioritize issues that block core functionality—for example, a checkout button that screen readers cannot activate is critical. Low-contrast decorative text might be minor.

Step 6: Report and Remediate

Present the findings to the team with a summary of top issues and recommended fixes. Avoid overwhelming stakeholders with a long list; group issues by type (e.g., keyboard, screen reader, contrast) and show the most impactful ones first. Work with developers to estimate effort and schedule fixes. After fixes are deployed, run a quick re-audit on the affected pages to confirm the issues are resolved. Accessibility is iterative; one audit is not enough.

Tools and Setup: What You Actually Need

You do not need an expensive suite of tools to run a thorough audit. Free and open-source options cover most needs. The key is knowing which tool to use for which task.

Automated Checkers

axe DevTools (browser extension) is the gold standard for automated testing. It integrates with Chrome and Firefox and provides clear, actionable results. WAVE (Web Accessibility Evaluation Tool) offers a visual overlay that highlights issues directly on the page. Lighthouse, built into Chrome DevTools, gives a performance and accessibility score with recommendations. All three are free. Use axe for detailed analysis, WAVE for quick visual checks, and Lighthouse for a broad overview.

Color Contrast Analyzers

The Colour Contrast Analyser (CCA) by The Paciello Group is a free desktop app that lets you pick colors from the screen and see contrast ratios. The Stark plugin for Figma and Sketch is useful for designers. For quick checks, the built-in contrast checker in Chrome DevTools works well.

Screen Readers

NVDA (Windows) is free and the most commonly used among screen reader users. VoiceOver (Mac) is built in and reliable. For mobile, TalkBack (Android) and VoiceOver (iOS) are the standards. Learn basic keystrokes: how to navigate by headings (H key in NVDA), how to read all content (Insert+DownArrow), and how to activate links. Many teams also use the Screen Reader Testing Checklist from WebAIM to ensure consistent coverage.

Browser Extensions and Developer Tools

The Accessibility Insights extension (Windows and Mac) provides guided tests for keyboard navigation and screen reader support. Chrome DevTools has an 'Issues' tab that flags some accessibility problems. For PDFs, use the Adobe Acrobat accessibility checker. For mobile apps, use the platform-specific accessibility inspector (e.g., Android Accessibility Scanner).

Setting Up a Consistent Environment

Create a virtual machine or a dedicated testing machine with a clean installation of the browser and assistive technologies. Document the exact versions of each tool, because results can vary. For example, an issue that appears in NVDA 2023.1 might not appear in NVDA 2024.1. Consistency ensures that your audit is reproducible and that fixes can be verified against the same baseline.

If your team works in an agile environment, integrate automated checks into your CI/CD pipeline. Tools like axe-core can be run as part of your build process, flagging new accessibility issues before they reach production. This shifts left the responsibility for accessibility, making it a continuous practice rather than a periodic event.

Adapting Audits for Different Constraints

Not every project has the luxury of a full audit. Budget, time, and expertise vary. Here are common scenarios and how to adapt.

Small Teams or Tight Budgets

If you have limited resources, focus on the most critical user flows. Use automated tools as a first pass, then do a manual keyboard test on the top five pages. Recruit a colleague who is not familiar with the project to try using the site with a screen reader for 15 minutes—they will often catch issues that experts overlook. Document findings in a simple spreadsheet. Prioritize fixes that affect the most users: missing alt text on product images, unclear form labels, and missing focus indicators.

Large-Scale Redesigns

For a redesign, run an audit on the current site first to establish a baseline. Then, as new designs are created, review them before development starts. Use a design system with built-in accessibility tokens (e.g., color palettes that meet contrast ratios, focus styles, and typography scales). Conduct component-level audits on reusable patterns (buttons, forms, modals) so that once a component is fixed, all instances benefit. This reduces the audit burden over time.

Third-Party or Legacy Products

If you are auditing a product you did not build (like a SaaS platform or a legacy system), you may not be able to fix the code. In that case, focus on documenting the barriers and communicating them to the vendor. For legacy products, consider a phased approach: fix high-impact issues first (like keyboard traps) and plan a larger rewrite later. Sometimes a simple overlay or skip navigation link can mitigate a problem temporarily, but avoid relying on overlays as a long-term solution—they often introduce new issues.

Mobile and Native Apps

Mobile audits follow a similar workflow but use platform-specific tools. For iOS, use the Accessibility Inspector in Xcode. For Android, use the Accessibility Scanner app. Test with screen readers (VoiceOver on iOS, TalkBack on Android) and ensure that all touch targets are at least 48x48 dp. Check that custom gestures have alternatives (e.g., a swipe gesture should also work with a button). Mobile audits often uncover issues with dynamic content, such as announcements when a new screen loads.

Pitfalls and What to Check When the Audit Fails

Even experienced auditors make mistakes. Here are common pitfalls and how to avoid them.

Over-Reliance on Automation

The biggest mistake is assuming that a passing automated score means the site is accessible. Automated tools miss context. For example, they can check that an image has alt text, but they cannot judge whether the alt text is meaningful. A button with the text 'Submit' might pass automated checks, but if it is labeled 'Submit' for a search form, it is not descriptive. Always supplement automation with manual testing.

Testing in a Single Environment

Screen readers behave differently across browsers and operating systems. An issue that appears in NVDA with Firefox might not appear in NVDA with Chrome. Similarly, mobile screen readers have different navigation patterns. Test at least two combinations: NVDA+Firefox and VoiceOver+Safari for desktop; TalkBack+Chrome and VoiceOver+Safari for mobile. Document the environment for each finding so developers can reproduce the issue.

Ignoring Content and Language

Accessibility is not just about code. Content must be clear and readable. Common content issues include: using jargon without explanation, writing long paragraphs without headings, and providing instructions that rely on visual cues (like 'click the green button'). Review content during the audit. Also check that the page language is set correctly in the HTML (lang attribute) so that screen readers use the right pronunciation.

Not Involving Users with Disabilities

Automated tools and even manual testing by nondisabled testers cannot fully replicate the experience of someone who uses assistive technology daily. If possible, include users with disabilities in your audit. They will find issues that you would never think to test. If you cannot recruit users, at least follow established test scripts from organizations like WebAIM or the W3C's WAI.

Failing to Prioritize Fixes

After an audit, teams often feel overwhelmed by the number of issues. Without prioritization, they may fix easy items and ignore critical ones. Use a severity scale: critical (prevents use of core functionality), major (causes significant difficulty), minor (annoying but workable). Fix critical and major issues first. Also consider the impact: a low-contrast button on a page visited by 10% of users might be less urgent than a missing label on the login form used by everyone.

Frequently Asked Questions and Next Steps

How often should we run an audit?

At minimum, run a full audit before every major release or redesign. For continuous improvement, integrate automated checks into your CI/CD pipeline and run a manual audit quarterly. If you receive user complaints about accessibility, run an audit immediately.

Can we use a checklist instead of a full audit?

A checklist can help ensure consistency, but it is not a substitute for an audit. Checklists are good for catching common issues (like missing alt text), but they can miss nuanced problems that require human judgment. Use a checklist as a starting point, but always include exploratory testing.

What if we cannot fix everything?

Be transparent with users. Provide a statement about known accessibility issues and a timeline for fixes. Offer alternative ways to access the information (like email or phone support). Prioritize fixes based on impact and effort. Even partial progress is better than nothing.

Next Steps After Your First Audit

1. Create a remediation plan: List all issues with severity, effort estimate, and owner. Set a target completion date.
2. Train your team: Share common findings and teach developers how to avoid them in the future. Provide resources like the WebAIM checklist or the W3C's tutorials.
3. Update your design system: Add accessibility requirements to component documentation. For example, specify minimum contrast ratios and focus styles.
4. Schedule a re-audit: After fixes are deployed, run a targeted audit on the changed pages. Plan the next full audit for the following quarter.
5. Share results: Publish an accessibility statement on your site that includes audit results and your commitment to improvement. This builds trust with users.

Accessibility is not a one-time project; it is a practice. Each audit makes your product more inclusive and your team more aware. Start small, learn from each cycle, and keep pushing for a web that works for everyone.