ADA Website Compliance Checklist: What You Need to Know

An ADA website compliance checklist turns one technical standard, WCAG 2.1 Level AA, into checks you can run on your own site. The Department of Justice's April 2024 rule made WCAG 2.1 AA a legal requirement under ADA Title II, which covers state and local governments, not private businesses. After the April 2026 interim final rule, entities serving 50,000 or more people must comply by April 26, 2027, and smaller entities and special district governments by April 26, 2028. For private businesses under Title III there is no technical regulation, but courts and DOJ guidance commonly point to WCAG 2.1 AA as the benchmark. This guide walks through what to check, in plain language, with a fast developer checklist you can run on any page.

Each row is one check in plain English, with the WCAG 2.1 success criteria it covers. Together the 36 rows cover all 50 Level A and AA criteria (30 at A, 20 at AA) in the W3C WCAG 2.1 Recommendation.

This checklist is general information, not legal advice.

We build and scan sites for accessibility constantly, and the single most common thing we see is a team that believes their site is accessible because it looks clean and modern. Accessibility is not about how a site looks. It is about whether it works for someone using a screen reader, a keyboard, or a magnifier, and that is invisible until you test for it. So let us make it visible. Everything below is written to be checked, not just read.

What is ADA website compliance, and what standard applies?

The ADA is a civil rights law that requires businesses and services open to the public to be accessible to people with disabilities. Think of it as the digital equivalent of a ramp into a building: your website should work as well for someone who cannot use a mouse or see the screen as it does for everyone else. The law itself does not contain a line of technical detail, which is where WCAG comes in.

WCAG, the W3C's Web Content Accessibility Guidelines, supplies that detail, and Level AA is the conformance level most laws and settlements reference. The DOJ's April 2024 Title II rule made WCAG 2.1 AA explicit for state and local governments, and it is the de facto standard courts apply to private businesses too (our explainer on the ADA Title II deadline moving to 2027 covers what changed). So "ADA compliance" and "WCAG compliance" are not two different jobs: following WCAG 2.1 AA is the practical way to meet your ADA obligation, and the rest of this checklist is what that standard asks for. For the full map of US laws, see which accessibility standard applies to your website.

Start with text alternatives for images and media

Every meaningful image, icon, and graphic needs a text description, the "alt text," that a screen reader can read aloud so a blind user understands what is there. Good alt text is specific but concise: "woman typing on a laptop in an office" tells the story, while "image123.jpg" tells the user nothing. The judgment call people miss is that decorative images, a divider line or a background flourish, should be marked as decorative with empty alt text, so the screen reader skips them instead of announcing clutter.

Media needs the same care in a different form. Videos need captions so people who are deaf or hard of hearing can follow along, and those captions help everyone in a loud room or watching without sound. Audio-only content needs a transcript. The principle underneath all of this is simple: any information carried by an image or a sound must also exist as text, because text is the one format every assistive technology can reach.

Make keyboard navigation work everywhere

Many people navigate the entire web without a mouse, using the keyboard alone, and this is where a large share of real-world barriers live. Your site must let someone tab through every link, button, and form field in a logical order, operate everything with Tab and Enter (and arrow keys where appropriate), and, critically, never trap them somewhere they cannot escape from with the keyboard.

There is a test you can run in the next two minutes, and we recommend it to every team: put your mouse aside and try to use your own site with only the Tab, Enter, and arrow keys. Can you reach every button? Open and close a pop-up? Complete a form? If anything is unreachable or you get stuck, that feature is broken for keyboard users. While you do this, watch for the focus indicator, the visible outline or highlight showing where you are on the page. If it is missing or invisible, users literally cannot tell where they are, which fails WCAG and makes the site unusable for keyboard navigation.

Use proper headings and semantic HTML

Headings are how screen reader users navigate a page, so they need to form a logical outline rather than being chosen for their visual size. Use one H1 for the page title, H2 for major sections, H3 for subsections beneath them, and do not skip levels for styling reasons. A user who jumps by headings should be able to understand your page structure from the outline alone.

The same discipline applies to every element. Use a real button element for buttons, not a div styled to look like one, because the real element comes with keyboard operability and the right screen reader announcement for free. Use list markup for lists, associate every form field with a real label, and reach for native HTML elements before custom widgets. This is semantic HTML, and it is the difference between assistive technology understanding your page and guessing at it. It is also where small code-quality problems quietly cause accessibility failures, a connection we dug into in our piece on how small code quality issues quietly break accessibility.

Get color and contrast right

Text needs enough contrast against its background for people with low vision to read it comfortably. The WCAG 2.1 AA threshold is a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, and low contrast is consistently the single most common failure we find on real sites. If you only fix one visual issue, fix this one, because it affects the widest range of users and is usually straightforward to correct. For the exact ratios, the definition of "large" text, and a step-by-step method, our guide to fixing low color contrast walks through the whole process.

Contrast is only half of the color story. Never rely on color alone to communicate meaning, because color-blind users and screen reader users will miss it. If an error field turns red, also add text that says "Error: please enter a valid email." If a chart distinguishes data by color, also label the segments or use patterns. The test is to imagine the page in grayscale: if any information disappears, that information was carried by color alone and needs a text or shape backup.

Make forms understandable and forgiving

Forms are where accessibility problems become expensive, because a form a user cannot complete is a customer you cannot serve. Every field needs a visible, programmatically associated label, not a placeholder that vanishes the moment someone starts typing. Tell people exactly what you need, and where format matters, say so up front rather than making them guess.

Error handling is the other half. When something goes wrong, identify the specific field and explain how to fix it in plain words, "Your ZIP code should be five digits," not a generic "invalid entry" with no indication of which field failed. Errors should be announced to assistive technology, associated with their field, and easy to find, so that a screen reader user knows what happened and where without hunting through the page.

Handle text sizing and readability correctly

This is the area the typical checklist gets subtly wrong, so it is worth stating precisely. WCAG does not mandate a specific minimum font size in pixels. What WCAG 2.1 AA actually requires, under success criterion 1.4.4, is that text can be resized up to 200 percent without loss of content or functionality, and under 1.4.10 that content reflows to a single column without horizontal scrolling at that zoom. The practical consequence is a build decision: use relative units like rem and em for text rather than fixed pixels, so that when a user zooms, your layout scales instead of breaking.

Sixteen pixels for body text is a sensible, widely used baseline for readability, and we recommend it, but treat it as a starting point rather than a legal line, because the real requirement is scalability, not a magic number. Beyond size, favor generous line spacing, avoid long passages set in all capitals since they are harder to read, and use bold or italics for genuine emphasis rather than decoration. Readable typography is not a WCAG checkbox on its own, but it is what makes the difference between technically passing and actually comfortable to use.

A fast ADA checklist for developers

If you are a developer who wants to move quickly, here is a compressed pass you can run on a page in one sitting. Work through it in order, because the early steps surface the highest-impact issues.

1. Tab through the entire page with no mouse and confirm you can reach and operate everything, with a visible focus indicator at every stop.
2. Run an automated scan to catch the high-volume, machine-detectable issues at once (missing alt text, low contrast, missing form labels and invalid ARIA), so you are not hunting for them by hand.
3. Check heading order by viewing the document outline and confirming it makes sense with no skipped levels.
4. Zoom the browser to 200 percent and confirm nothing is cut off, overlapping, or requires horizontal scrolling.
5. Inspect your custom widgets (menus, modals, carousels and tabs) with a screen reader, since these are where automated tools and quick checks miss the most.
6. Review color: grayscale the page in your head and confirm no meaning is lost, then verify text contrast hits 4.5:1.

For step 2, you can scan your site with Sitejar for free, which lists each issue mapped to the WCAG criterion it fails and, where possible, a source-level fix to hand your developers or your AI assistant.

That six-step pass will not certify you, because no quick check can, but it reliably surfaces the majority of the issues that generate complaints, and it tells you honestly whether you have a small cleanup or a bigger project on your hands. The important habit is that this is not one-and-done: run the scan step on a schedule, because every new page or design change can reintroduce issues you already fixed.

Build a testing process, not a one-time audit

Compliance is a state you maintain, not a milestone you pass once. Every new page, campaign, or feature is a chance to reintroduce a barrier, so the durable approach is to bake checking into how you ship. Automated scanning is the right first layer because it catches the repetitive, machine-detectable failures across your whole site cheaply and consistently, but be clear-eyed about its limits: automated tools reliably catch only a portion of all WCAG issues, which is why manual testing with a keyboard and a screen reader on your key flows is not optional.

Combining the two is the standard. Let the automated scan handle volume and regressions, and reserve human testing for judgment calls and the complex interactive components that machines struggle to evaluate. Where you can, involve people with disabilities in testing, because lived experience surfaces problems no checklist anticipates. And make accessibility part of your existing process rather than a separate phase: check alt text when images go live, keyboard operability when interactive features ship, and contrast when brand colors change, so accessibility is maintained continuously instead of rescued in a panic before a deadline. For the difference between testing and a formal audit, see what an accessibility audit proves.

Common questions about ADA website compliance

Because the rules are widely misunderstood, here are direct answers to the questions we hear most. These are general explanations, not legal advice for your specific situation.

How do I know if my website is ADA compliant?

You combine automated and manual testing, because neither alone is enough. Run an automated accessibility scan to flag machine-detectable issues, then test keyboard navigation, try your site with a screen reader, and check color contrast by hand. No single tool catches everything, so the honest answer to "are we compliant" always comes from a combination of a scan plus human testing of your important flows, and ideally a specialist audit for a large or complex site. That is also why a Lighthouse score of 100 isn't compliance.

What is the difference between ADA and WCAG compliance?

The ADA is the law; WCAG is the technical standard that shows you how to satisfy it. Most ADA lawsuits and settlements reference WCAG 2.1 Level AA as the benchmark, so in practice, meeting WCAG 2.1 AA is how you meet your ADA obligation. You do not choose between them: you follow WCAG to comply with the ADA.

Can I use an accessibility overlay instead of fixing my site?

No, and this is a trap worth avoiding. Overlays are JavaScript widgets that claim to fix accessibility automatically at page load, but they address only a fraction of issues, they frequently interfere with the very screen readers they claim to help, and courts have not accepted them as a compliance shield. We covered the evidence in detail in our analysis of whether accessibility overlays protect you from lawsuits and our full case against overlays. The durable fix is correcting the accessibility issues in your source code, which is the only approach that actually helps disabled users and holds up under scrutiny.

Who is responsible for ADA compliance on my website?

If your website serves the public, you are, meaning the business or organization that owns it. Developers and agencies share responsibility by building accessibility in from the start rather than bolting it on later, and everyone who touches the site, designers, content authors, and engineers, plays a part in keeping it accessible. Responsibility does not transfer to a vendor or a tool; it stays with the organization serving the public.

The bottom line

ADA website compliance in 2026 means meeting WCAG 2.1 Level AA, and this checklist is what that standard asks for in practice: text alternatives for images and media, keyboard operability with a visible focus indicator, logical headings and semantic HTML, 4.5:1 color contrast with no reliance on color alone, understandable and forgiving forms, and text that scales to 200 percent without breaking. Run the six-step developer pass to see where you stand, starting with a keyboard walk-through and an automated scan, then layer in screen reader testing for your key flows and make the whole thing a repeating habit rather than a one-time audit. You do not have to be perfect on day one. Start with the highest-impact issues, fix them at the source, and keep testing as you ship. An accessible site is not only the compliant choice, it is the one that actually includes the people who want to use what you have built.

Sources

W3C, WCAG Standards and Guidelines Overview

U.S. General Services Administration, Section508.gov Fonts and Typography

This guide is educational and reflects Sitejar's point of view. It is not legal advice. For your specific situation, consult a qualified professional.