Website Accessibility Audit: Your 2026 ADA & WCAG Guide
Website Accessibility Audit: Your 2026 ADA & WCAG Guide
A website accessibility audit is a structured evaluation of your site against WCAG 2.2 success criteria to find barriers that block people with disabilities from using your content, and to produce a prioritized remediation plan your dev team can actually act on. For most US sites, WCAG 2.2 Level AA is the target. Full stop.
Here’s what a defensible audit includes:
- Automated scan across your key pages and templates (catches roughly 30–40% of real failures)
- Manual keyboard and screen reader checks for the issues scanners miss entirely
- Prioritized remediation list with WCAG mapping, severity, and recommended fixes
Your immediate next step: run a baseline automated scan on your homepage, a product or service page, and your contact form. That 15-minute exercise will surface the most glaring issues and help you scope a full audit.
Pro Tip: Don’t stop at the automated scan. Automated tools are great for the low-hanging fruit, but they’ll never catch a confusing form label or a focus trap buried in a custom dropdown. Think of the scan as your opening move, not the whole game.
Key Takeaways
A defensible website accessibility audit combines automated scanning, manual keyboard and screen reader testing, and a prioritized remediation plan tied to WCAG 2.2 Level AA success criteria.
| Point | Details |
|---|---|
| Automated tools have limits | Scanners catch roughly 30–40% of WCAG failures; manual and AT testing are required for a complete audit. |
| WCAG 2.2 Level AA is the US target | Most ADA enforcement guidance and procurement requirements reference WCAG 2.2 Level AA as the defensible standard. |
| Prioritize by user impact | Score issues by severity times frequency times user impact to build a sprint-ready remediation roadmap. |
| Integrate accessibility into CI | Add axe-core or pa11y to your CI/CD pipeline so regressions are caught at the PR stage, not post-launch. |
| Coumba Win Design delivers audit-ready plans | Coumba Win Design’s audit deliverables include per-issue WCAG mapping, code snippets, and a retest plan developers can act on immediately. |
Table of Contents
- What does a website accessibility audit actually produce?
- Why accessibility matters for US websites right now
- When should you run an accessibility audit?
- WCAG conformance levels explained: A, AA, and AAA
- What types of accessibility audits are there?
- How to run a website accessibility audit step by step
- Common accessibility failures your audit will find
- How to prioritize and track remediation
- Which tools should you use for accessibility testing?
- How to maintain accessibility after remediation
- How Coumba Win Design runs an accessibility audit
- Why accessibility is central to good design
- Ready to get your site audited? Here’s what working with Coumba Win Design looks like
- Sources
- FAQ
What does a website accessibility audit actually produce?
A website accessibility audit is not a single-tool scan, and it’s definitely not a checkbox exercise. It’s a systematic evaluation that maps every identified barrier to a specific WCAG success criterion, explains the user impact, and tells your team exactly how to fix it.
The four POUR principles (Perceivable, Operable, Understandable, Robust) are the organizing framework behind every WCAG criterion. An audit traces each failure back to one of these:
- Perceivable: Can users perceive all content? (Think: missing alt text, low contrast)
- Operable: Can users operate all controls without a mouse? (Think: keyboard traps, no skip links)
- Understandable: Is content clear and predictable? (Think: missing form error messages, inconsistent navigation)
- Robust: Does content work with current and future assistive tech? (Think: broken ARIA, invalid HTML)
A real audit delivers per-issue documentation that includes the WCAG criterion violated, severity rating, reproduction steps, a screenshot or code snippet, and a recommended fix. That’s what separates an audit from a quick scan.
A VPAT (Voluntary Product Accessibility Template) or ACR (Accessibility Conformance Report) is a vendor-facing declaration of conformance — not an audit. An audit finds the problems; a VPAT summarizes your conformance posture after you’ve addressed them. Conflating the two is one of the most common mistakes teams make when responding to procurement requests.
Why accessibility matters for US websites right now
Here’s the uncomfortable truth: ADA Title III applies to public-facing websites, and Ada makes clear that businesses offering goods and services online are considered places of public accommodation. That means inaccessible websites carry real civil liability.
Lawsuit filings targeting website accessibility have climbed steadily, with demand letters and litigation hitting e-commerce, hospitality, and financial services especially hard. The business case goes beyond legal risk, though:
- Broader audience reach: Roughly 1 in 4 US adults lives with some form of disability (CDC data). Inaccessible sites exclude a significant slice of potential customers.
- SEO benefits: Accessible markup, proper heading structure, and descriptive alt text all improve search performance alongside compliance.
- User retention: Clear navigation, readable typography, and keyboard-friendly forms help everyone, not just users with disabilities.
The practical conclusion is simple: an audit reduces your litigation exposure and expands your usable audience at the same time. That’s a rare win-win in web strategy.
When should you run an accessibility audit?
Timing matters. A lot of teams treat accessibility as a one-and-done project, which is how regressions sneak back in six months after a redesign.
Run an audit when any of these triggers hit:
- A major redesign or CMS migration is launching
- A significant new feature (checkout flow, account portal, interactive widget) goes live
- You receive a demand letter, complaint, or legal inquiry
- A government or enterprise procurement RFP requires a VPAT or conformance statement
- Users with disabilities report specific barriers
Recommended cadence by risk level:
- High-risk sectors (healthcare, finance, e-commerce, education): quarterly automated monitoring plus an annual full manual audit
- Standard commercial sites: annual manual audit plus automated scans on every deploy
- Low-traffic informational sites: biannual manual review plus automated monitoring
For scoping, start with a representative sample: your homepage, 3–5 high-traffic templates (product page, blog post, contact form, checkout), and any custom interactive components. Full-site scans make sense for automated monitoring; manual audits work best on a curated sample that covers your template variety.
WCAG conformance levels explained: A, AA, and AAA
WCAG (Web Content Accessibility Guidelines), published by W3C, organizes success criteria into three conformance levels. Most US organizations target Level AA, and here’s why that breakdown matters:
- Level A: The bare minimum. Covers the most critical barriers (missing alt text, keyboard access). Failing Level A criteria blocks users entirely.
- Level AA: The practical US standard. Adds requirements for color contrast (4.5:1 for normal text), visible focus indicators, consistent navigation, and more. This is what ADA enforcement guidance and most procurement bodies reference.
- Level AAA: The highest level. Includes criteria like sign language interpretation and extended audio descriptions. Rarely required across an entire site; sometimes targeted for specific content types.
WCAG 2.2 (published October 2023) is the current W3C recommendation. It’s backward-compatible with 2.1 and 2.0, and it adds new criteria around focus appearance and mobile interactions that matter for modern web apps.
Mapping POUR to common Level AA failures gives you a quick mental model:
| POUR Principle | Example Level AA Failure | WCAG Criterion |
|---|---|---|
| Perceivable | Text contrast below 4.5:1 | 1.4.3 Contrast (Minimum) |
| Operable | No visible keyboard focus indicator | Focus Appearance |
| Understandable | Form inputs missing accessible labels | Labels or Instructions |
| Robust | Custom widget missing ARIA roles | Name, Role, Value |
WCAG 2.2 Level AA is the target for ADA defensibility and most US procurement requirements. Build your audit scope around it.
What types of accessibility audits are there?
Not all audits are created equal. The right type depends on your risk level, budget, and timeline.
Automated scanning uses tools like axe DevTools, Google Lighthouse, or WAVE to crawl pages and flag detectable violations. Fast, scalable, and great for continuous monitoring. The catch: automated tools catch roughly 30–40% of real WCAG failures. Meaningful alt text, logical reading order, and focus management require human judgment.
Expert manual audits involve a trained auditor working through pages with keyboard-only navigation, inspecting code, and testing ARIA implementations. This is where the nuanced failures surface. Budget 4–8 hours per template for a thorough pass.
Assistive-technology testing pairs manual review with actual screen readers (NVDA on Windows, VoiceOver on macOS/iOS) to catch announcement failures, focus order problems, and widget interaction issues that only appear in real AT environments.
User testing with people with disabilities is the gold standard for understanding real-world impact. It’s resource-intensive but invaluable for complex applications or high-stakes user flows.
| Audit Type | Coverage | Best For | Limitation |
|---|---|---|---|
| Automated scan | 30–40% of WCAG failures | Continuous monitoring, baseline | Misses semantic and content issues |
| Expert manual | around 80% with skilled auditor | Pre-launch, legal risk, procurement | Time-intensive, requires expertise |
| AT testing | Catches AT-specific failures | Custom widgets, complex flows | Requires AT knowledge and setup |
| User testing | Real-world impact | High-stakes apps, UX validation | Most resource-intensive |
For most US commercial sites, the right answer is a hybrid: automated scans on every deploy, plus a full manual audit annually or before major launches.
How to run a website accessibility audit step by step
Here’s the workflow. Follow it in order, and you’ll have a defensible audit your developers can actually use.
-
Define scope and standard. List every page template, user flow, and interactive component you’ll test. Confirm your target: WCAG 2.2 Level AA. Note the browsers, devices, and screen readers in scope (at minimum: Chrome + NVDA on Windows, Safari + VoiceOver on macOS).
-
Run baseline automated scans. Use axe DevTools, Google Lighthouse, and WAVE across your scoped pages. Export results into a shared tracker (a spreadsheet works fine). Flag duplicates across tools and deduplicate by WCAG criterion.
-
Keyboard-only manual testing. Tab through every interactive element. Check for: logical tab order, visible focus indicators on all focusable elements, no keyboard traps, skip navigation links, and full operability without a mouse. Document every failure with the page URL, element description, and reproduction steps.
-
Screen reader passes. Run NVDA (Windows) and VoiceOver (macOS/iOS) through your key flows. Listen for: meaningful link and button text, correct heading hierarchy, form label announcements, error message association, and image alt text. Record reproduction steps for every failure.
-
Code inspection and ARIA review. Inspect custom widgets (modals, accordions, carousels, date pickers) against WAI-ARIA Authoring Practices. Check for correct roles, states, and properties. Validate HTML to catch structural errors that break AT parsing.
-
Assemble the audit report. Every defensible audit report should include:
- Executive summary (scope, methodology, overall conformance posture)
- Per-issue table: WCAG criterion, severity (critical/serious/moderate/minor), affected page, reproduction steps, screenshot or code snippet, recommended fix
- Prioritized remediation roadmap with sprint-friendly phasing
- Retest plan
-
Post-fix verification and CI integration. After developers implement fixes, retest every issue in the original environment. Add axe-core or pa11y to your CI/CD pipeline so regressions get caught at the PR stage, not in production.
Pro Tip: When running screen reader tests, resist the urge to look at the screen. Close your eyes and navigate by audio alone for at least one full user flow. You’ll catch announcement failures you’d never notice visually.
Common accessibility failures your audit will find
These are the issues that show up in almost every audit. Know them before you start, and you’ll triage faster.
- Missing or inadequate alt text: Images with no alt attribute, or alt text that says “image001.jpg.” Screen reader users get nothing useful. Fix: write descriptive alt text that conveys the image’s purpose; use
alt=""for purely decorative images. - Low color contrast: Text that fails the 4.5:1 ratio for normal text or 3:1 for large text (WCAG 1.4.3). Affects users with low vision and anyone in bright sunlight. Check your typographic and color choices against a contrast analyzer.
- Unlabeled form inputs: Inputs with placeholder text but no
<label>element. Placeholders disappear on focus and aren’t reliably announced by screen readers. - Missing document language: No
langattribute on the<html>element. Screen readers default to the wrong language, mangling pronunciation. - Empty links and buttons:
<a href="#">with no text, or<button>containing only an icon with no accessible name. Users hear “link” or “button” with no context. - Inaccessible custom widgets: Carousels, modals, and dropdowns built without ARIA roles or keyboard support. These are often the most complex fixes. See accessible component patterns for reference implementations.
- Keyboard traps: Focus enters a modal or widget and can’t escape without a mouse. A critical failure under WCAG 2.1.2.
- Broken heading structure: Headings that skip levels (H1 → H3) or are used for visual styling rather than document structure. Screen reader users navigate by headings; a broken hierarchy is disorienting.
Include a screenshot or code snippet for each issue in your report. Developers fix things faster when they can see exactly what’s broken.
How to prioritize and track remediation
Raw audit output is just a list of problems. A remediation plan turns it into something your team can actually ship.
-
Score every issue using a simple priority matrix: severity (critical = 4, serious = 3, moderate = 2, minor = 1) multiplied by frequency (how many pages it appears on) multiplied by user impact (how many users are affected and how severely). Sort descending.
-
Phase your fixes into sprint-friendly chunks:
- First two weeks: All critical issues (keyboard traps, missing form labels, empty buttons). These block users entirely and carry the highest legal risk.
- Sprints 2–4: Serious issues (contrast failures, missing alt text at scale, heading structure).
- Subsequent releases: Moderate and minor issues, plus any AAA enhancements you’re targeting.
-
Estimate developer hours by issue type. Simple fixes (adding an alt attribute, adding a
langattribute) run 15–30 minutes each. Complex widget refactors can take 4–16 hours. A full audit for a mid-size site typically surfaces 40–100 issues; budget accordingly. -
Add regression guards. Once fixes are merged, add axe-core rules to your CI pipeline targeting the specific criteria you just fixed. A failing CI check on a PR is infinitely cheaper than re-auditing after a regression.
| Fix Category | Typical Dev Time | Priority |
|---|---|---|
| Missing alt text (static images) | 15–30 min each | High |
| Form label association | 30 min per form | Critical |
| Color contrast updates | 1–4 hrs (design + dev) | High |
| Custom widget ARIA refactor | 4–16 hrs per widget | Critical |
| Heading structure cleanup | 1–3 hrs per template | Moderate |
Which tools should you use for accessibility testing?
The W3C/WAI tools list catalogs over 100 accessibility evaluation tools. You don’t need all of them. Here’s the practical shortlist:
Automated scanners:
- axe DevTools (Deque Systems): The most widely used browser extension for manual-triggered scans. Zero false positives by design. The free version covers most WCAG 2.2 AA criteria; the Pro version adds guided testing workflows. Integrates as axe-core in CI pipelines.
- Google Lighthouse: Built into Chrome DevTools. Runs an accessibility audit alongside performance checks. Great for quick baseline checks; less granular than axe for detailed issue documentation.
- WAVE (WebAIM): Visual overlay tool that highlights errors, alerts, and structural elements directly on the page. Browser extensions for Chrome, Firefox, and Edge. The AIM enterprise report adds human-reviewed results and an end-user impact score, which helps prioritize by actual user harm rather than just technical violation count.
Assistive technology for testing:
- NVDA (Windows): Free, open-source screen reader. The most common screen reader in WebAIM’s annual survey. Pair with Chrome or Firefox.
- VoiceOver (macOS/iOS): Built into Apple devices. Essential for testing Safari-specific behavior and mobile accessibility.
- JAWS: The dominant enterprise screen reader. Worth testing against for B2B or enterprise-facing applications where your users are more likely to be running it.
References and CI tools:
- WAI tools list for comparing scanner capabilities before building a CI pipeline
- axe-core (npm package) for automated checks in Jest, Playwright, or Cypress test suites
- pa11y for command-line and CI-friendly page scanning
Pro Tip: Run axe DevTools and WAVE on the same page and compare results. They use different detection logic, so they’ll catch slightly different issues. The overlap gives you high-confidence findings; the differences reveal edge cases worth investigating manually.
How to maintain accessibility after remediation
Fixing issues once is the easy part. Keeping them fixed is the actual challenge.
Continuous monitoring strategy:
- Run automated scans (axe-core or pa11y) on every deploy as part of your CI/CD pipeline. A failing accessibility check should block a merge the same way a failing unit test does.
- Schedule periodic manual spot checks (monthly for high-risk sites, quarterly for standard commercial sites) on your highest-traffic templates.
- Monitor your error logs and user feedback channels for accessibility-related complaints.
Governance and roles:
- Assign an accessibility owner (a developer, designer, or product manager) who is responsible for the audit cadence, CI rules, and vendor vetting. Without a named owner, accessibility work drifts.
- Integrate accessibility review into your PR checklist and design review process. Catching a missing label in Figma takes five minutes; fixing it after launch takes five hours.
- Train developers on the top 10 WCAG failures your audit found. Targeted training beats generic “accessibility awareness” sessions every time.
Publish and maintain an accessibility statement. An accessibility statement documents your conformance target (WCAG 2.2 Level AA), known limitations, the date of your last audit, and a contact method for users to report barriers. Update it after every audit cycle. It signals good faith to users and regulators alike, and it’s a standard deliverable in any accessibility-focused UX practice.
How Coumba Win Design runs an accessibility audit
Coumba Win Design’s audit process is built around one principle: every finding has to be actionable. No vague “consider improving contrast” notes. Every issue in the deliverable includes the WCAG criterion, severity, the exact page and element, reproduction steps, a screenshot or code snippet, and a recommended fix with implementation guidance.
Standard deliverables for every audit engagement:
- Executive summary with overall conformance posture and top-priority findings
- Per-issue spreadsheet with WCAG 2.2 mapping, severity, affected pages, and recommended fixes
- Prioritized remediation roadmap phased into sprint-ready chunks
- Sample code snippets for the most common fix patterns
- Retest plan specifying which issues to verify and how
Scoping approach: For sites with fewer than 50 unique templates, Coumba Win Design audits a representative sample covering the homepage, 3–5 high-traffic templates, all interactive components, and every user flow that involves a form or transaction. Larger sites get a stratified sample plus full automated coverage.
What clients typically see: After a Coumba Win Design audit, development teams report faster remediation velocity because the issue documentation is specific enough to hand directly to a developer without a follow-up call. The retest plan also means clients aren’t left guessing whether their fixes actually worked.
The most expensive accessibility audit is the one that produces a PDF nobody reads. A good audit produces a spreadsheet your developers open on Monday morning and a roadmap your product manager can slot into the next sprint. That’s the only deliverable that actually moves the needle.
Why accessibility is central to good design
Accessibility isn’t a compliance checkbox bolted onto the end of a project. It’s a design constraint that makes everything better, the same way a word count makes writing sharper.
The sites that score highest on accessibility audits tend to be the same sites that score highest on usability testing with non-disabled users. Clear heading structure, labeled form inputs, sufficient contrast, and keyboard-friendly navigation are just good UX. The WCAG criteria aren’t arbitrary; they’re distilled from decades of research into how people actually use the web.
The ethical argument is real, but the business argument is just as strong. Excluding users with disabilities isn’t just a legal risk; it’s leaving revenue on the table and signaling to a significant portion of your audience that your product wasn’t built with them in mind. That’s a brand problem, not just a compliance problem. Accessibility done right shows up in website structure, in SEO, and in conversion rates, not just in audit scores.
Ready to get your site audited? Here’s what working with Coumba Win Design looks like
Coumba Win Design’s accessibility audit service gives startup founders and development teams a clear, developer-ready remediation plan without the vague consulting-speak. The engagement starts with a scoping call (usually 30 minutes) where you walk through your site’s templates, tech stack, and compliance goals. From there, you get a sample deliverable within the first week so you know exactly what you’re getting before the full audit is complete.
Typical timelines run one to two weeks for a standard commercial site audit, with the full deliverable including the prioritized remediation roadmap, code snippets, and retest plan. After your team ships fixes, Coumba Win Design runs a retest pass to verify remediation and update your accessibility statement. CI integration guidance is included so regressions don’t undo the work.
If you want a design partner who treats accessibility as a feature, not an afterthought, Coumbawin and request your audit scoping call today.
Sources
Official references worth bookmarking:
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
FAQ
What is a website accessibility audit?
A website accessibility audit is a structured evaluation of a site against WCAG success criteria to identify barriers that prevent people with disabilities from using the content, producing a prioritized list of issues with recommended fixes.
How much does a website accessibility audit cost?
Cost varies by site size and audit depth. Automated-only scans can run a few hundred dollars, while manual audits for mid-size commercial sites depend on scope, template count, and whether retesting is included.
What are the four principles of web accessibility?
The four principles are Perceivable, Operable, Understandable, and Robust (POUR). Every WCAG success criterion maps to one of these, and a complete audit traces each failure back to the principle it violates.
Can automated tools alone pass an accessibility audit?
No. Automated tools catch roughly 30–40% of real WCAG failures; the rest require manual keyboard testing, screen reader passes, and human judgment on content quality and semantic structure.
What WCAG level should US websites target?
WCAG 2.2 Level AA is the practical standard for ADA defensibility and most US procurement requirements. Level A is the bare minimum; Level AAA is rarely required across an entire site.
