How to Make Website ADA Compliant in 2026 (Step-by-Step Guide)

If you want to know how to make website ADA compliant, the timing matters - and the stakes have never been higher. ADA website accessibility lawsuits set a record last year - more than 5,000 federal and state cases filed, up 37% year over year. Small businesses under $25 million in revenue made up nearly 67% of targets. This isn't a problem that only affects large companies. It affects yours.

Making your website ADA compliant sounds technical and overwhelming. It doesn't have to be. This guide walks you through exactly what ADA compliance means for websites, which standard you actually need to meet, a practical step-by-step checklist, and how to test your site without spending a fortune.

We also have a companion post on ADA website compliance for small businesses if you want the legal and business context first. This guide is the practical how-to.

What "ADA compliant" actually means for a website

The Americans with Disabilities Act (ADA) was passed in 1990, long before the web existed. It doesn't mention websites directly. What's happened over the past decade is that courts have consistently ruled that websites are "places of public accommodation" under Title III of the ADA - meaning they must be accessible to people with disabilities.

The technical standard courts and regulators use is the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA. That's the target you're aiming for. WCAG 2.1 AA was the previous standard and is still referenced in some regulations, but WCAG 2.2 is backward-compatible - if you meet 2.2, you meet 2.1 too.

Level AA is the middle tier. Level A is the minimum (catching only the most obvious barriers). Level AAA is the top tier and genuinely difficult to achieve on most sites. AA is where the legal standard sits, and it's achievable for most small and mid-size businesses.

How to make your website ADA compliant: the step-by-step checklist

WCAG 2.2 organizes accessibility into four principles: Perceivable, Operable, Understandable, and Compatible. Here's what each one means in plain terms, with specific actions you can take.

Perceivable: can users see and hear your content?

Add alt text to every meaningful image. Alt text is the text description that screen readers speak aloud when a user with visual impairments encounters an image. Every image that carries meaning needs a description. If an image is purely decorative (a background pattern, a separator line), use an empty alt attribute: alt="". This tells screen readers to skip it.

Bad alt text: "image1.jpg" or "photo"
Good alt text: "Two team members reviewing a marketing report on a laptop"

Check your color contrast. WCAG 2.2 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt+ or 14pt+ bold). You can test this with the WebAIM Contrast Checker (free, just Google it). Many sites fail here because designers chose aesthetically pleasing muted colors that simply don't have enough contrast for people with low vision.

Caption your videos. Any prerecorded video with audio needs captions. Live video also needs captions at AA level. Auto-generated captions from YouTube or Vimeo are a start but usually need editing - accuracy matters.

Don't use color as the only signal. If your contact form shows validation errors only by turning the field border red, you're relying solely on color. Add an icon or error text alongside the color change.

Make text resizable. Users should be able to zoom to 200% without content disappearing or overlapping. Test this by pressing Ctrl/Cmd + "+" in your browser a few times. If your layout breaks, you have a problem.

Operable: can users use your site without a mouse?

Test keyboard navigation. Open your website and put your mouse aside. Use Tab to move between interactive elements (links, buttons, form fields) and Enter/Space to activate them. Every single interactive element on your page must be reachable and usable this way. If you hit a dead end where Tab stops working, that's a keyboard trap - a Level A failure.

Make focus visible. As you Tab through the page, there should be a clearly visible indicator on whichever element currently has focus. This is often a blue outline or similar visual cue. Many designers remove this outline (using CSS outline: none) because it looks cluttered, but doing so breaks accessibility for keyboard users. WCAG 2.2 actually strengthened this requirement with criterion 2.4.11 (Focus Not Obscured) - the focused element can't be hidden behind sticky headers or pop-up banners.

Add a "Skip to main content" link. This is a link at the very top of the page that lets keyboard users jump past your navigation and go straight to the main content. Without it, someone using only a keyboard has to Tab through every navigation link on every page load. Here's basic code:

<a href="#main-content" class="skip-link">Skip to main content</a>

Write descriptive link text. "Click here" and "read more" are useless to screen reader users who often jump from link to link. The link text itself should describe the destination: "Read our guide on social media content calendars" is clear; "click here" is not.

Give every page a unique title. The <title> tag in your page's head should uniquely describe each page. A screen reader announces the page title when a user lands on it. "Home - Aslan Agency" and "Blog - Aslan Agency" are fine. A dozen pages all titled "Page" are not.

Understandable: can users comprehend your content?

Set the language attribute. Your HTML should include <html lang="en"> (or whatever language your site is in). Screen readers use this to apply the correct pronunciation rules. It takes 30 seconds and is an easy win.

Label every form field. Every input field needs a programmatically associated label - not just placeholder text. Placeholder text disappears when the user starts typing and is often low-contrast. Use proper <label> elements linked to fields with matching for and id attributes.

Write clear error messages. When a form submission fails, don't just highlight the field in red. Tell users specifically what went wrong: "Phone number must include area code" beats "Invalid input."

Keep navigation consistent. Your main menu should appear in the same location and same order across all pages. Users with cognitive disabilities rely on this consistency.

Compatible: does your site work with assistive technologies?

Use semantic HTML. HTML has built-in elements for a reason: <nav> for navigation, <main> for main content, <header> and <footer>, <h1> through <h6> for headings in order, <button> for buttons. When you use a <div> styled to look like a button, screen readers don't know it's interactive. Use the real elements.

Validate your HTML. Broken HTML can confuse screen readers. Run your pages through the W3C HTML Validator (free at validator.w3.org). Fix any errors it finds, especially missing closing tags, duplicate IDs, and malformed attributes.

Use ARIA carefully. ARIA (Accessible Rich Internet Applications) attributes let you add accessibility information to custom widgets like dropdown menus, modals, and carousels. But ARIA used incorrectly can make things worse. The rule of thumb: use native HTML elements first. Only reach for ARIA when native elements can't do the job.

Tools to test your website for ADA compliance

No automated tool catches every accessibility issue - human testing is still essential, especially for keyboard navigation and screen reader use. But automated tools are the right starting point because they're fast and free.

WAVE (wave.webaim.org) - Install the browser extension for Chrome, Firefox, or Edge. It overlays visual markers on your page showing errors, alerts, and structural features. WAVE is particularly good for learning because it shows you what the issue is and where it is at the same time. Start here.

axe DevTools - A browser extension from Deque Systems. It adds an "axe" tab inside Chrome DevTools. Known for accuracy and minimal false positives. The free version catches around 50% of WCAG issues. More technical than WAVE, better for developers.

Google Lighthouse - Built into Chrome DevTools (open DevTools, click the "Lighthouse" tab, run an audit). Gives you an accessibility score from 0-100. Good for a quick benchmark, but the score isn't directly correlated to legal compliance - you can score 95 and still have critical issues Lighthouse doesn't test.

Manual testing with a screen reader - Download NVDA (free, Windows) or use VoiceOver (built into Mac/iOS). Move through your site using only the keyboard and listen to what the screen reader says. This is uncomfortable and awkward the first time. That discomfort is information. If you can't get through your own checkout or contact form without a mouse, you have real problems to fix.

For enterprise or high-risk sites, paid tools like Deque's axe Platform, Pope Tech, or Siteimprove provide continuous monitoring and detailed reporting. They're priced for larger organizations but worth it if you're in an industry with heavy lawsuit activity.

What it costs to get compliant

Costs vary widely depending on the state of your site. A rough breakdown:

Professional audit: $3,000 to $5,000+ depending on site size. This tells you what's broken before you start fixing anything.

Remediation for a typical small business site: $3,000 to $15,000. Sites with lots of custom JavaScript, complex forms, or video content cost more.

New accessible build: If the site has deep structural problems, a rebuild may be cheaper than remediation long-term. Expect $10,000 to $60,000+.

Ongoing maintenance: $500 to $1,500 per month if you want continuous monitoring. New content can introduce new accessibility failures, so this is worth it for active sites.

Compare those numbers to the cost of a lawsuit. Average ADA web accessibility settlements run between $5,000 and $50,000. Add your legal fees (another $50,000 or more). And there are real DOJ penalties too: up to $75,000 for a first violation, $150,000 for repeat violations. Getting compliant proactively is almost always the cheaper path.

WCAG 2.2's new requirements you might miss

If you've done any accessibility work in the past few years, you might think you're already covered. WCAG 2.2 added new AA-level requirements worth double-checking:

Focus Not Obscured (2.4.11): When a user Tabs to a focusable element, that element can't be fully hidden by a sticky header, cookie banner, or chat widget overlay. This catches a lot of modern sites that use persistent sticky navbars.

Dragging Movements (2.5.7): If your site has any drag-and-drop functionality (reordering items, sliders, carousels controlled by drag), you need to offer a single-click alternative for users who can't perform drag gestures.

Target Size - Minimum (2.5.8): Interactive elements need a minimum target size of 24x24 CSS pixels. Tiny icon buttons, close buttons on modals, and packed navigation links often fail this. Mobile designs are especially prone to it.

Accessible Authentication (3.3.8): Login processes can't force users to solve cognitive tests (like character puzzles or memory-based challenges) without providing an accessible alternative. This affects sites with custom CAPTCHAs.

How to prioritize your fixes

If you run an audit and get a long list of issues, don't panic. Prioritize by impact and risk:

Fix Level A failures first. These are the most basic barriers and the ones most likely to come up in a lawsuit.

Then fix issues on high-traffic pages. Your homepage, product pages, and checkout flow carry the most risk and the most potential benefit to users.

Focus on form accessibility early. Forms are where lawsuits concentrate. A contact form someone can't submit, a checkout a screen reader user can't complete - these are the violations that generate complaints and litigation.

Document your remediation work. If you do get contacted by a plaintiff's attorney, showing that you had an active compliance program in place and were making documented progress helps your legal position.

One practical note: if you're on WordPress, there are accessibility-focused plugins that help, but no plugin fully handles compliance for you. The WP Accessibility plugin (free) can help with skip links and some common issues. Your theme matters too - some themes are built with accessibility in mind from the start.

For SEO strategy, check out our guide on how to create a brand voice for your business - a consistent voice helps with both user experience and search visibility, and those are increasingly tied together.