ADA Compliance Checklist for Websites

1 in 4 U.S. adults has a disability(opens in a new tab); yet, only 3% of website homepages are fully accessible(opens in a new tab), which means most websites are quietly locking out a significant portion of their audience.

The Americans with Disabilities Act(opens in a new tab) (ADA) requires that digital content be accessible to people with disabilities, and, in practice, that means meeting the Web Content Accessibility Guidelines(opens in a new tab) (WCAG) 2.1 Level AA. Failing to meet that standard puts your business at legal risk, but more importantly, it means real people can’t access your content or services. 

Below, we’ve created a checklist to help you assess whether your website or digital content meets ADA compliance requirements. 

What is ADA Compliance?

The ADA was designed to protect people with disabilities from discrimination in places of public accommodation. Recent DOJ guidance confirmed that the internet qualifies, meaning businesses open to the public must make their digital content accessible to people with disabilities, including those who rely on assistive technologies such as screen readers. 

Because the ADA doesn’t include technical standards, most businesses follow WCAG 2.1 Level AA, the international benchmark for web accessibility and the standard most courts reference in ADA lawsuits. 

Another important note: Federal agencies and their vendors are also subject to Section 508 compliance, which ties directly to WCAG. For a full breakdown of how these laws connect, see our post: The Difference Between Section 508, ADA, and WCAG.

Is ADA Compliance Mandatory?

Yes. While the ADA predates the internet, DOJ guidance has made clear that websites are considered public places. Businesses that fail to meet accessibility standards face real legal exposure and real barriers for people trying to use their sites.

ADA compliance checklist with orange checkmarks

ADA Compliance Checklist

To make it easy for you to start checking your website for common ADA violations, we’ve included the WCAG success criteria in a checklist below.

• Use sufficient color contrast: Without enough contrast between text and its background, users with low vision or color blindness may struggle to read your content, even if it looks fine to someone without visual disabilities. Color contrast refers to the difference in luminance between those two elements, and small differences can have a big impact on readability. Use a color contrast checker to test our existing palette and flag any combinations that fall short. Per WCAG Success Criterion 1.4.3(opens in a new tab), normal text requires a minimum contrast ratio of 4.5:1 and large text 3:1. 

• Include alt text: Without alt text, users with visual impairments who rely on screen readers may have no idea what an image, chart, or button is or why it’s there. Alt text is a short written description attached to non-text content that screen readers read aloud in place of the visual. Keep it descriptive but concise, and leave it empty (alt=””) for purely decorative images to screen readers skip over them. Per WCAG Success Criterion 1.1.1(opens in a new tab), all non-text content should have alt text that serves the same purpose.

• Provide captions for videos: Users who are deaf or hard of hearing rely on captions to access video content, and they also benefit users watching in noisy environments or those who process written information more easily than audio. Captions are a synchronized text version of a video’s audio track, and accuracy matters: errors in auto-generated captions are one of the most common accessibility complaints. Review auto-captions before publishing rather than relying on them as is. WCAG Success Criterion 1.2.2(opens in a new tab) requires captions for all prerecorded video content that includes audio. 

• Use descriptive links: Link text like “click here” or “read more” gives screen reader users no information about where the link goes or why they’d want to follow it. Screen readers can pull up a list of all links on a page, and without descriptive text, that list becomes meaningless. A quick test: read your links out loud and ask whether they make sense without surrounding context. Doing so will help you meet WCAG Success Criterion 2.4.4,(opens in a new tab) which requires a link’s purpose to be clear from the text alone or from the link text combined with its programmatic context.

• Provide accessible forms and documents: Online forms and documents, such as PDFs, are among the most common sources of high-impact accessibility issues. Users who rely on keyboard navigation or screen readers need clear labels, descriptive instructions, and meaningful error messages to complete tasks successfully. Without these, a user may not know what a field is asking for, or have no way to understand what went wrong if they encounter an error. Test your forms by navigating them using only keyboard commands or a screen reader to ensure you meet WCAG Success Criterion 1.3.1(opens in a new tab).

• Avoid fast strobing lights: Flashing or strobing content can trigger seizures in users with photosensitive epilepsy, and the threshold is lower than most people assume. WCAG Success Criterion 2.3.1(opens in a new tab) sets the limit at no more than three flashes per second. If strobing is necessary, use it sparingly and provide a way for users to turn it off.

• Include zoom functionality: Users with visual or cognitive disabilities often rely on browser zoom or text resizing to make content readable. If your site blocks zooming (through viewport meta tags or fixed layouts), those users lose a tool they depend on. Ensure your text can be resized up to 200% without loss of content or functionality, per WCAG Success Criterion 1.4.4(opens in a new tab). Test by zooming in on your content and checking whether the content flows cleanly without requiring horizontal scrolling.

• Use headings properly: Headings aren’t just a visual formatting choice. They’re how screen reader users navigate a page. A user relying on a screen reader can pull up a list of all headings on a page and jump between them, so a broken or illogical heading structure makes it much harder to find information. WCAG Success Criterion 1.3.1(opens in a new tab) requires heading structure to reflect the actual hierarchy of content on the page, so avoid skipping heading levels or using headings purely for visual size.

• Support keyboard navigation: Not every user uses a mouse. Users with motor disabilities, tremors, or limb differences often rely entirely on a keyboard to navigate the web, tabbing through links, buttons, and form fields in sequence. If any functionality on your site requires a mouse to operate, those users are locked out, and you fail to meet WCAG Success Criterion 2.1.1(opens in a new tab). Test by unplugging your mouse and navigating your entire site using only the Tab, Enter, and arrow keys.

• Add skip navigation: Every time a user lands on a new page, a screen reader reads from the top, which means navigating through your entire navigation menu before reaching the actual content, on every single page. WCAG success Criterion 2.4.1(opens in a new tab) requires a skip mechanism so users can bypass repeated blocks of content across pages, typically via skip navigation links. 

• Ensure assistive technology compatibility: A site can look accessible on paper but still fail in practice if it doesn’t work correctly with the tools real users depend on, such as screen readers like JAWS or NVDA, screen magnifiers, or switch devices. Compatibility issues often stem from poorly written HTML or misuse of ARIA that confuses assistive technology. WCAG Success Criterion 4.1.2(opens in a new tab) requires that all components have programmatically determinable names, roles, and values. The most reliable way to test this is with actual assistive technologies, not just automated checkers.

• Use error messages: When a form submission fails, users need to know what went wrong and how to fix it. Vague error messages like “invalid input” leave users guessing, and for users with cognitive disabilities, that frustration can be a barrier to completing a task entirely. Per WCAG Success Criterion 3.3.1(opens in a new tab), error messages should identify the specific field, explain what the error is, and suggest how to correct it.

• Avoid using color alone to convey information: If your site relies solely on color to communicate something (e.g., a red field for errors, a green badge to indicate status), users with color blindness may miss it entirely. WCAG Success Criterion 1.4.1(opens in a new tab) mandates that color not be the only visual means of conveying information or indicating an action. Information should be conveyed through a secondary means, such as an icon, label, or pattern. This applies to charts and graphs, too, where color-coded data sets are a common accessibility issue.

• Ensure consistency across pages: When navigation, buttons, and icons behave differently from page to page, it creates a cognitive load for all users — and a much steeper barrier for users with cognitive or learning disabilities who rely on predictable patterns. Per WCAG Success Criterion 3.2.4(opens in a new tab), components that have the same functionality across a set of pages must be identified consistently. That consistency also helps screen reader users build a mental model of your site’s structure. Run a quick audit across your key page templates to check that repeated components look and behave the same way.

• Provide controls for auto-play content: Auto-playing video or audio can be disorienting for screen reader users because the content competes directly with the screen reader’s audio output. WCAG Success Criterion 1.4.2(opens in a new tab) requires that audio that plays automatically for more than 3 seconds include a way for users to pause, stop, or mute it. Give users a visible, easy-to-find way to pause or stop auto-play content. Where possible, avoid auto-play altogether.

• Provide controls for time limits: Session timeouts and time-limited interactions are significant barriers for users who need more time to read, process, or respond, including users with cognitive disabilities, motor impairments, or low vision. WCAG Success Criterion 2.2.1(opens in a new tab) mandates that users have a way to turn off, adjust, or extend any time limits unless they’re essential. Warn users before a timeout occurs and give them the option to extend their session without losing their progress. This can save users from frustration or being unable to complete critical tasks.

• Use the right language attributes: Screen readers use a page’s language attribute to determine which language rules and pronunciation patterns to apply. If the lang attribute is missing or incorrect, a screen reader may read English content with the wrong accent engine, making it difficult or impossible to understand. WCAG Success Criterion 3.1.1(opens in a new tab) requires the default human language of each page to be programmatically determined. This is a small fix with a meaningful impact, and takes less than a minute to check in your page’s HTML.

To further improve your site's accessibility, provide a way for users to report accessibility issues. This allows you to take more proactive steps to resolve them and improve the user experience.

Mobile App Checklist

ADA compliance doesn't stop at the browser. Mobile apps are subject to the same accessibility requirements as websites and follow the same WCAG principles. The items below address the most common accessibility gaps specific to mobile interfaces.

• Use adequate touch target size: Small tap targets are one of the most common barriers on mobile. Users with motor impairments or tremors may struggle to accurately tap buttons, links, or icons that are too small. Per WCAG Success Criterion 2.5.5(opens in a new tab), touch targets should be at least 44x44 pixels. Make sure all interactive elements are large enough to tap reliably and that there is sufficient spacing between them.

• Don’t disable pinch-to-zoom: Many users with low vision rely on pinch-to-zoom to enlarge content and make it readable. Disabling it (which is easy to do by accident in viewport settings) removes a tool that those users depend on. Per WCAG Success Criterion 1.4.4(opens in a new tab), content must remain accessible when text is scaled to 200%, meaning zoom cannot be blocked. This is one of the most common mobile accessibility errors and one of the easiest to fix. 

• Maintain color contrast in mobile UI: Color contrast requirements don't change on mobile, but smaller screens and variable lighting conditions, such as bright sunlight, make contrast even more critical. UI elements such as icon labels, status indicators, and button text are frequent offenders in mobile interfaces. WCAG Success Criterion 1.4.3(opens in a new tab) requires a minimum contrast ratio of 4.5:1 for normal text, regardless of device. Test your app's contrast ratios using a mobile accessibility checker rather than assuming desktop testing covers it. 

• Support native accessibility APIs: Mobile operating systems have built-in accessibility tools (e.g., VoiceOver on iOS and TalkBack on Android) that users with visual or motor disabilities rely on to navigate apps. If your app isn't built to work with these APIs, those users may find buttons unlabeled, gestures unresponsive, or entire screens unnavigable. Test your app with VoiceOver and TalkBack enabled before launch, not as an afterthought. This will also ensure you meet WCAG Success Criterion 4.1.2(opens in a new tab) requirements.

• Use accessible form inputs: Mobile form fields present unique challenges: small keyboards, autocorrect interference, and unclear labels can make forms difficult for anyone, and nearly impossible for users with cognitive or motor disabilities. WCAG Success Criterion 3.3.2(opens in a new tab) requires that labels or instructions be provided when content requires user input. Additionally, each input should have a visible, programmatically associated label, and error messages should be specific and easy to find on a small screen. Enable appropriate keyboard types for each field (numeric for phone numbers, email for email fields) to reduce input errors. 

• Don’t lock screen orientation: Locking an app to portrait or landscape mode creates a barrier for users with devices mounted in a fixed position — a common setup for users with motor disabilities who use wheelchair mounts or other assistive hardware. Your app should respond to the orientation of the user's device without breaking the layout or cutting off content, per WCAG Success Criterion 1.3.4(opens in a new tab).

Computer monitor showing internet browser with the United States Department of Justice seal

Beyond WCAG: Best Practices to Stay ADA-Compliant

Beyond taking steps to make a website more accessible, businesses must employ best practices to reduce the risk of being sued — and penalized — for ADA non-compliance. In addition to the checklist above, here are a few best practices to help you achieve and maintain compliance.

Have an Ongoing Plan for Accessibility

Every time you publish new content or make changes to your site, you create an opportunity for new accessibility issues to surface, which is why a one-time ADA audit isn't enough. Put a recurring testing and fix process in place to catch issues before they become complaints. Businesses with documented, ongoing accessibility programs are better positioned to demonstrate good-faith compliance if a lawsuit arises.

Take a Comprehensive Approach

Automated tools can only catch some accessibility issues — coding errors and context-dependent problems require human review alongside automation. Use an accessibility platform that combines intelligent automated scanning with certified expert auditing for a more complete picture. A hybrid approach reduces the likelihood of issues slipping through that could expose your business to legal risk.

Publish an Accessibility Statement

An accessibility statement signals to users, and to plaintiffs' ADA attorneys, that accessibility is an active priority, not an oversight. It should identify the standard you're working toward (such as WCAG 2.1 Level AA), note any known limitations, and include contact information for users who encounter issues. Sites with accessibility statements have a clearer paper trail of intent, which matters significantly in legal disputes.

Build Accessibility in from the Start

Retrofitting an inaccessible site is significantly more expensive and time-consuming than designing with accessibility in mind from the beginning. Use developer tools that flag issues during the build process and involve people with disabilities in testing at every stage — their firsthand experience surfaces problems automated tools consistently miss. The earlier accessibility is treated as a requirement rather than a feature, the lower the long-term compliance costs.

Meet ADA Requirement and Ensure Accessibility with AudioEye

Ensuring your digital content is ADA-compliant helps you create a more inclusive online environment for users with disabilities and improves their overall experience. Plus, it helps you avoid legal action against your business for lack of accessibility.

Creating digital content that provides a seamless user experience and is compliant is easy with AudioEye. AudioEye combines AI-powered automation with Expert Audits and Custom Fixes to detect more issues, resolve them faster, and keep your site protected as it evolves. The result: ~97% of issues resolved and 400% more legal protection than automation-only solutions.

Ready to get closer to an ADA-compliant website? Run a free scan or schedule a demo to see how AudioEye can help you meet ADA compliance standards.