Checklist10 min readFebruary 8, 2026

Is My Website ADA Compliant? A Complete Checklist

If you have ever asked yourself “Is my website ADA compliant?” you are not alone. With ADA lawsuits surging in 2026, understanding your website's compliance status is more important than ever. This checklist will help you evaluate your site against the most critical accessibility requirements.

What Does ADA Compliance Mean for Websites?

The Americans with Disabilities Act (ADA) does not contain a specific technical standard for websites. However, the Department of Justice has consistently pointed to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA as the appropriate benchmark for ADA website compliance. Most court settlements and consent decrees require conformance to WCAG 2.0 or 2.1 at the AA level.

In practical terms, ADA compliance for your website means that people with disabilities—including those who are blind, have low vision, are deaf or hard of hearing, have motor impairments, or have cognitive disabilities—can perceive, navigate, interact with, and understand your web content. The WCAG 2.2 standard organizes its requirements around four principles: Perceivable, Operable, Understandable, and Robust (POUR).

This checklist covers the most critical items you should evaluate. While it does not cover every single WCAG success criterion (there are over 80), it addresses the issues that account for the vast majority of accessibility barriers and legal complaints. For a complete evaluation, use our full WCAG checklist tool.

Perceivable: Can Users See and Hear Your Content?

The Perceivable principle requires that all information and user interface components are presented in ways that users can perceive through at least one of their senses.

Images Have Alternative Text

Every meaningful image on your website must have an alt attribute that describes its content or function. Decorative images should have an empty alt="" attribute so screen readers skip them. This is the single most commonly cited violation in ADA lawsuits.

Color Contrast Meets Minimum Ratios

Normal text (under 18px or 14px bold) must have a contrast ratio of at least 4.5:1 against its background. Large text (18px or 14px bold and above) requires at least 3:1. Use our color contrast checker to test your specific color combinations.

Video Content Has Captions

All pre-recorded video content with audio must have accurate, synchronized captions. Live video should have captions where feasible. Auto-generated captions are a starting point but must be reviewed for accuracy. Audio-only content (like podcasts) needs a text transcript.

Content Does Not Rely Solely on Color

Information conveyed through color must also be available through other means, such as text labels, patterns, or icons. For example, error states should not be indicated only by changing a form field to red—they should also include an error message or icon.

Text Can Be Resized to 200%

Users must be able to zoom text up to 200% without loss of content or functionality. Avoid using fixed pixel sizes for text containers. Test your site at 200% browser zoom and ensure no content overflows or becomes hidden.

Operable: Can Users Navigate and Interact?

The Operable principle ensures that all user interface components and navigation can be operated by all users, regardless of the input method they use.

All Functionality Works with Keyboard Only

Every interactive element—links, buttons, form fields, menus, modals, sliders, and custom widgets—must be fully operable using only a keyboard. Press Tab to navigate forward, Shift+Tab to navigate backward, Enter or Space to activate, and Escape to close. No functionality should require a mouse.

Focus Is Visible at All Times

When a user tabs through your page, a visible focus indicator must be present on the currently focused element. Many websites remove the default focus outline for aesthetic reasons using outline: none. If you remove the default indicator, you must provide a custom one that is clearly visible.

No Keyboard Traps Exist

Users must never become stuck in a component where they cannot tab away using the keyboard. Common keyboard traps include modals without an Escape key handler, embedded media players, and WYSIWYG editors. Test every interactive element to ensure users can always navigate away.

Pages Have Descriptive Titles

Each page must have a unique, descriptive <title> element that describes its purpose. Titles like “Untitled” or “Page 1” are not acceptable. Users who rely on screen readers use page titles to understand where they are and to navigate between open tabs.

Interactive Targets Are Large Enough

WCAG 2.2 requires that interactive targets (buttons, links, form elements) be at least 24 by 24 CSS pixels. This helps users with motor impairments, tremors, or limited fine motor control. Small targets placed close together are a common accessibility failure, especially on mobile.

Understandable: Can Users Comprehend Your Content?

The Understandable principle requires that content and interface operations are comprehensible to all users, including those with cognitive and learning disabilities.

Page Language Is Declared

The <html> element must include a valid lang attribute (e.g., lang="en"). Screen readers use this attribute to determine which language rules to apply for pronunciation. Content in a different language than the page default should be marked with its own lang attribute.

Forms Have Clear Labels and Error Messages

Every form input must have a programmatically associated label (using the <label> element or aria-label). When errors occur, they must be clearly identified in text (not just by color), and suggestions for correction should be provided when possible. Required fields must be clearly indicated.

Navigation Is Consistent Across Pages

Navigation menus and other repeated components must appear in the same relative order on every page. Users with cognitive disabilities rely on predictable layouts to navigate websites efficiently. Changing the position or order of navigation elements between pages creates confusion.

No Unexpected Context Changes

Focusing on or changing the value of an element should not automatically trigger a change of context (such as navigating to a new page, opening a pop-up, or moving focus) unless the user has been informed in advance. Select elements that automatically submit a form when a value is chosen are a common violation.

Robust: Does Your Code Work with Assistive Technology?

The Robust principle requires that content is implemented in a way that is compatible with current and future assistive technologies.

Heading Hierarchy Is Logical

Headings must follow a logical hierarchy without skipping levels. Each page should have one <h1>, followed by <h2>s for main sections, <h3>s for subsections, and so on. Screen reader users navigate pages by jumping between headings, so a logical hierarchy is critical.

ARIA Attributes Are Used Correctly

If you use ARIA attributes, they must be used according to the ARIA specification. Incorrect ARIA is worse than no ARIA at all—it can actively mislead assistive technology users. Common mistakes include using role="button" on elements that do not have keyboard event handlers, or setting aria-hidden="true" on visible, interactive elements.

Links Have Descriptive Text

Link text must clearly describe the destination or purpose of the link. Avoid generic link text like “Click here,” “Read more,” or “Learn more” without additional context. Screen reader users often navigate by pulling up a list of all links on a page, where generic text provides no useful information.

Status Messages Are Announced

Dynamic status messages—such as form submission confirmations, search results counts, or loading indicators—must be announced to assistive technology without requiring the user to move focus. Use ARIA live regions (aria-live="polite" or role="alert") to communicate dynamic changes.

Quick Self-Assessment: How Did You Score?

If you were able to confirm all of the items in this checklist, your website is in good shape for ADA compliance. However, keep in mind that this checklist covers only the most critical criteria. WCAG 2.2 Level AA contains over 50 success criteria in total, and a comprehensive audit should evaluate all of them.

If you found issues—or were unsure about several items—you are not alone. Research from WebAIM consistently finds that over 96% of the top one million websites have detectable WCAG failures on their homepage. The important thing is to start addressing issues now, prioritizing the most impactful barriers first.

For an objective, automated assessment of your website, run a free scan below. Our scanner checks your pages against WCAG 2.2 criteria and provides an actionable report with specific issues, their severity, and guidance on how to fix each one.

Get a Definitive Answer: Is Your Website ADA Compliant?

Stop guessing. Enter your URL below and get a detailed accessibility report in under 30 seconds. Free scan, no signup required.