How to Check If Your Website Is ADA Compliant (Self-Service Guide)
A practical first-pass walkthrough — automated scan, keyboard test, screen reader basics, contrast, alt text, and form labels
On this page
On this page
What this guide is — and isn't
If you run a website and want to know where you stand on accessibility right now, without hiring anyone or waiting weeks for a report, this guide walks you through a practical self-check you can do this afternoon. It uses one free automated tool plus five manual checks that any non-technical site owner can perform with nothing more than a keyboard, a browser, and about an hour of focused attention.
Here is the honest framing up front, because this site exists in part to correct the "instant compliance" myths that overlay-widget vendors sell: this self-check is a first pass, not a compliance determination. Automated tools plus a bit of manual poking around will surface real, fixable problems — but they cannot replace a trained professional using multiple screen readers across every critical user flow on your site. If you take one thing from this guide, take that.
With that framing in place, here's how to actually run the check.
Step 1: Run the free automated scan
Start with our Compliance Checker tool — a free, no-login scan that fetches your home page and tests it against the WebAIM Big Six failure types, which together account for the large majority of detected accessibility errors across the web. It checks for missing alt text, missing form labels, empty links, empty buttons, missing document language, and likely low-contrast text, and groups the results by WCAG success criterion.
This step takes about ten seconds and gives you a concrete, prioritized starting list. It is not exhaustive — automated tools generally catch only a minority of total WCAG failures, because they cannot evaluate things like whether your screen reader output actually makes sense, or whether your keyboard focus order matches your visual layout. Treat the scan output as your triage list, not your final report card.
While you're there, run your key template pages too (not just the homepage) — your product pages, contact form, and checkout flow are usually where the highest-impact issues live, and where lawsuits and demand letters most often target.
Step 2: Test keyboard navigation
Unplug your mouse — or just resist the urge to touch it — and try to use your site with only the Tab, Shift+Tab, Enter, and Space keys.
What to check as you go:
- Can you reach every interactive element? Tab through the entire page. Every link, button, form field, and custom widget (dropdown menus, modals, carousels) should be reachable in a logical order.
- Can you see where you are? Every focused element needs a visible focus indicator — a border, outline, or highlight that clearly shows which element currently has keyboard focus. If you tab through your page and lose track of where you are, that's a real barrier for keyboard-only users, including many people with motor disabilities who cannot use a mouse at all.
- Does the tab order make sense? Focus should generally move in the same order a sighted user would read the page — left to right, top to bottom (for left-to-right languages). If focus jumps erratically around the page, that's disorienting for anyone navigating by keyboard.
- Can you escape everything you enter? Open any modal, dropdown, or menu with the keyboard, then confirm you can close it again (usually with Escape) and that focus returns somewhere sensible afterward. A modal you can open but not close with the keyboard is called a "focus trap," and it is one of the more serious barriers you can find.
- Can you complete a real task? Try to actually fill out your contact form, or add something to a cart, using only the keyboard. Completing a real task surfaces problems that just tabbing around does not.
This single check — five to ten minutes on your most important pages — often surfaces some of the most serious barriers a site can have, because keyboard operability underlies WCAG's entire "Operable" principle.
Step 3: Try a screen reader
This is the step non-technical site owners skip most often, and it's also the most revealing. You don't need to buy anything or become an expert — you need to spend 20-30 minutes hearing your own site the way a blind or low-vision visitor might experience it.
On Windows: Download NVDA, a free, open-source screen reader from NV Access. Turn it on, open your site in a browser, and try navigating with it active. NVDA reads aloud whatever has focus and lets you move through headings, links, and form fields using specific keyboard shortcuts.
On Mac or iPhone: VoiceOver is already built in. On Mac, enable it in System Settings under Accessibility; on iPhone, under Settings > Accessibility > VoiceOver. It takes a few minutes to learn the basic gesture/keyboard set, but Apple's own accessibility documentation walks through the basics.
What to listen for:
- Do images make sense, or does it just say "image" or read a filename? That's a missing or unhelpful alt text problem.
- Do buttons and links announce what they do? An icon-only button that just announces "button" with no label is a dead end for a screen reader user.
- Do form fields announce their purpose? A field that just says "edit text" with no indication of what to type is unusable.
- Does the reading order make sense? If the screen reader jumps around in a way that doesn't match the visual layout, that's a structural problem.
You will likely find this uncomfortable at first — that's normal, and it's exactly the point. If you can't figure out how to complete your own contact form by ear, imagine being a daily screen reader user encountering that same barrier for the first time.
Step 4: Check color contrast
Low-contrast text is consistently one of the single most common accessibility failures found across the web — more common than any other single issue. It's also one of the easiest to check and fix.
Use our free Color Contrast Checker to test your text and background color combinations against WCAG's minimum thresholds: 4.5:1 for normal text, 3:1 for large text (18pt+ or 14pt+ bold), and 3:1 for UI components and graphical objects.
Common places low contrast hides:
- Light gray body text on a white background
- Placeholder text inside form fields
- Text over background images or gradients
- "Muted" secondary text (captions, metadata, footer links)
If you use a defined set of brand colors, run each text/background combination through the checker once and fix any failing pairs at the design-token level rather than page by page — that way the fix propagates everywhere the token is used.
Step 5: Check that images have alt text
Missing alternative text is one of the most common — and most consequential — accessibility failures, because it means a screen reader user gets no information at all about what an image conveys.
Go through your key pages and ask, for every image:
- Does this image convey information? If yes, it needs a text alternative (an
altattribute) that conveys the same information a sighted user would get. - Is this image purely decorative? If it adds no informational value (a background flourish, for example), it should have an empty
alt=""so screen readers skip it entirely rather than announcing something meaningless like "decorative-border-2.png." - Does the alt text describe purpose, not just appearance? For a product photo, describe what's shown. For a linked logo, describe where the link goes ("Acme Inc. homepage"), not just "logo."
Our free Heading Validator tool can also help you check heading structure while you're auditing content, which pairs well with an alt-text pass since both are usually content-level fixes rather than code changes.
Step 6: Check that forms have labels
Missing form labels are consistently one of the highest-prevalence WCAG failures found across the web, and they're one of the most damaging — an unlabeled field is often a hard blocker for a screen reader user trying to complete a purchase, sign up, or contact you.
For every form on your site, check:
- Does every input have a visible, programmatically associated label? A placeholder ("Enter your email") is not a substitute for a real label — placeholders disappear once you start typing and are not reliably announced by all screen readers.
- Are required fields marked in a way that's announced, not just shown visually with an asterisk?
- Are error messages associated with the field they describe? If validation fails, the error needs to be connected to its field programmatically, not just displayed nearby visually.
Our WCAG Quick Reference tool is a good place to look up the exact success criteria (1.3.1, 3.3.2, 4.1.2) if you want to hand this off to a developer with specific citations.
Putting it together: what your first pass tells you
After these six steps, you should have a concrete, prioritized list: what the automated scanner flagged, what broke during your keyboard walkthrough, what confused you (or was silent) during your screen reader pass, which color combinations failed contrast, which images lack alt text, and which forms lack labels. That is real, actionable information, and fixing it will measurably improve your site.
What it does not tell you: whether every complex interactive component (custom dropdowns, date pickers, carousels, single-page-app route changes) correctly manages ARIA states and focus; whether your site works with JAWS as well as it does with NVDA or VoiceOver; or whether a trained tester working through every critical user flow would find issues your first pass missed. Those require the depth of a real audit — see our ADA audit process guide for what a professional engagement actually covers, and our full 7-step remediation guide for what comes after you have a complete list of findings.
If your self-check turns up a manageable number of straightforward issues (alt text, labels, contrast), you may be able to fix those in-house. If it turns up structural problems — broken keyboard traps, disorienting screen reader behavior, complex custom components — that's a signal to bring in someone who does this professionally rather than guessing at a fix.
Ready to take the next step? Grow Wild Agency offers a free preliminary WCAG 2.1 AA scan of your website that goes beyond a single automated pass, so you can see exactly where a professional review would pick up where this self-check leaves off.
Frequently Asked Questions
- Can I make my website fully ADA compliant just by following this checklist?
- No, and we want to be direct about that. This self-check will surface the most common, highest-prevalence issues and give you a realistic sense of where your site stands, but it does not replace comprehensive manual testing by a trained accessibility professional using multiple screen readers, full keyboard-only walkthroughs of every critical flow, and expert review of ARIA usage and focus management. Treat this as your first pass, not your final answer.
- How long does a self-check take?
- The automated scan takes seconds. A basic keyboard walkthrough of your homepage and one or two key pages (like a contact form or checkout flow) takes 15-30 minutes. A first screen reader pass adds another 30-60 minutes if you've never used one before. Budget an afternoon for a genuinely useful first pass across your most important pages.
- What's the difference between this self-check and a professional audit?
- A professional audit tests every critical user flow with multiple screen readers (NVDA, JAWS, VoiceOver), performs full keyboard-only walkthroughs, evaluates ARIA usage and focus management in depth, checks reflow at 200% zoom, simulates color blindness, and produces a prioritized remediation roadmap with WCAG criterion IDs and severity ratings. See our guide to the full [ADA audit process](/guides/ada-audit-process) for what that involves.
- Should I install an accessibility overlay widget instead of doing all this manually?
- No. Overlay widgets that claim to fix compliance automatically do not address the underlying HTML, CSS, and code issues this self-check is designed to help you find, and they have been the subject of FTC enforcement action for misleading compliance claims. See our guide on [why overlay widgets don't work](/guides/overlay-widgets-warning) for the full picture.
- What should I do after running this self-check?
- Fix what you can fix yourself — missing alt text, unlabeled form fields, and low-contrast text are usually straightforward content or CSS changes. For anything structural (broken keyboard traps, missing focus indicators, complex interactive widgets), bring in a developer or accessibility specialist. And regardless of what you find, if your site is public-facing and important to your business, plan for a full professional audit rather than treating the self-check as the finish line.