The ADA-Compliant Website Design Checklist

An ADA-compliant website is one that people with disabilities can perceive, navigate, and use as fully as everyone else, built to the Web Content Accessibility Guidelines (WCAG) 2.1 or 2.2 at Level AA. In practice, that means every image has meaningful alternative text, every interactive element works with a keyboard and a screen reader, color contrast meets minimum ratios, and the underlying code is clean enough for assistive technology to interpret. The checklist below walks through exactly what to audit, in priority order, so you can find the gaps, fix them, and keep your site compliant as it grows.

Accessibility is no longer a nice-to-have. Of the top one million home pages tested in the WebAIM Million 2026 report, 95.9% had at least one detectable WCAG failure, with an average of 56.1 errors per page. At the same time, plaintiffs filed thousands of digital accessibility lawsuits in U.S. federal and state courts last year. The risk is real, the standard is well defined, and the path to compliance is more straightforward than most teams assume.

What “ADA Compliant” Actually Means for a Website

The Americans with Disabilities Act (ADA) does not contain a line-by-line technical spec for websites. Instead, courts and regulators have consistently pointed to WCAG as the measuring stick. In April 2024, the U.S. Department of Justice finalized a Title II rule formally adopting WCAG 2.1 Level AA as the technical standard for state and local government websites, with compliance deadlines that now fall in April 2027 for larger entities and April 2028 for smaller ones. Private businesses are generally covered under Title III, where WCAG 2.1 or 2.2 Level AA has become the de facto benchmark referenced in settlements and consent decrees.

WCAG itself is built on four principles, summarized by the acronym POUR:

• Perceivable – users must be able to perceive the information, regardless of sensory ability (for example, alt text for images, captions for video).
• Operable – users must be able to operate the interface, including by keyboard alone.
• Understandable – content and operation must be clear and predictable.
• Robust – content must work reliably across browsers, devices, and assistive technologies, now and in the future.

WCAG 2.2, published by the W3C as a Recommendation and approved as ISO/IEC 40500, contains 87 success criteria across three levels: A, AA, and AAA. Level AA is the target for legal compliance and the standard this checklist is built around. It requires meeting all Level A and AA criteria, 56 in total.

Why ADA Compliance Is Worth Prioritizing

Three forces make accessibility a business priority, not just a legal one.

Legal exposure is growing. In 2025, ADA Title III filings in federal court exceeded 8,600 cases, and website accessibility claims made up roughly a third of them. A mid-year report tracked a 37% year-over-year surge in web accessibility lawsuits, with New York, Florida, and California leading filings and new hotspots like Illinois emerging. Most claims target the same handful of fixable issues.

The audience is large. The CDC estimates that roughly one in four U.S. adults lives with a disability. An inaccessible site silently turns away a significant share of potential customers, often without a single complaint, because most users simply leave.

Accessibility and quality overlap. Clean semantic markup, descriptive link text, logical heading order, and fast keyboard navigation also improve SEO, Core Web Vitals, and overall usability. Building for accessibility tends to make the whole site better for everyone, including search crawlers and AI engines that parse your content.

The ADA-Compliant Website Design Checklist

Work through these in order. The first three categories cover the issues that appear most often in automated scans and lawsuits, so they deliver the most risk reduction per hour of effort.

1. Text Alternatives and Images

• Every meaningful image has descriptive alt text that conveys its purpose, not just its file name.
• Decorative images use empty alt attributes (alt="") so screen readers skip them.
• Complex images such as charts and infographics have a longer text description nearby.
• Images of text are avoided; use real, styled text instead.
• Icons that carry meaning include an accessible name (via aria-label or visually hidden text).

2. Color and Contrast

• Body text meets a contrast ratio of at least 4.5:1 against its background.
• Large text (24px, or 18.66px bold) meets at least 3:1.
• Interactive elements and meaningful graphics meet at least 3:1.
• Color is never the only way information is conveyed; pair it with text, icons, or patterns (for example, error states that show both red and a message).

3. Forms and Inputs

• Every input has a programmatically associated <label>.
• Required fields and formats are clearly indicated in text, not by color alone.
• Error messages identify the field and explain how to fix the problem.
• Related inputs are grouped with <fieldset> and <legend> where appropriate.
• Autocomplete attributes are used for common fields to reduce input burden.

4. Keyboard Operability

• All functionality works with a keyboard alone, no mouse required.
• The visible focus indicator is always present and clearly distinguishable.
• Focus order follows a logical reading sequence.
• There are no keyboard traps where focus cannot move away from a component.
• A “skip to main content” link lets keyboard and screen reader users bypass repeated navigation.

5. Structure and Semantics

• One <h1> per page, with headings nested in logical order (no skipped levels).
• Landmark regions (<header>, <nav>, <main>, <footer>) are used so assistive tech can jump between sections.
• Lists use real list markup; tables use proper <th> headers and scope attributes.
• The page lang attribute is set so screen readers use correct pronunciation.
• ARIA is used only to fill genuine gaps, never as a substitute for native HTML.

6. Links, Buttons, and Controls

• Link text describes its destination; avoid bare “click here” or “read more.”
• Buttons and links have accessible names (no empty links or empty buttons).
• Touch and click targets are large enough to activate comfortably, at least 24 by 24 CSS pixels under WCAG 2.2.
• Custom widgets expose the correct role, state, and name to assistive technology.

7. Media and Motion

• Pre-recorded video has accurate captions; key audio content has a transcript.
• Audio descriptions are provided for video where visuals carry essential information.
• Auto-playing audio or video can be paused, stopped, or muted.
• Content does not flash more than three times per second.
• Animation respects the prefers-reduced-motion user setting.

8. Responsive and Zoom Support

• Content reflows without horizontal scrolling when zoomed to 200%.
• The layout adapts down to a 320px viewport width.
• Text can be resized up to 200% without loss of content or function.
• Orientation is not locked unless essential.

9. Predictability and Help

• Navigation and component patterns are consistent across pages.
• Help options (such as contact details or a search) appear in a consistent location.
• Users are not asked to re-enter information they already provided in the same process.
• Authentication does not rely on a cognitive test like remembering or transcribing a code, unless an alternative is offered.

10. Testing and Governance

• Run an automated scan to catch obvious failures (these typically detect 30 to 40% of issues).
• Perform manual keyboard-only and screen reader testing on key flows.
• Include people with disabilities in usability testing where possible.
• Publish an accessibility statement with a contact method for reporting barriers.
• Re-test after every significant design or content release.

A 5-Step Process to Reach and Maintain Compliance

A checklist tells you what to fix. This process tells you how to get there without stalling.

Step 1: Audit against WCAG 2.2 Level AA. Combine an automated scan with manual testing. Automated tools are fast but only catch a fraction of real barriers, so pair them with keyboard and screen reader checks on your highest-traffic templates.

Step 2: Triage by impact and frequency. Map each issue to the templates it affects. A contrast or missing-label problem in your global header or checkout flow outranks a one-off issue on a buried page, because template-level fixes cascade everywhere.

Step 3: Remediate at the source. Fix issues in components and templates, not page by page. Resist accessibility overlay widgets as a primary solution; they often fail to address underlying code problems and have themselves been named in litigation.

Step 4: Validate the fixes. Re-test each remediated flow with the same keyboard and screen reader methods used in the audit. Confirm the fix did not introduce new issues.

Step 5: Bake accessibility into your workflow. Add accessibility acceptance criteria to design and development tickets, run automated checks in your build pipeline, and schedule periodic manual audits. Accessibility is a state you maintain, not a project you finish.

For a real-world example, see how Lounge Lizard partnered with Underlined to deliver a website built around strong UX and UI. The engagement shows how prioritizing usability and clean design can turn a site into one that genuinely supports the business behind it.

Manual vs. Automated Accessibility Testing

Neither approach is sufficient on its own. The strongest programs use both, with automated tools for breadth and speed and manual testing for the issues that require human judgment.

Common Mistakes That Break Compliance

• Relying on an overlay widget. Overlays do not fix the underlying code and have not reliably protected sites from legal claims.
• Treating alt text as a formality. Stuffing keywords or repeating the file name fails users and search engines alike.
• Over-using ARIA. Pages loaded with ARIA frequently have more errors, not fewer. Native HTML elements come with accessibility built in.
• Removing focus outlines for aesthetics. A missing focus indicator makes keyboard navigation nearly impossible.
• Testing once and forgetting. Every new template, plugin, or campaign page can reintroduce barriers.

Frequently Asked Questions

What does it mean for a website to be ADA compliant?

An ADA-compliant website lets people with disabilities access and use its content and functions as effectively as anyone else. Because the ADA does not specify technical requirements for websites, compliance is measured against the Web Content Accessibility Guidelines (WCAG), typically version 2.1 or 2.2 at Level AA, covering things like alt text, color contrast, keyboard operability, and clean semantic code.

Which WCAG version and level should I target?

Aim for WCAG 2.2 Level AA. It is the current published standard, it is backward compatible with WCAG 2.1, and Level AA is the conformance level courts, regulators, and the U.S. Department of Justice’s Title II rule reference for legal compliance. Meeting Level AA means satisfying all Level A and AA success criteria.

Can I make my website ADA compliant with an accessibility plugin or overlay?

No single plugin or overlay can make a site fully compliant. These tools may help with surface-level adjustments, but they do not fix the underlying HTML, ARIA, and design issues that cause most failures, and overlays have been named in accessibility lawsuits. Durable compliance comes from fixing accessibility at the code and design level and testing both automatically and manually.

How often should I test my website for accessibility?

Test continuously, not once. Run automated checks within your development pipeline so regressions are caught before launch, and perform manual keyboard and screen reader audits on critical flows before every major release and on a recurring schedule. Sites change constantly, and each change can introduce new barriers.

Is ADA compliance legally required for private business websites?

In practice, yes for most. While the ADA’s application to private websites is still being shaped through litigation, courts have repeatedly treated business websites as places of public accommodation under Title III, and the volume of web accessibility lawsuits continues to rise each year. Building to WCAG 2.2 Level AA is the most reliable way to reduce legal exposure and serve all of your users.

Make Accessibility Part of How You Build

ADA compliance is not a one-time stamp. It is a standard you design toward, test against, and maintain as your site evolves. Start with the checklist above, fix the highest-impact issues at the template level, and put testing into your regular workflow. If you want an expert audit or an accessible site built right from the start, the team that designs and develops for compliance can get you there faster and keep you there.

DRIVE YOUR SALES TO NEW HEIGHTS!

TALK TO A MARKETING MIXOLOGIST