ADA Website Compliance Guide: WCAG, Accessibility Testing, and What Actually Applies

The direct answer: ADA website compliance is not one magic checklist for every organization. Website accessibility means people with disabilities can perceive, understand, navigate, and complete the same meaningful tasks as everyone else. For most modern sites, WCAG 2.2 Level AA is a responsible technical target. The legal standard that actually applies depends on who you are, what you offer, where you operate, and whether a law, regulation, contract, or procurement rule names a specific requirement. Start by removing real barriers. Do not start by buying a widget and declaring victory.

That distinction matters because accessibility advice on the internet tends to arrive in one of two costumes: a blood-pressure-raising lawsuit pitch or a 97-point checklist with no connection to what people are trying to do. Neither is a strategy.

An accessible website lets a person read the offer, understand the choices, use the navigation, complete the form, play the media, recover from an error, and get the result using the tools and interaction methods they need. That may include a keyboard, screen reader, voice input, switch device, captions, magnification, increased text spacing, reduced motion, or simply a tired brain on a terrible Wi-Fi connection.

This guide explains what WCAG does, how the major U.S. accessibility frameworks differ, what a useful website accessibility test includes, how to prioritize repairs, and why the little accessibility icon floating in the corner is not a civil-rights force field.

This is practical website guidance, not legal advice. A qualified attorney should evaluate obligations for your specific organization, location, customers, contracts, and risk.

Website accessibility is access to the outcome

Accessibility is often reduced to individual ingredients: alt text, contrast, keyboard focus, labels, captions. Those ingredients matter, but the business and human question is larger:

Can a person get the intended outcome without being blocked, misled, trapped, or forced to ask someone else for help?

If a visitor can read a product description but cannot select an option, the page is not functionally accessible. If a job applicant can open the form but the date picker cannot be operated by keyboard, the process is not accessible. If a customer can reach checkout but the error message is communicated only by turning a border red, the system has failed at exactly the moment the person needs help.

This is why accessibility belongs inside user experience. Our UX diagnosis guide treats access as a condition across the whole decision path—not a cleanup task after the visual design has been approved.

The Scope Design version is blunt: user needs overrule taste when comprehension, access, or completion is at stake. Your art director may adore pale gray type. The person trying to read it still wins.

What WCAG 2.2 actually is

The Web Content Accessibility Guidelines 2.2 are a technical standard developed through the World Wide Web Consortium. WCAG covers a wide range of barriers affecting people with visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.

WCAG is organized around four principles, usually shortened to POUR:

• Perceivable: People can access the information through available senses or alternatives. Examples include text alternatives for meaningful images, captions for prerecorded video, and sufficient contrast.
• Operable: People can operate controls and navigation with the interaction methods they use. Keyboard access, visible focus, adequate target sizes, and alternatives to dragging live here.
• Understandable: Content and interactions make sense. Labels are clear, navigation is consistent, errors are identified, and help appears where people expect it.
• Robust: Browsers, assistive technologies, and other user agents can reliably interpret the content. Semantic HTML, correct names and roles, and accurate component states matter here.

The standard has three conformance levels:

• Level A addresses foundational barriers.
• Level AA adds requirements commonly used as the practical target in laws, policies, and contracts.
• Level AAA contains additional criteria, but WCAG does not expect every page or site to satisfy all AAA criteria.

Conformance is not achieved by collecting a certain number of points. A page must satisfy every applicable success criterion at the claimed level. A glowing score of 97 is not “basically compliant” if the remaining failure prevents somebody from paying, applying, booking, or reading the answer.

Why target WCAG 2.2 when some rules name WCAG 2.1?

WCAG 2.2 extends WCAG 2.1. W3C advises using 2.2 to maximize the future applicability of accessibility work, and content conforming to WCAG 2.2 also conforms to 2.1 and 2.0. The newer version adds criteria covering issues such as obscured keyboard focus, alternatives to dragging, minimum target size, consistent help, redundant entry, and accessible authentication. W3C summarizes the changes in its What’s New in WCAG 2.2 guide.

That makes WCAG 2.2 AA a sensible engineering and design target for a new or substantially rebuilt site. It does not mean every law automatically names WCAG 2.2. Legal requirements, contractual targets, and a responsible modern build can overlap without being identical.

ADA website compliance: which rules actually apply?

There is no honest universal answer to “Does my website have to be ADA compliant?” without knowing what kind of organization operates it. The better starting point is to identify the applicable framework before pretending one acronym answers everything.

ADA Title II: state and local government websites

The U.S. Department of Justice issued a specific rule for web content and mobile apps provided by state and local governments. The rule uses WCAG 2.1 Level A and AA as its technical standard for covered content and apps.

The dates deserve special attention because they changed. In April 2026, DOJ extended the compliance deadlines. According to the department’s current Title II web-rule fact sheet:

• State and local governments with a population of 50,000 or more have until April 26, 2027.
• State and local governments with fewer than 50,000 people, plus special district governments, have until April 26, 2028.

The rule covers content and apps a public entity provides directly or through contractual, licensing, or other arrangements. Hiring a vendor does not cause the obligation to evaporate into the procurement portal.

The rule also contains specific exceptions and legal concepts that need careful application. A summary article is not a substitute for reading the rule or obtaining counsel.

ADA Title III: private businesses open to the public

DOJ’s Guidance on Web Accessibility and the ADA says Title III applies to businesses open to the public and that inaccessible website features can limit access to the goods, services, and privileges those businesses offer online. The department says businesses must provide full and equal enjoyment and effective communication where required.

The same guidance also says DOJ does not have a detailed regulation that supplies one technical web checklist for Title III. It points to WCAG and the Section 508 Standards as helpful technical guidance while explaining that businesses have flexibility in how they meet the ADA’s general requirements.

The practical conclusion is not “private websites can ignore accessibility.” It is also not “WCAG 2.2 AA is the exact federal regulation for every private website.” The responsible conclusion is that businesses open to the public should make their online goods and services accessible, use a recognized technical standard to organize the work, and get legal advice when they need a determination about their own obligations.

Section 508 is not shorthand for every website

Section 508 covers information and communication technology developed, procured, maintained, or used by federal agencies. The U.S. Access Board’s Section 508 overview includes websites, software, documents, kiosks, and other ICT in that federal context.

A private contractor may encounter Section 508 through federal work or procurement. A local restaurant does not become a federal agency because somebody installed an accessibility scanner.

The European Accessibility Act has a defined scope

The European Accessibility Act applies to specified products and services sold in the EU, including areas such as e-commerce, consumer banking, payment services, passenger transport information, and electronic communications. The European Commission’s accessibility overview explains that covered products and services have been subject to common requirements since June 2025.

It is not a single sentence that makes every website everywhere subject to the same rule. Scope, exemptions, member-state implementation, and the nature of the product or service matter.

The Scope Design Accessibility Assurance Stack

Accessibility fails when it is assigned to one person at the end. A developer cannot fix a video that was never captioned. A content editor cannot repair a custom menu whose state is invisible to assistive technology. A scanner cannot decide whether the available instructions make sense to the person completing the task.

The work holds together through five connected layers:

1. Obligation and target: Define who needs access, what experience is in scope, and which law, policy, contract, and WCAG version apply.
2. Design and content: Build understandable structure, language, contrast, media alternatives, forms, error recovery, motion controls, and readable typography.
3. Code and components: Use semantic markup, reliable keyboard behavior, accurate names and roles, visible focus, correct states, and resilient components.
4. Mixed-method testing: Combine automation with keyboard testing, zoom and reflow, assistive technology, and representative user tasks.
5. Ownership and feedback: Name the people responsible, test releases, provide a way to report barriers, prioritize repairs, and prevent regressions.

How to test a website for accessibility

A useful accessibility evaluation does not begin and end with a browser extension. It combines different methods because each method sees a different part of the problem.

1. Define the scope and target

List the site areas, applications, documents, third-party tools, user roles, languages, authenticated states, and critical tasks in scope. Identify the intended WCAG version and level. Include templates and representative pages rather than scanning only the homepage and admiring the green score.

Critical tasks usually include things such as:

• finding and understanding a service;
• navigating menus and search;
• completing contact, application, registration, or checkout forms;
• signing in and recovering an account;
• reading or downloading essential documents;
• using calculators, maps, booking tools, chat, or customer portals;
• playing media and accessing captions or transcripts; and
• recognizing and recovering from errors.

W3C’s WCAG-EM evaluation methodology provides a structured approach for defining scope, exploring a site, selecting a representative sample, auditing that sample, and reporting findings.

2. Run automated checks

Automated tools are excellent at finding repeatable, machine-detectable issues across many pages. They can surface missing attributes, certain label and name problems, some color-contrast failures, invalid relationships, duplicate IDs, and patterns that deserve review.

They are fast. They are consistent. They are also incapable of deciding everything.

W3C’s evaluation tools overview says some accessibility checks cannot be automated and require human intervention. Tools can also produce inaccurate results. Use them to accelerate evaluation and regression detection, not to outsource judgment.

3. Test with a keyboard

Put the mouse aside. Start at the address bar and use Tab, Shift+Tab, Enter, Space, arrow keys, Escape, and any documented shortcuts.

Verify that:

• every interactive element can be reached and operated;
• focus order follows a sensible path;
• focus is visible and not hidden behind sticky headers, cookie banners, or chat widgets;
• menus, dialogs, accordions, tabs, carousels, and custom controls behave predictably;
• focus moves into and out of dialogs correctly;
• there is no keyboard trap;
• skip links work where needed; and
• the person can recover after an error without starting the entire process over.

Keyboard testing catches failures that a scanner may never understand because the problem exists in the sequence and behavior, not in one isolated line of markup.

4. Test zoom, reflow, spacing, contrast, and motion

Increase text size and browser zoom. Test at narrow viewports. Apply increased text spacing. Check Windows High Contrast Mode or other forced-color environments where relevant. Verify that content does not disappear, overlap, clip, or require two-dimensional scrolling for ordinary reading.

Our website typography guide explains why font size alone is not an accessibility guarantee. Line height, line length, contrast, spacing, layout behavior, and user control all contribute to whether text remains readable.

Pause animation. Use reduced-motion settings. Make sure essential instructions are not hidden inside a hover effect or conveyed only through color.

5. Test with assistive technology

At minimum, test representative tasks with commonly used screen-reader and browser combinations appropriate to the audience and platform. Listen to page structure, headings, landmarks, link names, form labels, instructions, errors, status messages, image alternatives, and component states.

Assistive-technology testing is not “turn on a screen reader and see if it talks.” It requires understanding the expected interaction model and distinguishing a product failure from unfamiliarity with the tool.

6. Include people with disabilities

Conformance testing and usability testing answer related but different questions. A page can satisfy individual technical criteria while the real experience remains confusing or needlessly difficult.

W3C recommends involving users with disabilities in accessibility evaluation because they can identify usability barriers that conformance evaluation alone does not discover. This does not replace standards-based evaluation. It adds reality to it.

Common website accessibility failures

The most damaging failures are not always the most visually dramatic. They are the barriers sitting between a person and the reason they came.

Navigation and structure failures

• Missing or illogical heading structure.
• Vague links such as “click here” repeated without context.
• Menus that open only on hover.
• Keyboard focus that jumps unpredictably.
• No way to bypass repeated navigation.
• Page titles that fail to identify the page.

Form and transaction failures

• Inputs without programmatic labels.
• Placeholder text used as the only instruction.
• Required fields indicated only by color.
• Errors announced visually but not programmatically.
• Date pickers, sliders, uploads, or CAPTCHA challenges that cannot be completed with alternative interaction methods.
• Time limits that cannot be extended.
• Authentication that requires memory puzzles or inaccessible drag actions without an alternative.

Visual and reading failures

• Text or controls with insufficient contrast.
• Fixed-size layouts that break when zoomed.
• Tiny targets packed together.
• Important content embedded in images without a text alternative.
• Long, dense copy with weak headings and no usable hierarchy.
• Low-contrast minimalist design approved because it looked expensive on one designer’s monitor.

Media and document failures

• Video without accurate captions.
• Audio without an equivalent transcript where needed.
• Meaningful visuals without appropriate text alternatives.
• PDFs that are scanned images, have no tag structure, or use a reading order that resembles a shuffled deck of cards.
• Instructions that depend only on color, shape, sound, or position.

Custom component failures

• Buttons built from generic containers without button semantics.
• Dialogs that do not announce their name or trap focus incorrectly.
• Status updates that appear visually but are never announced.
• Tabs, accordions, carousels, and comboboxes with invented keyboard behavior.
• Third-party scheduling, payment, chat, map, or portal tools that introduce barriers outside the site’s main templates.

What to fix first

An audit can produce hundreds of findings. Treating all of them as equal is an efficient way to make nobody responsible for anything.

Prioritize using four factors:

1. User impact: Does the issue block, seriously hinder, or mildly inconvenience someone?
2. Task importance: Does it affect payment, application, booking, account access, safety information, essential documents, or another critical outcome?
3. Reach: Is it in a shared template or component affecting hundreds of pages, or on one rarely used page?
4. Repair leverage: Can one component fix remove the same barrier everywhere?

Start with complete blockers on critical tasks. Then repair shared components and templates. Then address severe issues in high-use content. Continue through lower-impact and isolated findings while protecting the fixes with regression tests.

Do not postpone easy content repairs while waiting for a perfect rebuild. Add the missing label. Correct the heading. Caption the video. Replace the unreadable PDF. Accessibility programs become credible by removing barriers, not by producing a magnificent spreadsheet about them.

Why an accessibility overlay is not a compliance strategy

An accessibility overlay is software added on top of a website, often through one script and a floating interface. Some tools may provide individual features that certain users find helpful. That is a different claim from automatically making the underlying website conform to WCAG or satisfy every legal obligation.

Overlays do not reliably repair inaccessible source code, content, workflows, documents, third-party tools, or design decisions. They can also conflict with the assistive technology and preferences a person already uses.

The claim “install this and any site becomes compliant” is not merely aggressive marketing. In 2025, the Federal Trade Commission finalized an order requiring accessiBe to pay $1 million over allegations that it deceptively advertised an AI-powered overlay as capable of making any website WCAG-compliant. The FTC’s accessiBe case summary is a useful reminder: automation can support accessibility work, but magical compliance claims still need evidence.

Use tools where they are useful. Fix the experience where it is broken. Do not confuse adding a control panel with rebuilding the staircase.

What website accessibility costs

There is no responsible universal price because “make the website accessible” can describe radically different scopes.

Cost depends on:

• the number of unique templates and components;
• the complexity of forms and transactions;
• custom applications and authenticated areas;
• the number and quality of PDFs, videos, and other media;
• third-party tools and vendor cooperation;
• the current codebase and design system;
• the target standard and contractual reporting requirements;
• whether the team needs training and workflow changes; and
• whether the engagement covers evaluation only, remediation, validation, monitoring, or all four.

A ten-page brochure site with clean semantic code is not the same project as an e-commerce system with 6,000 product documents, account management, recurring payments, and three vendor-controlled portals.

Ask a potential accessibility partner to explain:

• what standard and conformance level they will evaluate;
• what pages, components, documents, and tasks are in scope;
• which automated and manual methods they use;
• which assistive technologies and browser combinations they test;
• how findings are prioritized and reproduced;
• whether remediation and validation are separate;
• how they handle third-party systems;
• what they mean by “compliant,” “certified,” or “guaranteed”; and
• how the team will prevent the same issues from returning.

If the entire methodology is “we run our proprietary scanner,” you are buying a scanner report.

A practical website accessibility action plan

This week

Use W3C’s Easy Checks to review page titles, image alternatives, headings, contrast, text resizing, keyboard access, focus, forms, moving content, and media alternatives. Test your highest-value task with a keyboard. Submit every important form and confirm the response is understandable.

This month

Define the target and scope. Inventory templates, components, documents, videos, and third-party tools. Run automated scans, but pair them with manual testing. Fix critical blockers and shared-component failures first. Add a visible way for people to report accessibility problems.

During the next release cycle

Put accessible acceptance criteria into design, content, development, and procurement. Add automated checks to the development pipeline. Create reusable accessible components. Train the people who publish content. Validate the repaired experience with manual and assistive-technology testing.

After launch

Accessibility can regress every time someone changes a heading, uploads a PDF, swaps a plugin, adds a popup, edits a form, or installs the latest shiny conversion toy. It belongs inside website maintenance, not in a forgotten audit folder. Use our website accessibility monitoring guide to establish change gates, testing cadence, ownership, feedback, and repair workflows.

Website accessibility FAQ

Is ADA compliance required for every website?

Not under one identical federal technical rule. DOJ says the ADA applies to online goods, services, programs, and activities offered by state and local governments and businesses open to the public. Title II now has a specific web and mobile rule naming WCAG 2.1 AA. DOJ’s general Title III web guidance does not provide the same detailed technical regulation for private businesses. Other laws, state requirements, contracts, procurement policies, and international rules may also apply. Get legal advice for your actual situation.

What does ADA website compliance mean?

In practical terms, it means providing people with disabilities equal access to the relevant online goods, services, programs, activities, and communications. WCAG supplies testable technical criteria commonly used to evaluate that access, but the legal framework and exact target depend on the organization.

Is WCAG a law?

WCAG is a technical standard, not a statute. A law, regulation, contract, or policy can incorporate a WCAG version and level. DOJ’s Title II web rule, for example, names WCAG 2.1 Level A and AA. For private businesses under Title III, DOJ identifies WCAG as helpful technical guidance while applying the ADA’s broader nondiscrimination and effective-communication requirements.

Should a website target WCAG 2.1 or WCAG 2.2?

Follow the version explicitly required by an applicable law or contract. For current design and development, WCAG 2.2 AA is a responsible target because it adds useful criteria and remains backward compatible with WCAG 2.1 and 2.0. Document the decision so the team understands the difference between the required baseline and the modern engineering target.

What are the four principles of web accessibility?

WCAG’s four principles are Perceivable, Operable, Understandable, and Robust—POUR. They mean people can access the information, operate the interface, understand the content and behavior, and use the experience through a range of browsers and assistive technologies.

How can I tell whether my website is accessible?

Evaluate representative pages, components, documents, and critical user tasks against a defined WCAG target. Combine automated scans, manual keyboard testing, zoom and reflow checks, assistive-technology testing, and evaluation with people with disabilities. A single score cannot establish full conformance or usability.

What are the main types of accessibility testing?

The useful categories are automated testing, expert manual review, assistive-technology testing, and testing with users with disabilities. Teams also need content and document review. These methods overlap, but none makes the others unnecessary.

Is automated accessibility testing enough?

No. Automation is valuable for speed, consistency, coverage, and regression detection, but many criteria require human judgment. A tool cannot reliably decide whether alternative text communicates the purpose of an image, whether instructions make sense, whether focus order supports the task, or whether an error-recovery experience is usable.

What is the best website accessibility checker?

There is no single best checker for every stack and workflow. Choose tools based on the standards they support, the pages they can reach, integration options, reporting quality, false-positive behavior, and the team’s ability to act on results. Use more than a score, and keep manual testing in the process.

Can an accessibility widget make a website compliant?

Do not assume so. A widget may offer individual interface adjustments, but it cannot automatically repair every problem in source code, content, documents, transactions, or third-party systems. Treat broad automatic-compliance promises with skepticism and ask for evidence.

Can a business be sued over an inaccessible website?

Website accessibility disputes and enforcement actions do occur, but the legal analysis depends on jurisdiction, the organization, the relationship between the website and the goods or services offered, and other facts. This article does not predict liability. The more productive business response is to identify and remove barriers rather than gamble on a slogan from either side.

Does an accessibility statement make a website compliant?

No. A useful statement can identify the accessibility target, known limitations, contact method, and response process. It cannot substitute for an accessible experience. A beautifully worded statement attached to a broken application form is documentation of the problem, not a fix.

How often should a website be audited for accessibility?

The right cadence depends on change frequency, risk, complexity, and audience. Test significant releases and changed components before launch. Monitor high-value templates continuously where practical. Run scheduled manual reviews and periodic broader evaluations. A fast-moving e-commerce site needs a different cadence than a small site updated twice a year.

Who is responsible for website accessibility?

Leadership owns the expectation and resources. Designers own usable patterns. Writers and editors own structure and alternatives. Developers own semantic and interactive behavior. QA owns verification. Procurement owns vendor requirements. Site owners own ongoing monitoring and response. When accessibility belongs only to “the accessibility person,” everyone else is free to reintroduce the same failures.

Does accessibility help SEO?

Some accessibility practices—descriptive titles, meaningful headings, semantic structure, text alternatives, captions, and understandable link text—can also help search engines interpret content. That overlap is useful, but accessibility is not an SEO tactic. A page can rank while blocking people, and a technically accessible page can still be irrelevant to a search query.

Build access into the work, not around it

Accessibility is not a favor to a theoretical edge case. It is the discipline of making sure the people you claim to serve can actually use the thing you built.

Start with the outcome. Choose the applicable target. Design and write for access. Build components that behave correctly. Test with more than one method. Give somebody ownership after launch. Listen when users report a barrier, then fix the barrier instead of defending the score.

That is less glamorous than installing a miracle script. It is also how serious websites get built.