Your website is ADA compliant if people with disabilities can use it, and the legal shorthand for that is conformance with the Web Content Accessibility Guidelines (WCAG) at Level AA. Nobody can answer the question from a screenshot, and no scanner can answer it alone. But you can find out in about half an hour whether your site is broadly in good shape or has the kind of failures that draw demand letters, using nothing more than a keyboard, a free browser tool and the screen reader already built into your phone or Mac. This guide walks through ten checks in that order. If you fail more than two or three, read the section at the end on what to do next.
A note on what “compliant” means before you start. The ADA does not contain a list of web rules. Courts, Department of Justice settlements and the 2024 Title II regulation all measure websites against WCAG 2.1 Level AA, and WCAG 2.2 AA (the current version) includes everything in 2.1. Our ADA compliance website checklist lists the requirements in full. This article is the quick test, not the full standard.
Before you start: what you need
- A laptop with Chrome, Edge or Firefox.
- The free WAVE browser extension from WebAIM.
- A screen reader you already own: VoiceOver on a Mac (Cmd+F5) or iPhone (Settings, Accessibility, VoiceOver), Narrator on Windows (Win+Ctrl+Enter), or the free NVDA on Windows.
- Four pages to test: the homepage, your main service or product page, the contact page with its form, and one blog post or content page. Templates are where the code lives, so four representative pages tell you most of what a full audit would.
Check 1: put the mouse away and use only the keyboard
Open the homepage, press Tab, and keep pressing it. You should be able to reach every link, button, menu item and form field on the page, in an order that matches the visual layout, and you should always be able to see which element is focused. Press Enter to open links and Space to press buttons. Open the main navigation, open any dropdown menus, and try the search box.
Pass: everything is reachable, a visible focus ring or highlight follows you, and you can get back out of every menu and modal with Tab, Shift+Tab or Escape.
Fail: focus disappears (usually because a theme set outline: none), a dropdown only opens on hover, a carousel or modal traps you, or you can see the focus jumping to an off-screen element. This is the single most common serious failure, and it fails WCAG 2.1.1, 2.1.2, 2.4.3 and 2.4.7 at once. (Checklist reference.)
Check 2: press Tab once on a fresh page load
Reload the homepage and press Tab exactly once. On a compliant site the first focusable element is a “Skip to content” link that appears when focused and jumps past the header and navigation. Without it, a keyboard or screen reader user has to tab through your entire menu on every single page.
Pass: a skip link appears and works. Fail: focus lands on the logo or the first menu item. This is WCAG 2.4.1, and it is a five-minute fix for a developer.
Check 3: fill out your contact form with a screen reader
Turn on VoiceOver or Narrator, close your eyes if you can bear to, and try to complete your contact form. Listen for whether each field is announced with a meaningful name (“Email address, edit text”) or just “edit text.” Submit the form empty and listen for whether the error is announced and tells you which field is wrong.
Pass: every field is named, required fields are identified, and errors are read out with instructions. Fail: fields are announced as “edit text” with no label (placeholder text is not a label), or the error is a red outline that the screen reader never mentions. That fails 1.3.1, 3.3.1 and 3.3.2, and it means your site cannot take a lead from a blind visitor. If you do only one screen reader test, make it this one.
Check 4: run WAVE on the four pages
Click the WAVE icon on each page. Red icons are errors; the ones that matter most are missing alternative text, empty links, empty buttons, missing form labels and very low contrast. Yellow alerts are worth reading but are often judgment calls.
Pass: zero red errors on all four pages. Fail: any red error. A page with a dozen missing alt attributes is the pattern that automated lawsuit-scanning tools look for, because it is the easiest failure to prove.
Keep this in perspective: WAVE and tools like it detect roughly a third of WCAG failures. A clean WAVE report is necessary, not sufficient, which is why the other nine checks exist.
Check 5: check your brand colors for contrast
Open the WebAIM Contrast Checker and enter your body text color against your background, your link color against the background, your button text against the button color, and any text that sits on a photo or a colored band. Normal text needs a 4.5:1 ratio; large text (18 point, or 14 point bold) and interface elements such as icons and field borders need 3:1.
Pass: every pairing meets its threshold. Fail: light gray body text, thin white text over a hero photo, and pale placeholder text are the usual offenders. This is WCAG 1.4.3 and 1.4.11, and it is often a design-system fix rather than a page-by-page one.
Check 6: read the heading outline
In WAVE, click the “Structure” tab, or install the free HeadingsMap extension. You are looking at the page the way a screen reader user navigates it: by jumping from heading to heading.
Pass: one H1 that says what the page is, H2s for each section, H3s nested under the H2 they belong to, no skipped levels. Fail: multiple H1s, an H4 under an H2 because it looked the right size, headings that are really bold paragraphs, or sections with no heading at all. This is 1.3.1 and 2.4.6. Our semantic HTML cheat sheet shows what the markup should look like.
Check 7: zoom to 200 percent, then squeeze to 320 pixels
Press Ctrl or Cmd and plus until the browser reads 200 percent. Then, in a normal window, drag the browser as narrow as it will go (or use the device toolbar in DevTools set to 320 pixels wide).
Pass: at 200 percent all text is still readable and nothing overlaps or is cut off; at 320 pixels the page reflows into a single column with no horizontal scrolling and no clipped content. Fail: text disappears behind fixed-height boxes, columns overlap, or you have to scroll sideways to read a sentence. This is 1.4.4 and 1.4.10, and it is where page builders fail most often.
Check 8: play every video and listen for autoplay
Find every video and audio element on the four pages. Play each one and turn on captions. Then reload the homepage with sound on.
Pass: every recorded video has accurate captions (auto-generated captions count only if someone has corrected them), audio content has a transcript, and nothing plays sound automatically. Fail: uncaptioned video, a background video with sound, or a hero video with no pause control. This is 1.2.2, 1.4.2 and 2.2.2.
Check 9: hover, tap and drag
On a phone, try the site with one finger. Can every menu be opened with a tap, not just a hover? Are buttons and links big enough to hit (WCAG 2.2 sets a minimum of 24 by 24 pixels, and 44 is a better target)? Is there anything that can only be done by dragging, such as a slider or a sortable list, with no button alternative? Does a tooltip or a menu vanish the moment your finger moves?
Pass: everything works with taps, targets are comfortably sized, and dragging always has an alternative. Fail: hover-only menus, tiny icon buttons packed together, drag-only controls. This covers 1.4.13, 2.5.7 and 2.5.8, three of the criteria added or tightened in WCAG 2.2, which is why older sites often fail them.
Check 10: look for the things that are not your website
Three categories cause a disproportionate share of complaints and are easy to forget because they were not built by whoever built the site.
- PDFs. Download two and open them in Acrobat or Preview. Can you select the text? Are there headings and a reading order? A scanned menu or an untagged brochure is inaccessible and is a very common lawsuit exhibit.
- Third-party embeds. Booking widgets, chat bubbles, payment forms, maps and social feeds. Run checks 1 and 3 on them. If a vendor’s widget fails, you are still the one being sued.
- Accessibility overlays. If your site shows a floating accessibility icon from an overlay vendor, that is not evidence of compliance. Overlays do not fix the code, they frequently interfere with real assistive technology, and sites running them are sued regularly. Treat the presence of one as a reason to run all ten checks, not a reason to skip them.
How to read your results
- Zero or one failure: you are in good shape. Fix the failure, keep the checklist in your publishing process, and re-run the ten checks quarterly and after any redesign.
- Two to four failures, mostly content (alt text, captions, contrast on a few images, PDFs): fixable in-house in days. Use the checklist.
- Failures in checks 1, 2, 3 or 7: these live in the theme. A developer needs to fix focus management, keyboard support, form markup and layout. On a hand-coded site this is a scoped remediation project. On a page-builder site the honest answer is often that a rebuild costs less than patching, because every component was built without accessibility and every fix fights the builder.
Either way, the next step is a proper audit that lists every failing success criterion with its location and fix, which is what a compliance officer or an attorney will ask to see. That is what our ADA compliance services deliver, and it is how The Trust Company of North Carolina went from a template site to independently verified WCAG AA conformance.
What these checks do not tell you
Thirty minutes finds the failures that matter most, but it is not conformance. Full WCAG 2.2 AA has 55 success criteria at Levels A and AA, and several of them (timing, status messages, consistent help, accessible authentication, error prevention on financial forms) only show up when you test specific flows such as checkout or login. A true audit tests every template and every process with a keyboard, at least one screen reader, and the criteria list in hand, and it produces a report you could hand to a lawyer. If your business is in a regulated industry, has more than a few thousand visitors a month, or has already received a demand letter, skip the self-test and go straight to that.
Frequently asked questions
Is there an official ADA compliance checker for websites?
No. The Department of Justice does not certify websites or endorse a tool. The recognized standard is WCAG 2.1 AA (2.2 AA going forward), and conformance is established by testing against it, ideally with independent verification. Any tool or badge that claims to certify ADA compliance is a marketing claim, not a legal one.
My site passed an automated scan. Am I compliant?
Not necessarily. Automated scanners detect the failures that can be identified from code alone, roughly a third of the standard. They cannot tell whether alt text is meaningful, whether a custom menu works with a screen reader, whether focus order makes sense, or whether an error message helps the user. A clean scan plus the keyboard and screen reader checks above is a reasonable first pass; a full audit is what conformance means.
Does my small business website really have to be ADA compliant?
If you are a business open to the public, courts have consistently held that your website is covered under Title III of the ADA, and there is no small-business exemption in the case law. More than 5,000 digital accessibility lawsuits were filed in 2025, many against small and mid-sized businesses. State and local governments and federally funded healthcare providers have written deadlines in 2027 and 2028. Our ADA compliance glossary entry covers the legal background.
How often should I run these checks?
After any redesign or theme change, after adding any new plugin or embed, and otherwise quarterly. Content checks (alt text, captions, headings, contrast on new images) belong in your publishing process for every new page.
Get a straight answer on where your site stands
If the ten checks turned up problems, or you would rather have someone else run them properly, book a discovery call. We will audit your site against WCAG 2.2 AA, tell you which failures are content and which are code, and give you an honest answer on whether to fix or rebuild.
or call 919-200-0201