A website accessibility audit is a structured evaluation of your site against WCAG 2.1 AA to find barriers that block people with disabilities. A real audit combines an automated scan with manual testing and assistive-technology testing, then documents and prioritizes every issue so it can be fixed.
Why audit your website at all
Most accessibility problems are invisible to the people who built the site. A keyboard user can’t reach your menu, a screen reader announces a button as “clickable” with no label, or a form rejects input without telling anyone why. An audit makes those barriers visible.
There are three reasons to do one:
- People. Roughly one in four US adults lives with a disability. If they can’t use your site, you’ve shut the door on them.
- Law. Under ADA Title III, courts have repeatedly treated business websites as “places of public accommodation.” The DOJ points to WCAG as the practical yardstick, and thousands of ADA web lawsuits and demand letters are filed every year. (This guide isn’t legal advice — talk to an attorney about your specific risk.)
- Quality. Accessible sites are usually faster, cleaner, and better for SEO. The audit doubles as a code-health review.
This is the opposite of installing an overlay widget. Overlays bolt a script onto your site and claim instant compliance, but they don’t fix the underlying HTML — and audits test the real page, not the widget. The durable path is to find the barriers and fix them in the code.
The accessibility audit process, step by step
A complete audit follows the same six stages whether you do it in-house or hire it out. Each one catches problems the others miss.
1. Define the scope and standard
You can’t test “the whole internet’s worth of pages” by hand, and you don’t need to. Pick a representative set:
- Your homepage and primary navigation
- Each unique page template (product page, blog post, landing page)
- The critical conversion flows end-to-end — checkout, booking, contact, account sign-up
Then set the target. For almost every US business that’s WCAG 2.1 AA, the level the DOJ, courts, and most settlements reference. (Section 508, which governs federal agencies and contractors, also maps to WCAG.) WCAG is organized around four POUR principles — Perceivable, Operable, Understandable, Robust — and three conformance levels, A, AA, and AAA. AA is the realistic legal benchmark; AAA is aspirational. See the POUR principles and conformance levels for the full breakdown.
2. Run an automated scan
Start with automation because it’s fast and free. Tools like axe DevTools, WAVE, or Lighthouse crawl the page and flag machine-detectable problems:
- Missing or empty alt text
- Insufficient color contrast
- Form fields without programmatic labels
- Broken or misused ARIA attributes
- Missing page language or document structure
The catch: automated tools find only about 30–40% of WCAG issues. They tell you an image has alt text, not whether that text is meaningful. They flag a missing label, but they can’t tell you the focus order is illogical. Treat the scan as a starting point, never the finish line. We go deeper on this split in automated vs manual testing.
3. Test manually against WCAG
This is where the real audit happens. A trained tester works through each WCAG 2.1 AA success criterion by hand, checking the things automation can’t judge:
| Area | What you’re checking |
|---|---|
| Keyboard navigation | Every link, button, menu, and form usable with Tab/Enter/arrows — no mouse |
| Focus management | Visible focus indicator, logical order, no keyboard traps in modals |
| Headings & landmarks | A sensible heading hierarchy and proper page regions |
| Name, role, value | Custom widgets expose what they are and what they do to assistive technology |
| Meaningful sequence | Content makes sense when CSS or images are stripped away |
| Error handling | Forms explain errors and how to fix them |
Manual testing is judgment work. It’s why a thorough audit can’t be reduced to a single button — and why our manual accessibility testing is hands-on, not script-driven.
4. Test with assistive technology
Now use the site the way disabled people actually do. Two passes matter most:
- Keyboard only. Unplug the mouse. Can you complete every flow? Can you see where focus is at all times?
- Screen reader. Run the same flows with NVDA or JAWS on Windows, or VoiceOver on macOS/iOS. Listen for unlabeled controls, content read in the wrong order, and dynamic updates the screen reader never announces.
This step routinely uncovers barriers that passed every automated check. A “Submit” button that reads as “button,” a modal that traps focus, a carousel that’s a black hole to a screen reader — these only surface when a human drives the assistive technology.
5. Document the findings
An audit is only as useful as its report. For every issue, record:
- The barrier — what’s broken, in plain language
- The WCAG criterion it violates (e.g., 1.4.3 Contrast, 2.1.1 Keyboard)
- Severity — does it block a task, or just degrade the experience?
- Location — page URL and the specific element
- Recommended fix — the actual code change, not “make it accessible”
Done well, this report becomes your remediation plan. It’s also the raw material for a VPAT if a customer or government contract asks for a formal conformance report — see our VPAT / accessibility conformance report service.
6. Prioritize and remediate
You won’t fix everything at once, so rank issues by user impact and legal exposure:
- Critical — blocks a core task for a whole group of users (an inaccessible checkout, a keyboard trap). Fix first.
- Serious — significant friction (poor contrast, missing labels). Fix next.
- Moderate / minor — quality issues that improve the experience but don’t block it.
Then remediate — change the code. Add real labels, fix the contrast, make the widget keyboard-operable, correct the heading order. After fixes land, re-test to confirm the barrier is gone and nothing regressed. Remediation and audit are a loop, not a one-time event. Curbcut’s accessibility remediation team does this by hand, then re-audits to verify.
What a real audit covers (vs. what a scanner sees)
| Issue | Automated scan | Manual + AT testing |
|---|---|---|
| Missing alt text | Detects | Detects + judges quality |
| Low color contrast | Detects | Detects edge cases |
| Keyboard operability | Misses most | Detects |
| Logical focus order | Misses | Detects |
| Screen-reader announcements | Misses | Detects |
| Meaningful link/button names | Partial | Detects |
| Dynamic content updates (ARIA live) | Partial | Detects |
The pattern is clear: automation handles the easy 30–40%, and a human handles the rest. Anyone selling “fully automated compliance” — including overlay vendors — is skipping the part of the audit that actually protects users and reduces legal risk.
After the audit: turning findings into fixes
A report on a shelf doesn’t help anyone. The point of the audit is the fix. Once you have a prioritized list, you can hand it to your developers or to us. Either way, every barrier on that list is fixable in the code — that’s the whole premise of manual remediation, and the reason overlays fall short.
Want to skip straight to a verdict? Our accessibility audit service runs all six stages and hands you a plain-language report plus a fix-it plan. Or start with a free scan to see where you stand today.
Authoritative resources
- W3C Web Accessibility Initiative (WAI) — the source of WCAG and the official Easy Checks
- ADA.gov — the DOJ’s guidance on web accessibility and the ADA
- WebAIM — practical testing techniques and the WAVE tool
- Section508.gov — federal accessibility requirements and testing guidance