How to Conduct an ADA Website Accessibility Audit: Complete Guide for 2026
8,667 federal ADA website lawsuits were filed in 2024 — a 7% increase over the previous year. With the April 2026 Title II deadline approaching and AI-powered filings accelerating, conducting a proper accessibility audit isn't optional anymore. It's the single most important thing you can do to protect your business and serve all your users. Here's exactly how to do it — step by step.
1. What Is an ADA Website Accessibility Audit?
An ADA website accessibility audit is a systematic evaluation of your website against established accessibility standards — primarily the Web Content Accessibility Guidelines (WCAG) — to identify barriers that prevent people with disabilities from using your site effectively.
While the ADA itself doesn't specify technical standards for websites (the DOJ has explicitly stated WCAG is not the ADA standard), WCAG 2.1 Level AA has become the de facto benchmark used in virtually every ADA settlement agreement, DOJ consent decree, and the 2024 Title II rule for government entities.
A thorough accessibility audit evaluates four dimensions of your website, corresponding to WCAG's four principles (known as POUR):
- Perceivable — Can all users perceive the content? This covers text alternatives for images, captions for video, sufficient color contrast, and content that doesn't rely solely on color to convey meaning.
- Operable — Can users navigate and interact with everything using a keyboard, voice control, or other assistive technologies? No keyboard traps, adequate time limits, and no content that triggers seizures.
- Understandable — Is the content readable and the interface predictable? Clear language, consistent navigation, helpful error messages, and labels on form inputs.
- Robust — Does the content work reliably across different browsers, devices, and assistive technologies? Proper HTML semantics, valid ARIA attributes, and compatible with screen readers.
An audit produces a detailed report documenting every accessibility barrier found, its severity, the relevant WCAG success criterion it violates, and specific remediation guidance. This report becomes your roadmap for making your site accessible — and your evidence of good-faith compliance efforts if you ever face legal action.
2. Why Your Business Needs an Accessibility Audit in 2026
The case for auditing your website has never been stronger. Three forces are converging in 2026:
The Legal Landscape Is Intensifying
- • 8,667 federal ADA website lawsuits were filed in 2024 — up from 8,116 in 2023
- • The April 2026 Title II deadline requires state and local government sites to conform to WCAG 2.1 AA
- • The European Accessibility Act (EAA) took effect in June 2025, impacting US businesses selling to EU customers
- • AI-powered pro se filings are making it cheaper and faster to file lawsuits without an attorney
- • The FTC's $1 million fine against accessiBe confirmed that overlay widgets are not a valid compliance strategy
The Business Case Is Compelling
- • Over 1 billion people worldwide have some form of disability — that's 16% of the global population
- • The annual spending power of Americans with disabilities exceeds $490 billion in discretionary income
- • Accessible websites consistently show improved SEO performance because the same practices (semantic HTML, alt text, heading structure, readable content) that help disabled users also help search engines
- • 71% of users with disabilities will leave a website that isn't accessible — and they rarely come back
Prevention Is Vastly Cheaper Than Litigation
- • Average ADA lawsuit settlement: $5,000–$25,000 (and up to $150,000+ for larger companies)
- • Legal defense costs: $10,000–$50,000+ even if you win
- • Emergency remediation under legal pressure: $15,000–$75,000 (rush pricing, external consultants)
- • Proactive accessibility audit + remediation: $1,500–$10,000 (your choice of timeline and vendors)
The math is simple. An audit that costs $3,000 today can prevent a lawsuit that costs $30,000+ tomorrow. And unlike a lawsuit settlement, a proper audit actually makes your website better for everyone.
3. Types of Accessibility Audits: Automated vs. Manual vs. Hybrid
Not all audits are created equal. Understanding the three approaches — and their limitations — is critical for choosing the right one for your situation.
Automated Scanning
Automated tools crawl your website and test each page against a set of programmatically checkable WCAG rules. Tools like axe-core, WAVE, and Lighthouse can scan hundreds of pages in minutes.
✅ Strengths
- • Fast — scans thousands of pages in minutes
- • Consistent — same rules applied every time
- • Affordable — free to low cost
- • Great for catching code-level issues
- • Easy to integrate into CI/CD pipelines
❌ Limitations
- • Only catches 30–40% of WCAG issues
- • Cannot evaluate subjective criteria
- • Misses keyboard traps and navigation issues
- • Can't judge if alt text is meaningful
- • May produce false positives/negatives
Best for: Initial baseline assessment, continuous monitoring, catching regressions between manual audits. Start your audit journey with a free AI-powered accessibility scan to understand where you stand.
Manual Expert Audit
A trained accessibility expert navigates your website using keyboards, screen readers (JAWS, NVDA, VoiceOver), and other assistive technologies. They evaluate each page against all WCAG success criteria, including subjective ones that automated tools cannot assess.
✅ Strengths
- • Catches 80–95% of accessibility issues
- • Evaluates real user experience
- • Tests actual assistive technology compat
- • Assesses subjective criteria (meaningful alt text, logical reading order)
- • Provides context-specific remediation advice
❌ Limitations
- • Expensive ($5,000–$25,000+)
- • Time-consuming (2–6 weeks)
- • Point-in-time snapshot only
- • Quality varies by auditor
- • Doesn't scale to every page
Best for: Annual comprehensive reviews, pre-launch assessments, VPAT/ACR documentation, responding to legal demands, government Title II compliance.
Hybrid Approach (Recommended)
The most effective audit strategy combines automated scanning for breadth with manual testing for depth. This is what most accessibility professionals recommend, and it's the approach that provides the best balance of coverage, cost, and ongoing protection.
🎯 Recommended Hybrid Strategy
- 1. Run automated scans across your entire site to create a baseline (tools like RatedWithAI, axe-core, or WAVE)
- 2. Manually audit every unique page template against full WCAG 2.1 AA criteria
- 3. Test critical user journeys with keyboard and screen reader
- 4. Set up continuous automated monitoring to catch regressions
- 5. Re-audit manually annually or after major redesigns
4. Before You Start: Scoping Your Audit
A well-scoped audit saves time and money. Before touching any testing tools, answer these questions:
Define Your Scope
- Which standard? WCAG 2.1 Level AA is the minimum for most businesses. If you operate in the EU, also consider EN 301 549 (which maps to WCAG 2.1 AA + additional requirements). If your site is a government entity, WCAG 2.1 AA is mandated by the 2024 Title II rule.
- Which pages? Identify all unique page templates. A typical business site has 5–15 templates. An ecommerce site might have 8–12 (homepage, category, product, cart, checkout, account, search, blog listing, blog post, about, contact, FAQ). You'll manually audit each template and use automated scanning for the rest.
- Which user journeys? Map the critical paths users take through your site. At minimum: finding a product → adding to cart → checkout → confirmation. Also: registration → login → account management. And: finding information → filling out a contact form.
- Which browsers and devices? Test on at least: Chrome (desktop), Safari (desktop and iOS), Firefox (desktop), and Chrome on Android. These cover the vast majority of assistive technology combinations.
- Which assistive technologies? At minimum: NVDA on Windows (free, most popular screen reader), VoiceOver on macOS/iOS (built-in), and keyboard-only navigation across all browsers.
Gather Your Documentation
- • Sitemap: XML sitemap or site architecture document
- • Design system/style guide: Color palette, typography, component library
- • Previous audit reports: If any exist
- • Known issues: Any complaints from users, customer service tickets, or legal correspondence about accessibility
- • Content inventory: List of PDFs, videos, and other non-HTML content
- • Third-party integrations: Chat widgets, payment forms, embedded maps, social media feeds — these are often the most problematic for accessibility
⚠️ Don't Forget Third-Party Content
Under the ADA, you're responsible for the accessibility of your entire website — including third-party widgets, embedded content, and payment processors. If your Stripe checkout form, HubSpot chat widget, or Google Maps embed isn't accessible, that's your liability. Audit these integrations specifically.
5. Step 1: Run an Automated Accessibility Scan
Start with automated scanning to establish your baseline and identify the low-hanging fruit. This gives you quick wins while you plan deeper manual testing.
Recommended Tools
- RatedWithAI — AI-powered accessibility scanner that provides instant scoring, WCAG violation details, and plain-language remediation guidance. Best for getting a quick, comprehensive baseline score.
- axe DevTools (by Deque) — Industry-standard accessibility engine used by Microsoft, Google, and government agencies. Available as a browser extension and CI/CD integration. Excellent for developers.
- WAVE (by WebAIM) — Visual accessibility evaluator that highlights issues directly on the page. Intuitive for non-technical stakeholders. Free for individual pages.
- Lighthouse (built into Chrome) — Free, always available, but limited scope. Good for a quick sanity check, not sufficient as your only tool.
- Pa11y — Open-source command-line tool, ideal for integrating into automated testing pipelines.
What to Document From Automated Scans
For each issue found, record:
- • WCAG Success Criterion: e.g., 1.1.1 Non-text Content, 1.4.3 Contrast
- • Severity: Critical / Major / Minor
- • Location: Exact URL, element selector, and line of code
- • Description: What the issue is and why it matters to users
- • Remediation: Specific fix instructions
- • Screenshot/evidence: Visual documentation of the issue
💡 Pro Tip: Run Multiple Tools
Different automated tools catch different issues. Research by the GDS (UK Government Digital Service) found that the top 5 automated tools combined catch significantly more issues than any single tool alone. Run at least 2–3 tools against your key pages. Deduplicate the results and you'll have a much more complete picture.
6. Step 2: Keyboard Navigation Testing
Keyboard testing is the single most important manual test you can perform. Approximately 7% of working-age adults have a severe dexterity disability, and many more use keyboards due to repetitive strain injuries, temporary disabilities, or personal preference. If your site doesn't work with just a keyboard, it likely fails for screen reader users, switch users, and voice control users too.
How to Test
Put your mouse aside. Seriously — unplug it or move it out of reach. Then navigate through every page and user journey using only these keys:
- Tab — Move forward through interactive elements (links, buttons, form fields)
- Shift + Tab — Move backward
- Enter — Activate links and buttons
- Space — Activate buttons, toggle checkboxes, open select menus
- Arrow keys — Navigate within radio groups, select options, tab panels, menus
- Escape — Close modals, dropdowns, and overlays
What to Check
- Focus visibility: Can you always see where the keyboard focus is? There should be a clear visual indicator (outline, highlight, underline) on every focused element. If you lose track of where you are, that's a WCAG 2.4.7 failure.
- Tab order: Does focus move in a logical sequence? Generally left-to-right, top-to-bottom, matching the visual layout. Skip navigation links should appear first.
- No keyboard traps: Can you Tab through every element and eventually reach the end of the page? If focus gets stuck anywhere — a custom widget, an embedded video, a modal that won't close — that's a Critical WCAG 2.1.2 failure and a top priority to fix.
- All functionality available: Can you complete every action? Add to cart, submit forms, use navigation menus, play/pause videos, close popups, expand accordions, use sliders and date pickers. If any feature requires a mouse, that's a WCAG 2.1.1 failure.
- Skip navigation: Is there a "Skip to main content" link that appears when you first Tab onto the page? Without it, keyboard users must Tab through every navigation link on every single page (WCAG 2.4.1).
- Modal management: When a modal opens, does focus move into it? Can you Tab through all elements within the modal? When it closes, does focus return to the triggering element? Can you close it with Escape?
🚨 Most Common Keyboard Failures
- • Custom dropdown menus that only respond to mouse hover
- • Modals without Escape key dismissal or focus trapping
- • Hamburger menus that can't be opened/closed via keyboard
- • Carousels/sliders without keyboard arrow key support
- • "Click to reveal" content that uses onClick without onKeyDown
- • Cookie consent banners that trap focus or can't be dismissed
- • Third-party chat widgets that intercept keyboard shortcuts
7. Step 3: Screen Reader Testing
Screen reader testing reveals how your website sounds to the 7.6 million Americans with significant vision loss. If keyboard testing checks that your site is operable, screen reader testing checks that it's perceivable and understandable without visual cues.
Which Screen Readers to Test
- NVDA + Firefox (Windows) — Free, open-source, used by 40%+ of screen reader users. This is your primary testing combination. Download from nvaccess.org.
- VoiceOver + Safari (macOS/iOS) — Built into every Apple device. Press Cmd+F5 to enable on Mac, or triple- click the side button on iPhone. Essential for mobile accessibility testing.
- JAWS + Chrome or Edge (Windows) — The most popular commercial screen reader (40%+ market share). Costs $1,000+/year, but offers a free 40-minute demo mode. Used heavily in enterprise and government.
- TalkBack + Chrome (Android) — Built into Android devices. Important if your audience includes Android users. Activate in Settings → Accessibility.
What to Evaluate
- Image alt text: Navigate to every image. Is the alt text read aloud? Does it meaningfully describe the image? Decorative images should have empty alt text (alt="") so they're skipped. Charts and infographics need detailed descriptions.
- Heading structure: Use the screen reader's heading navigation (H key in NVDA) to jump through headings. Is there a logical hierarchy? H1 → H2 → H3? No skipped levels? Screen reader users rely on headings as their primary navigation mechanism — 67.5% of screen reader users navigate by headings (WebAIM survey).
- Link text: Use the screen reader's links list to see all links on the page read out of context. Do they make sense? "Click here," "Read more," and "Learn more" are meaningless without visual context. Links should describe their destination: "Download the 2026 WCAG Audit Template" not "Click here."
- Form labels: Tab to each form field. Does the screen reader announce what the field is for? "First name, edit text" is correct. "Edit text" with no label is a failure. Check that error messages are announced when forms fail validation.
- Landmarks and regions: Use landmark navigation (D key in NVDA) to jump between page regions. Is there a <nav>, <main>, <header>, <footer>, and appropriate <section> elements? ARIA landmarks (role="navigation", etc.) should supplement, not replace, semantic HTML.
- Dynamic content: Do alerts, status messages, form errors, and live updates get announced? ARIA live regions (aria-live="polite" or "assertive") should be used for content that changes without page reload.
- Tables: Are data tables properly marked up with <th> elements and scope attributes? Can the screen reader navigate cell-by-cell and announce row/column headers?
🎯 Screen Reader Testing Shortcut
If you're new to screen readers, start with VoiceOver on macOS (it's already installed) and practice on a site you know well — like Wikipedia — for 15 minutes before testing your own site. The learning curve is steep at first but the insight is invaluable. Even 30 minutes of screen reader testing will reveal issues you never knew existed.
8. Step 4: Visual and Cognitive Accessibility Review
Accessibility isn't just about screen readers. Millions of people have low vision, color blindness, dyslexia, ADHD, cognitive disabilities, or anxiety disorders that affect how they process web content. This step catches issues that neither automated tools nor screen reader testing will find.
Color Contrast
- • Normal text (under 18pt/14pt bold): Minimum 4.5:1 contrast ratio against background (WCAG 1.4.3)
- • Large text (18pt+ or 14pt+ bold): Minimum 3:1 contrast ratio (WCAG 1.4.3)
- • UI components (borders, icons, focus indicators): Minimum 3:1 contrast ratio (WCAG 1.4.11) — this is a WCAG 2.1 addition that many sites miss
- • Test with tools like the Colour Contrast Analyser (CCA) or the contrast checker built into Chrome DevTools
- • Don't forget to check contrast on hover/focus states, placeholder text, disabled elements, and text over images
Color Independence
- • Information must not be conveyed by color alone (WCAG 1.4.1). Check: Do error states use only red text? Add an icon or text label too.
- • Are required form fields indicated only with a red asterisk? Add "(required)" text too.
- • Do charts and graphs rely solely on color to distinguish data series? Add patterns or labels.
- • Test with a color blindness simulator (Chrome extension: "Colorblindly" or "NoCoffee") to see your site as 8% of men with color vision deficiency see it.
Text and Readability
- • Can users resize text up to 200% without loss of content or functionality? (WCAG 1.4.4) — test by zooming to 200% in the browser
- • Does the content reflow properly at 320px viewport width without horizontal scrolling? (WCAG 1.4.10)
- • Is line height at least 1.5× the font size? Paragraph spacing at least 2× the font size? (WCAG 1.4.12)
- • Can users override text styles without breaking the layout?
Cognitive Load
- • Are instructions clear without relying on spatial cues ("click the button on the right") or sensory characteristics alone? (WCAG 1.3.3)
- • Does the site have a consistent navigation pattern across pages? (WCAG 3.2.3)
- • Are error messages specific and helpful? "Please enter a valid email address" vs. "Invalid input." (WCAG 3.3.1, 3.3.3)
- • Is there a timeout? If so, can users extend it? Are they warned before it expires? (WCAG 2.2.1)
- • No auto-playing content that lasts more than 5 seconds without a way to pause, stop, or hide it (WCAG 1.4.2, 2.2.2)
Animation and Motion
- • Does the site respect prefers-reduced-motion? (WCAG 2.3.3) — check in browser developer tools by toggling the media query
- • No content that flashes more than 3 times per second (WCAG 2.3.1 — a seizure safety requirement)
- • Parallax scrolling, animated backgrounds, and auto-playing carousels should have pause controls
9. Step 5: Forms, Interactive Elements, and Dynamic Content
Forms are where accessibility failures most directly cost you customers. A user who can't complete checkout can't buy. A user who can't fill out a contact form can't become a lead. And a user who can't register can't become a subscriber.
Form Accessibility Checklist
- Every input has a visible label — Placeholder text is NOT a label (it disappears when typing). Use <label> elements properly associated via the "for"/"id" attribute pair. (WCAG 1.3.1, 4.1.2)
- Required fields are identified — Both visually and programmatically (aria-required="true" or the HTML "required" attribute). Don't rely on red asterisks alone.
- Error messages are specific and adjacent — "Please enter a valid US zip code (e.g., 90210)" not "Invalid input." Errors should appear near the field and be announced by screen readers. Use aria-describedby to associate errors with inputs.
- Error prevention for important actions — Financial transactions, legal commitments, and data deletion should be reversible, verified, or confirmed (WCAG 3.3.4). Show a summary before final submission.
- Logical grouping — Use <fieldset> and <legend> to group related fields (like a set of radio buttons for shipping method). Screen readers announce the legend for context.
- Autocomplete attributes — Use the HTML autocomplete attribute on personal data fields (autocomplete="name", "email", "tel", etc.) so browsers and password managers can help fill them. (WCAG 1.3.5)
Custom Interactive Widgets
Custom widgets (date pickers, autocomplete fields, accordions, tabs, carousels, modals, mega menus) are the #1 source of accessibility failures in modern websites. For each custom widget, verify:
- • Does it have the correct ARIA role? (role="dialog", "tablist", "menu", etc.)
- • Does it have the correct ARIA states? (aria-expanded, aria-selected, aria-checked, etc.)
- • Does it follow the WAI-ARIA Authoring Practices Guide (APG) keyboard interaction pattern for that widget type?
- • Is the screen reader announcement sensible at each interaction point?
Dynamic Content Updates
- • Shopping cart updates: When a user adds an item, is the updated count announced? Use aria-live="polite".
- • Search-as-you-type: Are results announced as they appear? Too many announcements can overwhelm — debounce to announce result count after typing stops.
- • Infinite scroll: Keyboard users must be able to reach the footer. Provide a "Load more" button as an alternative.
- • Toast notifications: Important status messages (success, error) need role="alert" or aria-live="assertive". Non-critical messages use aria-live="polite".
- • Single Page App (SPA) navigation: When the route changes, announce the new page title and move focus to the main content area.
10. Step 6: Multimedia and Document Accessibility
Video Content
- • Captions: All pre-recorded video with audio must have synchronized captions (WCAG 1.2.2). Auto-generated captions (YouTube, etc.) are a starting point but must be reviewed for accuracy — auto-captions average 60–80% accuracy, which isn't sufficient for compliance.
- • Audio descriptions: Videos where important visual information isn't described in the audio track need audio descriptions or an accessible alternative (WCAG 1.2.3, 1.2.5). Think: product demos, tutorials, charts shown on screen.
- • Transcripts: Provide a full text transcript for audio-only content (podcasts, audio recordings) and as a supplement to video (WCAG 1.2.1).
- • Player controls: Is the video player keyboard-accessible? Can you play, pause, adjust volume, and toggle captions with a keyboard?
- • No autoplay with sound: If video autoplays, it must be muted or have an immediately accessible way to stop/mute (WCAG 1.4.2).
PDF and Document Accessibility
PDFs are often the worst accessibility offenders on otherwise accessible websites — and they're specifically called out in ADA settlements. Ohio State University recently spent $20 million on PDF remediation alone.
- • All PDFs should be tagged (not scanned images of text)
- • Reading order must be defined and logical
- • Images in PDFs need alt text
- • Tables must have proper header cells
- • The document language must be specified
- • Consider converting frequently accessed PDFs to accessible HTML pages instead
💡 PDF Audit Tool
Use Adobe Acrobat Pro's built-in accessibility checker (Full Check) or the free PAVE tool for basic PDF accessibility validation. For government entities, Section 508 compliance specifically requires PDF/UA conformance.
11. Step 7: Mobile and Responsive Accessibility
Over 60% of web traffic is mobile. Mobile accessibility testing should cover both responsive design and native mobile assistive technology.
Touch Target Size
- • Interactive elements (buttons, links, form inputs) should have a minimum target size of 24×24 CSS pixels (WCAG 2.5.8, new in WCAG 2.2) with adequate spacing between targets
- • Recommended: 44×44 CSS pixels for comfortable touch interaction (WCAG 2.5.5 AAA / Apple HIG / Material Design)
- • Navigation links stacked vertically with only 8px spacing are nearly impossible for users with motor disabilities
Orientation and Viewport
- • Content must work in both portrait and landscape orientation (WCAG 1.3.4) — some users mount devices in fixed orientations
- • Don't disable pinch-to-zoom (maximum-scale=1 in viewport meta tag) — low-vision users rely on zoom (WCAG 1.4.4)
- • Content should reflow at 320px width without horizontal scrolling (WCAG 1.4.10)
Mobile Screen Reader Testing
- • iOS: Enable VoiceOver (Settings → Accessibility → VoiceOver). Navigate your site using swipe gestures. Single-swipe moves to next element, double-tap activates.
- • Android: Enable TalkBack (Settings → Accessibility → TalkBack). Similar swipe-based navigation.
- • Pay special attention to navigation menus, hamburger toggles, and modal interactions on mobile — these frequently fail
- • Test gesture-based interactions (swipe carousels, drag-to- dismiss) — all gesture functions must have a non-gesture alternative (WCAG 2.5.1)
12. Creating Your Remediation Roadmap
After completing your audit, you'll have a list of issues. Now you need to prioritize them into an actionable plan. Not all accessibility issues are equally urgent — use this framework to prioritize:
Priority Framework
🔴 Critical (Fix within 1–2 weeks)
- • Keyboard traps (user literally cannot proceed)
- • Missing form labels on checkout/registration (blocks conversions)
- • Auto-playing audio/video with no controls (seizure risk, immediate barriers)
- • Content that flashes (seizure danger — potential physical harm)
- • Login/authentication that's completely inaccessible
- • Missing language attribute on <html> element
🟠 High (Fix within 1–3 months)
- • Color contrast failures on primary content and CTAs
- • Missing or inadequate alt text on content images
- • Broken heading hierarchy across templates
- • No skip navigation link
- • Video without captions
- • Focus not visible or managed on interactive components
🟡 Medium (Fix within 3–6 months)
- • Redundant or non-descriptive link text
- • Missing ARIA landmarks and roles
- • Insufficient touch target sizes
- • Missing autocomplete attributes on forms
- • Reflow issues at 320px width
- • PDF accessibility issues
🟢 Low (Ongoing improvement)
- • Decorative images that could use empty alt
- • Minor text spacing issues
- • Orientation locking on non-essential pages
- • Status messages not announced to screen readers
- • AAA-level enhancements (aspirational)
Documentation Best Practices
Your audit report and remediation plan are legal documents. Treat them that way:
- • Date everything — when the audit was conducted, when each issue was identified, when each fix was deployed
- • Keep before/after evidence — screenshots, code samples, scan results showing the issue before and after remediation
- • Track your progress — a spreadsheet or project management board showing issue status (Open → In Progress → Resolved → Verified)
- • Create an Accessibility Conformance Report (ACR/VPAT) if you serve enterprise or government customers — they'll request it during procurement
- • Publish an accessibility statement on your website declaring your commitment, the standard you're targeting, known limitations, and a contact method for reporting issues
13. Accessibility Audit Costs: What to Budget
Audit costs vary dramatically based on scope, methodology, and who performs them. Here's what to expect in 2026:
💰 Automated Scanning Only
- • Cost: Free – $500/month
- • Coverage: ~30–40% of WCAG issues
- • Timeline: Minutes to hours
- • Best for: Initial baseline, ongoing monitoring, small businesses
- • Examples: RatedWithAI (free scan), WAVE (free), Lighthouse (free), axe DevTools ($50–$250/month)
💰💰 Hybrid Audit (Automated + Limited Manual)
- • Cost: $1,500 – $5,000
- • Coverage: ~50–70% of WCAG issues
- • Timeline: 1–2 weeks
- • Best for: Small-to-mid businesses, compliance baseline, litigation response
- • Includes: Automated scan of full site + manual review of 5–10 key page templates + keyboard testing + basic screen reader check
💰💰💰 Comprehensive Expert Audit
- • Cost: $5,000 – $25,000+
- • Coverage: ~80–95% of WCAG issues
- • Timeline: 2–6 weeks
- • Best for: Enterprise, government (Title II), high-litigation-risk industries, VPAT documentation
- • Includes: Full manual audit of all templates + complete assistive technology testing (JAWS, NVDA, VoiceOver) + user journey walkthroughs + detailed remediation report + VPAT/ACR documentation
💰💰💰💰 Enterprise Full-Service
- • Cost: $25,000 – $100,000+
- • Coverage: 95%+ including user testing with disabled users
- • Timeline: 4–12 weeks
- • Best for: Large enterprises, government agencies, organizations under DOJ investigation
- • Includes: Everything above + user testing with people with disabilities + code-level remediation support + ongoing monitoring + staff training + policy development
💡 Smart Budget Strategy
Start with a free automated scan at RatedWithAI.com to understand your current score and biggest issues. Fix the automated findings yourself (many are simple HTML fixes). Then invest in a hybrid or comprehensive audit for the issues that require expert evaluation. This two-step approach typically reduces the manual audit cost by 30–50% because the easy issues are already resolved. Small businesses can claim up to $5,000 in federal tax credits for accessibility improvements.
14. Beyond the Audit: Ongoing Monitoring
An accessibility audit is a snapshot. Websites change constantly — new content, design updates, plugin updates, third-party widget changes — and each change can introduce new barriers. The businesses that stay protected are those that build accessibility into their ongoing workflow.
Build an Accessibility Program
- Continuous automated monitoring: Run automated scans weekly or on every deployment. Tools like RatedWithAI can alert you when new accessibility issues are introduced before they reach users.
- Accessibility in your design system: Bake accessibility into your component library. Every button, form field, modal, and navigation pattern should be accessible by default. If accessibility is a feature of your design system, developers can't accidentally break it.
- Developer training: The cheapest accessibility fix is the one that never needs to be made. Train your development team on WCAG basics, semantic HTML, keyboard testing, and ARIA usage. Even a 2-hour workshop dramatically reduces the rate of new accessibility issues.
- QA integration: Add accessibility checks to your QA process. Keyboard testing and a quick automated scan should be part of every feature review.
- User feedback channel: Publish a way for users to report accessibility issues (an email address, a contact form, or a feedback button). Some of your best bug reports will come from actual users with disabilities.
- Annual re-audit: Even with continuous monitoring, conduct a manual expert audit at least annually to catch the issues automated tools miss.
✅ The Monitoring Stack That Protects You
- 1. AI-powered scanning — Instant baseline and continuous monitoring with RatedWithAI
- 2. CI/CD integration — Catch issues in development with axe-core or pa11y in your build pipeline
- 3. Manual spot-checks — Monthly keyboard and screen reader testing of new features
- 4. Annual expert review — Comprehensive manual audit by certified professionals
- 5. User feedback — Real accessibility reports from your actual users
This is why one-time fixes aren't enough. Approximately 46% of ADA website lawsuit defendants face repeat litigation. The organizations that avoid repeat lawsuits are those with ongoing monitoring and maintenance programs — exactly what an accessibility tool like RatedWithAI is designed to provide.
15. Frequently Asked Questions
How much does an ADA website accessibility audit cost?
Costs range from free (automated scans) to $25,000+ (comprehensive expert audits). Automated-only scans are free to $500/month. Hybrid audits cost $1,500–$5,000. Comprehensive expert audits with assistive technology testing range from $5,000–$25,000+ depending on site complexity. Budget approximately $100–$250 per unique page template for manual testing. Start with a free AI-powered scan to understand your baseline.
How often should I audit my website for ADA compliance?
Run automated scans monthly (or on every deployment) and conduct a comprehensive manual audit at least annually. Also audit after any major redesign, CMS update, or new feature launch. High-risk industries (ecommerce, hospitality, food service) should consider weekly automated monitoring.
Can automated tools catch all accessibility issues?
No. Automated tools catch approximately 30–40% of WCAG violations. They excel at detecting code-level issues (missing alt text, contrast failures, missing form labels) but cannot evaluate subjective criteria like whether alt text is meaningful, content is logically organized, or custom widgets are properly keyboard-operable. A thorough audit requires both automated scanning and manual expert review.
What WCAG level should my audit target?
Target WCAG 2.1 Level AA. This is the standard in the DOJ's 2024 Title II rule for government websites and the de facto standard used in ADA Title III settlement agreements. The European Accessibility Act also maps to this level. Level A alone is insufficient for legal protection, while Level AAA is generally aspirational.
Do I need to audit every page on my website?
Not manually, but every page should be covered. Manually audit each unique page template (typically 5–15 templates for most sites), then use automated scanning to catch page-specific issues across all pages. Always manually audit: homepage, login/registration, checkout/payment, contact forms, and pages with interactive widgets.
What's the difference between an accessibility audit and a scan?
A scan is automated, takes minutes, and catches ~30–40% of issues. An audit is comprehensive — automated scanning plus manual expert testing, keyboard navigation assessment, screen reader testing, and cognitive accessibility review — catching 80–95% of issues. Think of a scan as a quick health check and an audit as a thorough physical exam.
Should I hire a consultant or audit in-house?
It depends on your team's expertise and risk profile. In-house audits work if you have WCAG-trained developers. For businesses facing litigation risk, government entities with Title II deadlines, or organizations needing VPAT documentation, professional audits by IAAP-certified experts provide greater legal defensibility. A common approach: use AI-powered monitoring tools continuously while engaging experts for annual reviews.
What happens after the audit identifies issues?
Create a remediation roadmap prioritized by severity. Critical issues (keyboard traps, missing form labels, seizure-risk content) — fix in 1–2 weeks. High-impact issues (contrast, alt text, headings) — fix in 1–3 months. Medium/low issues — schedule into regular sprints. Document everything: your audit report, remediation plan, and fix dates demonstrate good-faith compliance efforts in legal proceedings.
Start Your Accessibility Audit Today — Free
The best time to audit your website was before you got a demand letter. The second best time is right now. RatedWithAI provides an instant, AI-powered accessibility scan that scores your site against WCAG 2.1 AA standards and shows you exactly what to fix — in plain language, with specific remediation guidance for each issue.
- ✅ Instant accessibility score with letter grade
- ✅ Detailed WCAG violation breakdown by category and severity
- ✅ Plain-language remediation guidance for every issue
- ✅ PDF report for your records — evidence of good-faith compliance effort
- ✅ No credit card required — scan your site in 60 seconds
Related Resources
Best Accessibility Testing Tools Compared (2026)
In-depth comparison of 12 accessibility testing tools for developers and QA teams
How to Respond to an ADA Demand Letter
Step-by-step response guide if you've already received legal notice
VPAT Guide: How to Create an ACR
Create an Accessibility Conformance Report for enterprise and government procurement
ADA Compliance Checklist 2026
Quick-reference checklist for all major ADA website compliance requirements
WCAG 2.2 Complete Guide
Everything you need to know about the latest WCAG standard
Why One ADA Settlement Isn't Enough
46% of defendants face repeat lawsuits — ongoing monitoring is the defense