An accessibility audit is the foundation of every serious accessibility program. You cannot fix what you have not found, and you cannot demonstrate compliance without a documented record of what you checked, what failed, and what you did about it.

Whether you are responding to ADA expectations, preparing for Section 508, or simply making sure your site works for every visitor, this guide walks through how to conduct a website accessibility audit from start to finish: how to scope it, what to test, how to document findings, and how to turn results into fixes.

What a Website Accessibility Audit Is (and Is Not)

An accessibility audit is a systematic evaluation of your website against a defined standard, usually WCAG 2.1 or WCAG 2.2 at Level AA. It combines automated scanning with manual testing, and it produces a documented record of issues, their severity, and the fixes required.

It is not a single click of an automated scanner. Automated tools catch roughly 30 to 40 percent of WCAG issues, and they miss many of the most serious problems, such as keyboard traps, missing focus indicators, confusing screen reader experiences, and link text that makes no sense out of context. For more detail, see our guide on automated versus manual accessibility testing.

It is also not the same thing as everyday testing. Testing is something you do continuously as you build and release. An audit is a formal, comprehensive snapshot. For a lighter introduction, see our guide on how to test the accessibility of your website. Think of the audit as the deep version you repeat on a schedule.

Why You Need an Audit

Three reasons an audit is worth the effort:

  1. Legal risk. Web accessibility lawsuits and demand letters number in the thousands each year, and regulators increasingly expect organizations to know their conformance status. An audit shows exactly where you stand against the standard. To understand the levels you will be measured against, see our guide on the levels of WCAG compliance.
  2. Real users. An audit is how you find the barriers that quietly cost you customers: the form a screen reader user cannot complete, the menu a keyboard user cannot open, the video a deaf visitor cannot follow.
  3. A clear plan. An audit produces a prioritized list, so instead of fixing issues randomly as they surface, your team works through them in order of impact.

Step 1: Define the Scope and the Standard

Decide in writing what you are auditing:

  • The standard. For most organizations, WCAG 2.1 or WCAG 2.2 Level AA is the target. Government teams working under Section 508 also anchor to WCAG Level AA. Healthcare, education, and finance often add selected Level AAA criteria on top.
  • The scope. Your public website, or also your subdomains, web applications, authenticated portals, mobile web, and PDFs and other downloadable documents?
  • Representative templates. You do not need to test every page. You do need to test every unique template and interactive pattern.
  • The definition of done. Zero known Level A failures? A documented plan for every Level AA issue? Agree on the goal before you start.

Write the scope down. Scope creep is the number one reason audits stall, and a written scope keeps the project honest.

Step 2: Inventory Your Templates and Key User Journeys

Map the unique page templates on your site, then choose representative examples of each. A typical sample includes:

  • The home page and main navigation
  • A standard content page and a landing page
  • Contact, signup, and other key forms
  • Search results
  • Product, pricing, or checkout pages if you sell or book online
  • Any modal, accordion, carousel, or media player
  • Downloadable documents such as PDFs linked from your pages

Then list your critical user journeys: find a product, fill out a form, complete a purchase, contact support. The audit must cover each journey from entry to completion, because that is how you find the barriers that matter most.

Step 3: Run Automated Scans First

Start with automated scanning because it is fast, inexpensive, and catches a well defined set of issues. Expect it to flag things like:

  • Missing or suspicious alt text
  • Empty links and buttons
  • Missing form labels
  • Low color contrast
  • Missing page language or page title
  • Broken heading structure

For tool options, see our roundup of 7 web accessibility testing tools. Record the findings, but do not stop there. Automated results are only the first pass, and some of the most impactful issues can only be found by a human.

Step 4: Test Manually With a Keyboard and a Screen Reader

Manual testing is where most serious findings come from. You do not need to be an expert to get real value from these four checks.

Keyboard Only

Unplug the mouse. Can you reach every link, button, form control, and menu? Is there a visible focus indicator everywhere? Can you escape modals and dropdowns, or do you get trapped? Many audits find their most severe issues right here. For details, see our deep dive on keyboard accessibility.

Screen Reader

Test with a free screen reader: NVDA on Windows or VoiceOver on Mac and iOS. Navigate a page, complete a form, buy something. Listen for images without alt text, buttons with no accessible name, confusing heading structure, and unlabeled fields. Our guide to screen reader accessibility explains what to listen for and why.

Zoom and Reflow

Zoom the page to 200 percent, and to 400 percent on mobile. Text should stay readable, and no content should be cut off or require scrolling in two directions. WCAG 2.2 added specific criteria for reflow and focus appearance, and manual zoom testing catches failures quickly.

Content Quality

Check for plain language, meaningful link text (every “click here” fails this test), descriptive headings in a logical order, and captions or transcripts on all media. This is the part of an audit where judgment matters most and automated tools are nearly silent.

Step 5: Document Every Finding

For each issue, record:

  1. The page and location where it was found
  2. The WCAG success criterion it fails, such as 1.1.1 Non-text Content or 2.4.7 Focus Visible
  3. The severity: blocker, serious, or moderate
  4. Who it affects and how
  5. The fix, described concretely enough for a developer to act on
  6. A screenshot or code snippet where helpful

Severity matters more than count. One keyboard trap on your checkout page is worse than fifty low contrast footnotes, and a good report says so plainly.

Step 6: Prioritize and Remediate

Turn findings into a prioritized remediation plan. A sensible order:

  1. Blockers that stop users cold: keyboard traps, inaccessible forms, broken navigation
  2. Serious issues on major journeys: missing labels, missing captions, poor focus visibility
  3. Moderate issues: low contrast, heading order problems, vague link text
  4. Enhancements: improved screen reader announcements, better error recovery

Assign owners and due dates, then track every fix to closure. If you want a reference list to work from, our complete ADA compliance checklist is a good starting point, and our roundup of the most common accessibility issues shows how to fix the problems that appear on nearly every audit.

One warning: do not rely on an overlay widget to “fix” the findings. Overlays cannot repair structural problems and frequently introduce new ones. See our explanation of why accessibility overlays fall short.

Step 7: Re-Test and Keep Monitoring

After fixes ship, re-run the automated scan and manually re-test the repaired templates, including every journey that had a blocker. Fixes sometimes break other things, so verify rather than assume.

Then keep monitoring. Sites drift as content and code change, and accessibility is not a one time project. A reasonable schedule: automated scans monthly or continuously, and a full manual audit at least once a year or after any major redesign. A monitoring service like Accessible Metrics catches new issues when they appear, instead of waiting for the next audit to find them.

Should You Audit In-House or Hire Someone?

A motivated in-house team can run a solid first pass using the steps above, and doing so builds useful skills. Consider bringing in an external specialist when the stakes are high: a legal demand letter, a government contract, a complex web application, or when you need a formal document such as an accessibility conformance report. For guidance, see our article on what to look for when hiring a web accessibility specialist.

Whichever route you choose, keep the paperwork. Scope documents, findings, remediation plans, and before and after scan results are exactly the kind of evidence that demonstrates a good faith effort. For more on what to keep, see our guide on must-have ADA accessibility compliance documentation.

The Bottom Line

A website accessibility audit is a defined process, not a mystery: set the scope, sample your templates, scan automatically, test manually with a keyboard and screen reader, document and prioritize findings, fix and re-test, then monitor continuously. Done honestly, an audit gives you three things: a clear picture of where you stand, a prioritized plan, and documented evidence of your effort.

Ready to start with the fastest part of the audit? Sign up for Accessible Metrics and scan your website for free. You will get a report mapped to WCAG standards that flags missing alt text, low contrast text, missing form labels, heading problems, and more, with plain language guidance for fixing each issue. Run your free scan today and make your next audit that much easier.