ADA website compliance means building and maintaining your site so people with disabilities can perceive, understand, navigate, and interact with it. Under ADA Title III (and Title II for government entities), websites are considered extensions of places of public accommodation. The accepted technical standard is WCAG 2.2 Level AA, published by the W3C. There is no single "ADA certified" badge -- compliance is an ongoing practice, not a one-time purchase.

We have remediated dozens of sites across healthcare, e-commerce, and SaaS. This article is the order of operations we actually follow, written for teams who need to get it right without burning months or buying snake oil.

  • Do accessibility overlays make you ADA compliant?
  • How do you test for WCAG 2.2 AA conformance?
  • How much does ADA compliance cost?
  • FAQ

    • What does ADA compliance mean for websites?

    ADA compliance for a website means the site does not discriminate against people with disabilities in how they access goods, services, or information. The Americans with Disabilities Act (1990) does not mention websites by name, but the Department of Justice has consistently held -- and courts have agreed -- that Title III covers web content offered by public accommodations.

    The DOJ's guidance page at ada.gov/resources/web-guidance states: "the ADA's requirements apply to all the goods, services, privileges, or activities offered by public accommodations, including those offered on the web."

    In practice, "ADA compliant" is shorthand for conforming to the Web Content Accessibility Guidelines (WCAG) at Level AA. WCAG is not a law -- it's a technical standard. But it's the standard referenced in virtually every ADA consent decree, DOJ settlement, and the 2024 final rule under Title II (28 CFR Part 35) that explicitly adopts WCAG 2.1 Level AA for state and local governments.

    What laws and standards apply?

    Three legal frameworks matter for most U.S. organizations:

    Framework Applies to Technical standard referenced Key detail
    ADA Title III Private businesses ("places of public accommodation") WCAG 2.1/2.2 AA (via case law and settlements) No explicit regulation yet, but DOJ position is clear
    ADA Title II State and local governments WCAG 2.1 AA (2024 final rule, compliance deadlines 2026-2028 based on population) First explicit WCAG mandate in regulation
    Section 508 Federal agencies and their contractors WCAG 2.0 AA (via the 2017 refresh of Section 508) Applies to internal and public-facing federal tech

    The 2024 Title II rule (published March 2024, effective April 2024) set concrete deadlines: state and local governments with populations of 50,000+ must comply by April 24, 2026. Smaller entities get until April 26, 2027. This is the first time WCAG has been codified in an ADA regulation.

    For private businesses under Title III, there's still no parallel regulation with a specific technical standard. But every major court case and settlement we've seen -- and the DOJ's own web guidance page -- points to WCAG AA as the benchmark.

    What is the right order of operations for remediation?

    The W3C's WCAG 2.2 Quick Reference lists 86 success criteria across three levels. Trying to tackle all of them at once is how you waste three months and ship nothing. Here's the sequence we follow, prioritized by impact and dependency.

    1. Semantic HTML structure

    Semantic HTML is the foundation. Every other accessibility fix -- screen reader compatibility, keyboard navigation, ARIA roles -- depends on your markup being correct first.

    What to do:

    Use one <h1> per page. Headings must follow a logical descending order: <h1>, <h2>, <h3>, and so on. Never skip levels (jumping from <h1> to <h4>) or use headings for visual styling. The moment you use an <h3> because you like the font size, you've broken the document outline for every screen reader user.

    Use <nav>, <main>, <header>, <footer>, <aside>, and <section> to define page landmarks. Screen readers like NVDA 2024.4 and JAWS 2025 expose these as a navigable list.

    Use <button> for actions and <a> for navigation. A <div> with an onclick handler is not a button -- it has no keyboard semantics, no role, and no accessible name unless you manually add them all.

    Use <ul>, <ol>, and <dl> for lists. Tables should use <th> with scope attributes for data tables.

    WCAG 2.2 success criteria addressed: 1.3.1 Info and Relationships (Level A), 2.4.1 Bypass Blocks (Level A), 2.4.6 Headings and Labels (Level AA), 2.4.10 Section Headings (Level AAA, but good practice).

    2. Alt text for images

    Every <img> element needs an alt attribute. The question is what goes in it.

    Rules we follow:

    Informative images: Describe the content and function in 125 characters or less. "A bar chart showing Q3 revenue of $4.2M, up 12% from Q2" is good. "Chart" is not.

    Decorative images: Use alt="" (empty string). This tells screen readers to skip the image entirely. Do not omit the alt attribute -- that causes screen readers to read the file name instead.

    Linked images: The alt text should describe the link destination, not the image. A logo linking to the homepage should have alt="CompanyName homepage".

    Complex images (charts, infographics): Provide a long description in surrounding text or via aria-describedby pointing to a visually hidden element.

    WCAG 2.2 success criteria addressed: 1.1.1 Non-text Content (Level A).

    3. Color contrast

    Insufficient contrast is the single most common WCAG failure we find in audits. The WebAIM Million study (2024) found contrast issues on 81% of home pages they tested.

    WCAG 2.2 AA minimums:

    Text type Minimum contrast ratio
    Normal text (under 18pt / 14pt bold) 4.5:1
    Large text (18pt+ / 14pt+ bold) 3:1
    UI components and graphical objects 3:1

    How to check:

    Chrome DevTools: Inspect an element, click the color swatch in the Styles panel. It shows the contrast ratio and whether it passes AA/AAA.

    Standalone tools: Colour Contrast Analyser (TPGi, free), Stark (Figma plugin, $40/year for pro).

    Bulk check: axe DevTools (Deque, free browser extension) flags all contrast failures on a page.

    Do not rely on color alone to convey information. A form field that turns red on error needs a text label like "This field is required" too. That's WCAG 1.4.1 (Use of Color).

    WCAG 2.2 success criteria addressed: 1.4.3 Contrast (Minimum) (Level AA), 1.4.1 Use of Color (Level A), 1.4.11 Non-text Contrast (Level AA).

    4. Keyboard operability

    Every interactive element on your site must be operable with a keyboard alone -- no mouse required. This matters for users of screen readers, switch devices, voice control, and anyone with a motor impairment.

    The checklist:

    Tab through every page. Can you reach every link, button, form field, and interactive widget?

    Can you activate buttons and links with Enter or Space?

    Can you dismiss modals, dropdowns, and menus with Escape?

    Is there a visible focus indicator on every interactive element? (More on this below.)

    Are there any keyboard traps -- places where tabbing cycles endlessly inside a component with no way out?

    The DOJ's web guidance at ada.gov specifically calls out keyboard navigation: "Keyboard access means users with disabilities can navigate web content using keystrokes, rather than a mouse."

    WCAG 2.2 success criteria addressed: 2.1.1 Keyboard (Level A), 2.1.2 No Keyboard Trap (Level A), 2.1.4 Character Key Shortcuts (Level A).

    5. Focus management

    Focus management is where most JavaScript-heavy sites fall apart. WCAG 2.2 introduced a new success criterion -- 2.4.11 Focus Not Obscured (Minimum) at Level AA -- which requires that when an element receives focus, it's not entirely hidden by sticky headers, footers, or other overlapping content.

    What to do:

    Visible focus indicators: The default browser outline works, but many CSS resets remove it (outline: none). If you do that, you must replace it with a custom focus style that meets the 3:1 contrast requirement from WCAG 2.4.7 (Focus Visible, Level AA). We use a 2px solid outline offset by 2px in a high-contrast color.

    Focus order: The tab order must follow the visual reading order (left-to-right, top-to-bottom in LTR languages). Do not use tabindex values greater than 0 -- they create unpredictable tab orders. Use tabindex="0" to add elements to the natural flow and tabindex="-1" to allow programmatic focus without tab access.

    Focus on dynamic content: When a modal opens, focus should move to the first focusable element inside it. When it closes, focus should return to the trigger element. Same logic applies for accordion panels, tab interfaces, and single-page-app route changes.

    WCAG 2.2 success criteria addressed: 2.4.3 Focus Order (Level A), 2.4.7 Focus Visible (Level AA), 2.4.11 Focus Not Obscured (Minimum) (Level AA), 2.4.12 Focus Not Obscured (Enhanced) (Level AAA).

    6. Forms and labels

    Forms are where accessibility failures cause real harm -- a user who cannot complete a sign-up form, a checkout, or a government application is locked out of your service.

    Requirements:

    Every <input>, <select>, and <textarea> needs a programmatically associated <label>. Use the for attribute matching the input's id. Placeholder text is not a label -- it disappears on input and isn't consistently announced by all screen readers.

    Group related fields with <fieldset> and <legend>. Radio button groups and checkbox groups are the most common use case.

    Error messages must be specific ("Email address is missing the @ symbol" not "Invalid input"), programmatically associated with the field (via aria-describedby or aria-errormessage), and announced to screen readers (use aria-live="assertive" or role="alert" on the error container).

    Required fields should be indicated with aria-required="true" or the HTML required attribute, plus a visual indicator.

    WCAG 2.2 success criteria addressed: 1.3.1 Info and Relationships (Level A), 3.3.1 Error Identification (Level A), 3.3.2 Labels or Instructions (Level A), 3.3.3 Error Suggestion (Level AA), 4.1.2 Name, Role, Value (Level A).

    7. ARIA -- only where needed

    The first rule of ARIA (from the W3C's own "Using ARIA" document): "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."

    ARIA is a repair tool. It fixes the accessibility tree when native HTML cannot express the widget you're building. If you're reaching for ARIA on a standard form, navigation, or content page, something has gone wrong upstream.

    When ARIA is needed:

    Custom widgets with no native HTML equivalent: tab panels (role="tablist", role="tab", role="tabpanel"), tree views, comboboxes with autocomplete.

    Live regions: aria-live="polite" for non-urgent updates (chat messages, stock tickers), aria-live="assertive" for errors.

    Labeling relationships that HTML cannot express: aria-labelledby to compose a label from multiple elements, aria-describedby for supplementary instructions.

    State communication: aria-expanded on disclosure triggers, aria-selected on tabs, aria-current="page" on the active nav link.

    Common ARIA mistakes we see:

    Adding role="button" to a <div> instead of just using <button>. The <div> still needs tabindex="0" and keyboard event handlers. The <button> gets all of that for free.

    Using aria-label to override visible text. Screen reader users hear one thing; sighted users see another. This creates a disconnect that violates WCAG 2.5.3 Label in Name (Level A).

    Applying aria-hidden="true" to content that's visible. This removes it from the accessibility tree while leaving it on screen.

    WCAG 2.2 success criteria addressed: 4.1.2 Name, Role, Value (Level A), 1.3.1 Info and Relationships (Level A), 2.5.3 Label in Name (Level A).

    Do accessibility overlays make you ADA compliant?

    No. Accessibility overlays -- JavaScript widgets that bolt onto your site and claim to fix accessibility automatically -- do not make your site ADA compliant. They increase legal risk.

    The Overlay Fact Sheet (overlayfactsheet.com), signed by over 700 accessibility practitioners, advocates, and organizations, documents the problems. Overlays cannot fix issues baked into your source code: missing form labels, broken heading hierarchies, inaccessible custom widgets, missing alt text on CMS-uploaded images. At best, they apply surface-level CSS adjustments (font size, contrast themes). At worst, they introduce new accessibility barriers -- multiple overlay vendors have been shown to break screen reader navigation or trap keyboard focus.

    Automated testing can catch roughly 30-40% of WCAG issues, according to research by GDS (UK Government Digital Service) and Deque. The rest require human judgment: Is this alt text meaningful? Does the tab order make logical sense? Is this error message specific enough?

    From a legal standpoint, companies using overlays have not been shielded from lawsuits. Plaintiff firms have specifically targeted sites running overlay products because the presence of the widget makes it easy to identify sites that likely have underlying accessibility issues.

    Our recommendation: spend the overlay subscription budget ($250-$500/month is typical for mid-market products) on actual remediation.

    How do you test for WCAG 2.2 AA conformance?

    Testing requires both automated and manual methods. Neither alone is sufficient.

    Automated testing tools:

    Tool Type Cost What it catches
    axe DevTools (Deque) Browser extension Free (core), $40/month (pro) Missing alt text, contrast failures, missing labels, ARIA misuse
    Lighthouse (Google) Built into Chrome DevTools Free Subset of axe rules, performance overlap
    WAVE (WebAIM) Browser extension + web service Free Visual overlay showing errors in context
    pa11y CLI / CI integration Free (open source) Batch testing across URLs, good for build pipelines
    IBM Equal Access Checker Browser extension Free Rules aligned to IBM's accessibility requirements

    Manual testing protocol:

    Keyboard-only navigation: Unplug the mouse (or disable the trackpad). Tab through every page. Can you complete every task?

    Screen reader testing: Test with NVDA (free, Windows) and VoiceOver (built into macOS/iOS). JAWS (Freedom Scientific, ~$1,000/license) is the third option if budget allows. Listen to how your page is announced -- headings, landmarks, form labels, dynamic content updates.

    Zoom testing: Zoom to 200% and 400% in the browser. Does content reflow without horizontal scrolling? Do interactive elements remain usable? This covers WCAG 1.4.4 (Resize Text) and 1.4.10 (Reflow).

    Reduced motion: Enable "prefers-reduced-motion" in your OS settings. Do animations stop or reduce? (WCAG 2.3.3 Animation from Interactions, Level AAA, but good practice.)

    The W3C WAI's WCAG 2.2 Quick Reference is your primary reference during testing. It lets you filter criteria by level (A, AA, AAA), topic, and technology, and includes "sufficient techniques" and "advisory techniques" for each criterion. We keep it open during every audit.

    How much does ADA compliance cost?

    It depends on the size and complexity of your site:

    Scope Typical cost Timeline
    Small marketing site (10-30 pages, CMS-based) $3,000 - $8,000 for audit + remediation 2-4 weeks
    Mid-size site (50-200 pages, custom components) $10,000 - $30,000 4-8 weeks
    Large application (SaaS, e-commerce, 100+ templates) $30,000 - $80,000+ 2-6 months
    Ongoing monitoring and maintenance $500 - $2,000/month Continuous

    These numbers include a proper audit (automated + manual), remediation of code, and a retest cycle. They do not include legal fees if you're already facing a demand letter -- that's separate.

    The cost of not doing it is harder to pin down. ADA demand letter settlements typically range from $5,000 to $25,000 for small businesses, but federal lawsuits can go much higher. Beyond dollars, there's the reputational cost and -- most importantly -- the real people you're excluding from your product or service.

    If you need help with an audit or remediation, our web accessibility and WCAG compliance team handles this end to end.

    FAQ

    Is ADA compliance legally required for my website?

    For businesses open to the public (Title III) and government entities (Title II), yes. Courts and the DOJ have consistently held that websites are covered. There's no explicit private-sector regulation yet, but the legal risk is real and documented through hundreds of filed lawsuits annually.

    What level of WCAG should I target?

    Level AA of WCAG 2.2 is the standard. It's what the DOJ references in settlements and what the 2024 Title II rule codifies for government sites. Level A alone is insufficient for most real-world accessibility. Level AAA is aspirational and not always achievable for all content types.

    Can I get sued even if I use an accessibility overlay?

    Yes. Overlays do not provide legal protection. The Overlay Fact Sheet, endorsed by hundreds of accessibility professionals, documents cases where overlay users were still sued. Overlays cannot fix structural code issues and sometimes introduce new barriers for assistive technology users.

    How often should I test my website for accessibility?

    Test after every significant design or content change. At minimum, run a quarterly automated scan and an annual manual audit. If you ship code weekly, integrate automated checks (axe-core or pa11y) into your CI/CD pipeline so issues are caught before deployment.

    Does WCAG 2.2 apply to mobile apps?

    WCAG 2.2 is technology-agnostic -- it applies to any web-based content, including responsive sites on mobile. Native mobile apps fall under the same ADA requirements, and the 2024 Title II rule explicitly includes mobile applications for government entities.

    What is the difference between Section 508 and ADA compliance?

    Section 508 applies specifically to U.S. federal agencies and their technology vendors. The ADA applies to private businesses (Title III) and state/local governments (Title II). Both point to WCAG as the technical standard, but Section 508 currently references WCAG 2.0 AA while ADA practice has moved toward 2.1 and 2.2 AA.

    Do PDFs on my website need to be accessible?

    Yes. PDFs are web content. They need proper heading structure, reading order, alt text for images, and tagged elements. The 2024 Title II rule includes specific exceptions for some pre-existing government documents, but as a general rule, if a PDF is publicly available, it should be accessible.