ADA Title II Deadline: April 24, 2026

State and local government websites must comply with WCAG 2.1 AA. An accessibility audit is the first step — start before it's too late.

How to Conduct a
Website Accessibility Audit

A complete, step-by-step guide to auditing your website for WCAG 2.1 AA compliance and ADA requirements — from automated scanning to manual testing with screen readers.

Start your free accessibility audit — results in ~30 seconds:

In this guide
  1. 1. What Is a Website Accessibility Audit?
  2. 2. Why Conduct an Accessibility Audit in 2026?
  3. 3. Step 1 — Run Automated Scanning
  4. 4. Step 2 — Keyboard Navigation Testing
  5. 5. Step 3 — Screen Reader Testing
  6. 6. Step 4 — Visual and Cognitive Checks
  7. 7. Step 5 — Fix Issues and Re-audit
  8. 8. Most Common Accessibility Issues
  9. 9. Ongoing Monitoring After the Audit
  10. 10. Frequently Asked Questions

1. What Is a Website Accessibility Audit?

A website accessibility audit is a comprehensive review of your website to identify barriers that prevent people with disabilities — including visual, auditory, motor, and cognitive disabilities — from accessing your content and functionality.

Accessibility audits evaluate compliance against WCAG 2.1 or 2.2 (Web Content Accessibility Guidelines), the international standard published by the W3C. In the United States, WCAG 2.1 Level AA is the legally required standard under ADA Title II (government sites) and the de facto standard for ADA Title III (private business sites).

Unlike a one-time speed test or SEO check, a complete accessibility audit combines automated scanning (which catches ~30–40% of issues instantly) with manual testing (keyboard navigation, screen readers, and visual inspection) to identify the full range of barriers.

2. Why Conduct an Accessibility Audit in 2026?

Legal Compliance

The DOJ's ADA Title II final rule requires state and local government sites to meet WCAG 2.1 AA by April 24, 2026. Non-compliance triggers DOJ investigations, consent decrees, and substantial penalties up to $75,000 per violation.

Lawsuit Risk

ADA web accessibility lawsuits increased 37% in 2025. Courts increasingly find that private business websites are "places of public accommodation" under ADA Title III. Domino's, Nike, and Beyoncé.com have all faced high-profile ADA web cases.

Market Reach

1 in 4 American adults has a disability. Globally, 1 billion people have a disability with $8 trillion in combined purchasing power. Accessible sites reach a wider audience and retain customers who would otherwise leave.

SEO Benefits

Many accessibility improvements directly benefit SEO: descriptive alt text helps Google understand images, proper heading structure helps crawlers parse content, and fast-loading accessible pages have lower bounce rates — all positive ranking signals.

3. Step 1 — Run Automated Scanning

Automated tools are the fastest way to find accessibility issues. They check hundreds of WCAG criteria in seconds and give you a prioritized list of problems to fix. Always start here.

What automated tools check (30–40% of WCAG 2.1 AA):
  • Missing or empty alt attributes on images
  • Color contrast ratios below 4.5:1 (normal text) or 3:1 (large text)
  • Form fields missing <label> elements
  • Missing or non-descriptive page <title> elements
  • Missing lang attribute on <html> element
  • Invalid ARIA roles and attributes
  • Duplicate id attributes
  • Buttons and links without accessible names
  • Heading hierarchy issues (skipping from H1 to H3)
  • Missing skip navigation links
PageGuard Free

Scans any public URL in ~30 seconds. Returns a 0–100 Accessibility score, specific WCAG violation list, and AI-powered fix recommendations. Also covers SEO and performance in the same scan.

axe DevTools Browser Extension Free

Runs axe-core accessibility engine directly in Chrome or Firefox DevTools. Good for testing pages that require login or that aren't publicly accessible. Run on each page template individually.

WAVE Web Accessibility Evaluation Tool Free

Browser extension from WebAIM that overlays visual indicators directly on the page. Excellent for identifying structural issues (landmark regions, heading order, form labels) at a glance.

Key limitation: Automated tools cannot detect issues that require human judgment — like whether alt text is actually descriptive, whether the reading order is logical, or whether interactive components are usable via keyboard.

4. Step 2 — Keyboard Navigation Testing

Many users with motor disabilities navigate entirely by keyboard — no mouse, no touch screen. Keyboard accessibility is one of the most commonly failed WCAG criteria and one of the easiest to test manually.

Keyboard Testing Protocol
  1. 1
    Disconnect your mouse (or disable it in system preferences). Navigate using only Tab, Shift+Tab, Enter, Space, and arrow keys.
  2. 2
    Check for visible focus indicators. Every focused element (links, buttons, inputs) must have a visible outline or highlight. If you can't see where focus is, that's a WCAG 2.4.7 violation.
  3. 3
    Tab through every interactive element. Buttons, links, form fields, dropdowns, modals, and date pickers all need to be reachable and operable via keyboard.
  4. 4
    Test for keyboard traps. Try pressing Escape to close modals and dialogs. You should never get "stuck" in a component with no way to exit via keyboard (WCAG 2.1.2).
  5. 5
    Check focus order. The logical reading order should match the Tab order. A focus that jumps from the header to the footer and back is disorienting for keyboard users.
  6. 6
    Verify skip navigation links. A "Skip to main content" link should be the first focusable element on every page. It's invisible until focused (that's intentional).
WCAG Criterion Level What to Check
2.1.1 Keyboard A All functionality operable without a mouse
2.1.2 No Keyboard Trap A Can always Tab or Escape out of a component
2.4.3 Focus Order A Focus order preserves meaning and operability
2.4.7 Focus Visible AA Visible focus indicator on keyboard-focused elements
2.4.11 Focus Not Obscured AA Focused component not fully hidden by sticky headers (WCAG 2.2 new)

5. Step 3 — Screen Reader Testing

Screen readers are software that converts page content to speech or Braille output. Approximately 7.3 million Americans use screen readers. Screen reader testing is the only way to verify how your site is actually experienced by blind users — automated tools can't do this.

NVDA (Windows) Free

NonVisual Desktop Access — the most widely used free screen reader. Use with Firefox or Chrome. Download from nvaccess.org.

Common shortcuts: Insert+F7 (elements list), Insert+Space (toggle browse mode)
VoiceOver (Mac/iOS) Built-in

Apple's built-in screen reader. Enable with Cmd+F5 on Mac. On iOS, triple-click the side button. Use with Safari for best compatibility.

Common shortcuts: VO+A (read from beginning), VO+U (rotor menu)
What to Test with a Screen Reader
  • Image descriptions: Listen to how images are announced. Alt text should describe the image's purpose, not just say "image" or match the filename.
  • Form interactions: Tab to each form field. The screen reader should announce the label, input type, and any error messages. "Edit text" alone is useless — it needs a label like "Email address, Edit text."
  • Landmark regions: Use the screen reader's rotor or element list to navigate landmarks (header, main, nav, footer). Every page needs a <main> landmark.
  • Dynamic content: After submitting a form or loading new content via JavaScript, the screen reader should announce the result. Check that ARIA live regions (aria-live="polite") work correctly.
  • Modal dialogs: When a modal opens, focus should move to it. When it closes, focus should return to the triggering button. The modal should have an accessible name via aria-labelledby.
  • Tables: Data tables need <th> elements with proper scope attributes. Screen readers should announce "Column: Name, Row: Value" for each cell.

6. Step 4 — Visual and Cognitive Checks

Visual and cognitive accessibility goes beyond screen readers. Many users have low vision, color blindness, or cognitive disabilities that require different accommodations.

Color Contrast Testing

WCAG 2.1 AA requires a 4.5:1 contrast ratio for normal text (under 18pt) and 3:1 for large text (18pt+ or 14pt+ bold). Automated tools catch many contrast issues, but check decorative text, disabled states, and placeholder text manually.

Tools: Colour Contrast Analyser (TPGi, free), browser DevTools color picker, WebAIM Contrast Checker

200% Text Zoom Test

Users with low vision often zoom their browser to 200% or more. Zoom in on your site (Ctrl/Cmd + "+") to 200% and verify: no content is cut off, no horizontal scrollbar appears in a 1280px viewport, and all functionality remains accessible.

WCAG criterion: 1.4.4 Resize Text (AA) — Text can be resized to 200% without loss of content or functionality

Color Blind Simulation

8% of men have some form of color blindness. Never use color alone to convey information (e.g., "required fields are in red"). Use icons, patterns, or labels in addition to color.

Tools: Chrome DevTools rendering tab (Emulate vision deficiencies), Colour Contrast Analyser, Sim Daltonism (Mac)

Animation and Motion

Animations and auto-playing content can trigger seizures (photosensitivity) or vestibular disorders. Check: does any content flash more than 3 times per second? Is there a way to pause or disable animations? Does your site respect the prefers-reduced-motion media query?

WCAG criterion: 2.3.1 Three Flashes or Below Threshold (A); 2.2.2 Pause, Stop, Hide (A)

Reading Level and Clarity

WCAG 3.1.5 (AAA) recommends content at an 8th-grade reading level or below when possible, and providing summaries for complex content. Even at AA level, clear language is a best practice that improves usability for everyone, especially users with cognitive disabilities.

7. Step 5 — Fix Issues and Re-audit

After your audit, prioritize fixes by severity and impact. Use this framework:

Priority Issue Type Fix Timeline Examples
Critical Completely blocks access for disabled users Immediately Keyboard traps, no page title, form fields with no label
High Significantly impairs access 1–2 weeks Missing alt text, low contrast, missing focus indicators
Medium Creates friction but doesn't completely block 1 month Heading order issues, link text "click here", missing landmarks
Low Minor improvements for better experience Ongoing Enhanced ARIA descriptions, improved error messages

After fixing each batch of issues, re-run your automated scan to confirm the fixes resolved the detected issues and didn't introduce new ones. Some fixes — like adding aria-hidden to decorative elements — can inadvertently cause other issues if applied incorrectly.

8. Most Common Website Accessibility Issues

Based on the WebAIM Million report (which audits the top 1 million websites annually), these are the most frequent WCAG failures found on websites:

01
Low Color Contrast Text

Found on 81% of home pages. Light gray text on white backgrounds is the most common culprit. Fix: use a contrast checker and adjust foreground/background colors to meet 4.5:1 ratio.

02
Missing Alternative Text for Images

Found on 55% of home pages. Add descriptive alt attributes to all meaningful images. Decorative images should have alt="" (empty string) to be ignored by screen readers.

03
Empty Links and Buttons

Found on 50% of home pages. Icon-only buttons (hamburger menus, social media icons, close buttons) with no text or aria-label are invisible to screen readers. Add aria-label="Close menu" to icon-only interactive elements.

04
Missing Form Input Labels

Found on 48% of home pages. Placeholder text is not an accessible label — it disappears when you type and isn't read by all screen readers. Use visible <label> elements associated with each input via the for attribute.

05
Missing Document Language

Found on 18% of home pages. The <html lang="en"> attribute tells screen readers which language to use for pronunciation. Without it, screen readers may mispronounce words or switch to an incorrect language.

9. Ongoing Monitoring After the Audit

An accessibility audit is not a one-time event. Every time you publish new content, update a plugin, or change a template, you risk introducing new accessibility issues. Organizations that achieve and maintain accessibility set up ongoing monitoring to catch regressions automatically.

Accessibility Monitoring Checklist
  • Automated weekly or daily scans on your most important pages
  • Email alerts when your accessibility score drops below a threshold
  • Score history to correlate drops with specific deployments
  • Manual re-audit after any major redesign or CMS upgrade
  • Include accessibility testing in your deployment checklist
  • Train content editors on accessible content practices (alt text, heading structure, link text)
PageGuard automates the monitoring layer

Add your site to PageGuard's dashboard and get automated accessibility scans with email alerts when scores drop. Catch regressions within hours instead of months. Free for 1 site.

Start monitoring free ›

Run Your Free Accessibility Audit Now

No signup required for the first scan. WCAG 2.1 AA check, accessibility score, and prioritized issue list — in ~30 seconds.

Frequently Asked Questions

What is a website accessibility audit?

A website accessibility audit is a systematic evaluation that identifies barriers preventing people with disabilities from using your site. It tests against WCAG 2.1 standards using automated scanning tools and manual testing (keyboard navigation, screen reader testing, visual checks) to find accessibility violations.

How long does an accessibility audit take?

An automated scan takes 30–60 seconds and finds roughly 30–40% of issues. A manual expert audit of a 20-page website takes 2–5 days. For most businesses, start with automated scanning, fix those issues first, then consider a targeted manual audit for your most critical user flows (checkout, contact forms, login).

What percentage of issues can automated tools detect?

Automated tools reliably detect 30–40% of WCAG 2.1 AA violations — the structured, rule-based issues like missing alt text, contrast failures, and invalid ARIA. The remaining 60–70% require human judgment: whether alt text is meaningful, whether keyboard interactions are intuitive, and whether dynamic content announcements are clear.

How much does an accessibility audit cost?

Automated auditing is free with PageGuard. A professional manual accessibility audit from a certified expert costs $3,000–$30,000 depending on site complexity. Ongoing monitoring with PageGuard starts at $9/month for automated weekly scans and email alerts.

Do I need an accessibility audit if I'm not a government website?

Yes. While ADA Title II's April 2026 deadline applies to government sites, ADA Title III covers private businesses with places of public accommodation — and courts increasingly treat websites as such. Over 4,600 ADA web lawsuits were filed in 2023. Any business website, e-commerce store, or SaaS product can be targeted. Accessibility auditing is no longer optional for serious businesses.

Related Tools & Guides