Free Website Accessibility Audit

What an accessibility audit actually covers

An accessibility audit is a systematic evaluation of a website against a defined standard, almost always WCAG 2.1 Level AA. The goal is to identify every place where someone using assistive technology would hit a barrier: content they can't perceive, controls they can't operate, information they can't understand, or components that don't work with their tools.

WCAG 2.1 Level AA includes 50 success criteria, and an audit checks each one against the pages and functionality on your site. Some criteria are binary (either the page has a language attribute or it doesn't). Others require judgment (is this alt text actually useful, or is it just the file name?). This distinction matters because it determines what automated tools can handle versus what needs a human reviewer.

The audit produces a report that maps each violation to a specific WCAG criterion, identifies the affected element on the page (often with a CSS selector or screenshot), explains why it fails, and provides a recommended fix. A good audit report is actionable: a developer should be able to read it and know exactly what to change without guessing.

The four pillars of WCAG

Every WCAG criterion falls under one of four principles, and understanding them helps you think about accessibility systematically rather than as a checklist of unrelated requirements.

Perceivable means users must be able to perceive the content through at least one sense. A blind user perceives images through alt text read by a screen reader. A deaf user perceives video through captions. A color-blind user perceives meaning through patterns or labels, not color alone. When content fails perceivability, some users literally cannot know it exists.

Operable means users must be able to interact with all controls and navigation. A keyboard user must be able to reach every button, link, and form field. A user with a motor impairment must have enough time to complete tasks. No content should cause seizures through rapid flashing. Navigation must be consistent so users can predict where things are.

Understandable means content must be readable and the interface predictable. The page language must be declared so screen readers pronounce words correctly. Form inputs must clearly indicate what's expected. Error messages must explain what went wrong and how to fix it. Components that appear on multiple pages should behave consistently.

Robust means content must work with current and future assistive technologies. HTML must be well-formed so parsing doesn't break. Custom interactive components need proper ARIA roles, states, and properties so screen readers can communicate their purpose and behavior. Status messages that appear dynamically must be announced without disrupting the user's focus.

Automated audits vs. manual audits

This is probably the most important distinction to understand when planning an accessibility audit. Automated and manual approaches serve different purposes, catch different things, and cost very different amounts. Most organizations need both, but in different proportions depending on their situation.

What automated auditing does well

Automated tools excel at finding structural violations that can be evaluated by inspecting the HTML. Does this image have an alt attribute? Does this text meet the contrast ratio? Is this form input associated with a label? Does the page declare a language? Is the heading hierarchy sequential? These checks are objective, fast, and consistent. An automated tool can scan a thousand pages in the time it takes a human auditor to review one.

The coverage is about 30 to 40% of WCAG 2.1 Level AA criteria, but those criteria cover the issues that appear most frequently. The WebAIM Million study found that 95.9% of home pages have at least one automatically detectable error. The average page has over 50 errors. Automated scanning catches all of these.

Automated auditing also scales in a way manual testing never can. You can scan every page on your site, scan after every deployment, scan on a schedule, and get alerts when new violations appear. This makes it ideal for ongoing monitoring and catching regressions before they affect users.

What requires manual testing

Some accessibility criteria require human judgment that no algorithm can replicate. Here are the areas where manual auditing matters most:

Keyboard interaction patterns. An automated tool can check whether an element is focusable, but it can't tell whether the focus order makes sense. It can't test whether a custom dropdown menu opens with Enter and closes with Escape. It can't verify that a modal dialog traps focus correctly and returns focus to the trigger when it closes. These patterns matter enormously for keyboard users, and they require someone to actually navigate the interface.

Screen reader experience. Automated tools verify that ARIA attributes are syntactically correct, but they can't evaluate whether the screen reader experience is actually good. Does the screen reader announce that a button opens a menu? When the menu opens, does focus move to the first item? When you select an option, is the result announced? These interaction flows require testing with real assistive technology.

Content quality. A tool can check that alt text exists, but it can't evaluate whether it's useful. "Image" as alt text technically passes the automated check but fails the real-world test because it tells the user nothing. Similarly, link text like "click here" passes automation but fails for screen reader users who navigate by links and hear a list of "click here, click here, click here" with no context.

Cognitive accessibility. WCAG criteria around readability, predictability, and error prevention require human judgment. Is the language clear? Are instructions understandable? Do form error messages actually explain what went wrong? These are qualitative assessments that automation can't make.

The right balance for most organizations

For most websites, the practical approach is heavy automation supplemented by targeted manual testing. Run automated scans continuously to catch the structural issues. Then do manual testing of your key user flows: the paths that matter most to your business and your users. For a retail site, that's product search, product pages, and checkout. For a service business, that's the contact form and any scheduling or booking flow. For a content site, it's navigation, search, and reading experience.

A full manual audit of an entire website is expensive and time-consuming. But a focused manual audit of your critical flows gives you the most important coverage at a reasonable cost. And continuous automated monitoring ensures that the structural issues stay fixed over time.

Understanding your audit report

An accessibility audit report can feel overwhelming the first time you see one. A typical small business website generates 20 to 100+ findings, and even a well-built site usually has a handful. The key is knowing how to prioritize so you're fixing the things that matter most first.

Severity levels explained

Most audit reports categorize findings by severity. The exact names vary between tools, but the concept is consistent:

• Critical: The issue completely blocks access for some users. A keyboard trap that prevents navigation past a certain point. A form with no labels at all, making it impossible for a screen reader user to know what information to enter. An auto-playing video with no way to pause it. These need to be fixed immediately.
• Serious: The issue creates a significant barrier but doesn't completely block access. Missing alt text on informational images. Contrast ratios below the minimum but not dramatically so. Interactive elements that are hard to reach by keyboard but not impossible. These should be fixed soon.
• Moderate: The issue degrades the experience but users can still accomplish their goal. Heading levels that skip from h2 to h4. Links that open in new tabs without warning. Form fields with labels that aren't programmatically associated but are visually adjacent. Fix these after the critical and serious issues.
• Minor: The issue is a best-practice violation that has minimal impact on actual usability. Redundant ARIA attributes. Deprecated HTML elements that still function correctly. These are worth fixing but shouldn't take priority over higher-severity items.

How to prioritize fixes

Start with critical issues because they represent complete barriers to access. A keyboard trap on your checkout page means keyboard users literally cannot buy from you. An unlabeled login form means screen reader users cannot sign in. These aren't usability inconveniences; they're dead ends.

Then work through serious issues, starting with the ones that appear most frequently across your site. If every product image is missing alt text, fixing that one issue type resolves hundreds of individual findings. Look for patterns rather than treating each finding as a separate task.

Group fixes by type rather than by page. It's more efficient to fix all contrast issues at once (usually by updating your CSS variables) than to fix one page at a time. Similarly, if form labels are missing across your site, the fix is probably in a shared template or component that affects all forms at once.

Why ongoing auditing matters more than a one-time fix

The biggest misconception about accessibility is that it's a project with an end date. You audit, you fix, you're done. In reality, accessibility is a moving target because your website is a living thing that changes constantly.

Every blog post your team publishes could include images without alt text. Every new product page could have form fields without labels. Every theme or plugin update could break the heading hierarchy or introduce keyboard traps. Every JavaScript feature your developers build could ignore screen reader announcements. Content management systems make it easy for non-technical users to publish content, and those users almost never think about accessibility because no one trained them to.

The data backs this up. Businesses that fix all their accessibility issues after an audit typically see new violations appear within weeks, introduced by routine content updates and code changes. Some businesses that were sued and remediated their sites have been sued again within a year because new violations appeared after the fix.

Continuous automated scanning solves this problem. By checking your site regularly and alerting you to new issues as they appear, you can fix them before they accumulate into the kind of pervasive violations that attract legal attention. It's the difference between mopping up a small spill and dealing with a flooded basement.

What a monitoring workflow looks like

A practical accessibility monitoring setup has three components. First, automated scans run on a schedule (daily or weekly depending on how often your site changes) and flag any new violations. Second, those findings get routed to the right person: content-related issues to your content team, code-level issues to your developers. Third, you track resolution to make sure findings don't sit in a queue indefinitely.

adaproof handles the first two parts. It scans your site against WCAG 2.1 Level AA, categorizes findings by severity, identifies exactly which element is failing and why, and alerts you when new issues appear. Your team handles the fixes, and the next scan confirms they're resolved.

Frequently asked questions

Related tools: Home · ADA compliance checker · WCAG compliance checker · Website accessibility checker · ADA website compliance · ADA compliance for ecommerce · ADA compliance for small business