How to Make Your Website ADA Compliant?

Web accessibility lawsuits hit a record high in 2026, with over 4,000 federal ADA lawsuits filed against businesses with non-compliant websites. The average settlement? Between $5,000 and $25,000 for a first offense. For larger companies, settlements have reached six figures. And this doesn’t even count the demand letters that never make it to court.

I’ve helped multiple clients fix accessibility issues on their WordPress sites, and the pattern is always the same: they didn’t know their site was non-compliant until they got a letter from a lawyer. Don’t wait for that to happen. Making your website ADA compliant protects you legally, expands your audience (about 26% of American adults have a disability), and often improves your SEO and overall user experience in the process.

What Is ADA Compliance for Websites?

The Americans with Disabilities Act (ADA), passed in 1990, prohibits discrimination against people with disabilities in all areas of public life. While the original law focused on physical spaces, courts have consistently ruled that websites are “places of public accommodation” under Title III, meaning they must be accessible to people with disabilities.

There’s an important distinction to understand: ADA itself doesn’t specify technical standards for websites. Instead, the Department of Justice has pointed to the Web Content Accessibility Guidelines (WCAG) as the standard. Specifically, WCAG 2.1 Level AA is what most courts reference. WCAG 2.2, released in October 2023, adds new criteria and is becoming the benchmark for 2026.

Don’t confuse ADA compliance with Section 508 compliance. Section 508 applies specifically to federal agencies and their contractors. ADA applies to private businesses. If you run a website and your business falls under ADA Title I (15+ employees) or Title III (places of public accommodation like stores, hotels, restaurants), your website needs to be accessible.

WCAG 2.2: What Changed and What You Need to Know

WCAG 2.2 introduced nine new success criteria over WCAG 2.1. These focus heavily on improving experiences for users with cognitive disabilities, low vision, and motor impairments. Here are the ones that matter most for your website:

• Focus Not Obscured (AA): When an element receives keyboard focus, it can’t be entirely hidden by other content like sticky headers or cookie banners. This is a huge issue on many WordPress sites with fixed navigation bars
• Dragging Movements (A): Any functionality that uses dragging (sliders, drag-and-drop) must have a non-dragging alternative. A click or tap option must exist
• Target Size (AA): Interactive elements (buttons, links, form controls) need to be at least 24×24 CSS pixels, with some exceptions for inline text links
• Consistent Help (A): If you offer help mechanisms (contact info, chat, FAQ), they must appear in the same location across pages
• Redundant Entry (A): Don’t ask users to re-enter information they’ve already provided in the same process (like re-typing an address in a checkout flow)
• Accessible Authentication (A): Login processes can’t require cognitive function tests (like puzzles) without providing an alternative method

Who Needs to Be ADA Compliant?

If you’re reading this and wondering whether ADA applies to you, here’s a practical breakdown:

Definitely need compliance: Any business with 15+ employees (ADA Title I), any business open to the public like stores, restaurants, hotels, banks, hospitals (ADA Title III), government agencies (Section 508), educational institutions receiving federal funding, and e-commerce businesses.

Should pursue compliance: Every website, honestly. Even if you’re a small business not technically covered by ADA, you’re leaving money on the table by excluding 61 million Americans with disabilities. Plus, accessibility overlaps heavily with good UX and SEO best practices. Proper headings, alt text, semantic HTML, and fast load times all help both accessibility and search rankings.

The Legal Landscape in 2026

ADA web accessibility lawsuits have exploded. In 2023 alone, over 4,600 lawsuits were filed, and that number has continued to climb. Most target e-commerce sites, restaurants, banking, healthcare, and education websites.

Key legal developments you should know about:

• The DOJ finalized its rule requiring state and local government websites to meet WCAG 2.1 Level AA by April 2026 (for governments serving 50,000+) or April 2027 (for smaller entities)
• The European Accessibility Act (EAA) takes full effect in June 2025, affecting any business serving EU customers
• Serial plaintiff firms continue to file thousands of cases annually, often using automated tools to identify non-compliant sites and send demand letters requesting settlements of $5,000 to $25,000

The cost of proactive compliance ($500 to $5,000 for most small to medium websites) is dramatically lower than the cost of defending against even one lawsuit.

How to Audit Your Website for Accessibility

Before you fix anything, you need to know what’s broken. Here’s the audit process I use:

Step 1: Run Automated Scans

Automated tools can catch about 30% to 57% of accessibility issues. They’re a good starting point but not sufficient on their own. Use these tools:

• axe DevTools (free browser extension): The industry standard. Scans your page and reports WCAG violations with specific code references and fix suggestions
• WAVE (free web tool): Provides visual feedback by overlaying icons on your page showing errors, alerts, and features. Great for non-developers because the results are visual
• Google Lighthouse (built into Chrome DevTools): Includes an accessibility audit as part of its overall site quality report. Gives you a score out of 100
• Pa11y (free, command line): Run automated scans from the command line or integrate into your CI/CD pipeline to catch issues before deployment

Step 2: Manual Keyboard Testing

Put your mouse away and try to use your entire site with just the keyboard. Press Tab to move between interactive elements. Use Enter to activate links and buttons. Use Arrow keys for dropdowns and menus. If you can’t reach something, can’t tell where focus is, or get stuck somewhere, that’s a failure.

Common keyboard failures I find: modal dialogs that trap focus, dropdown menus that don’t respond to arrow keys, custom sliders with no keyboard control, and skip navigation links that don’t work.

Step 3: Screen Reader Testing

This is where you find the issues automated tools miss entirely. Use VoiceOver (built into macOS and iOS) or NVDA (free for Windows). Navigate your site the way a blind user would and listen to how your content is announced. Images without alt text, form fields without labels, and headings that skip levels become immediately obvious.

How to Fix Common Accessibility Issues

Here are the fixes I implement most often, ordered by how commonly they appear:

Missing alt text: Every image that conveys information needs descriptive alt text. Decorative images should have empty alt attributes (alt=””). Don’t just describe what the image is, describe what it communicates. “Chart showing 35% increase in revenue” is better than “bar chart.”

Poor color contrast: WCAG AA requires a 4.5:1 contrast ratio for normal text and 3:1 for large text (18px+ or 14px+ bold). Use the WebAIM Contrast Checker to test your color combinations. Light gray text on a white background is the most common failure.

Missing form labels: Every form input needs an associated label element. Placeholder text is not a label. Screen readers don’t reliably announce placeholders. Use the for attribute on the label and the matching id on the input.

Heading hierarchy problems: Headings should follow a logical order: H1, then H2, then H3. Never skip levels (H1 to H3 with no H2). Screen reader users navigate by headings, so a broken hierarchy is like a book with no chapter structure.

Missing focus indicators: Never remove the outline on interactive elements with outline: none. Keyboard users rely on focus indicators to know where they are on the page. If you don’t like the default browser outline, replace it with a custom one. Don’t remove it entirely.

No skip navigation: Add a “Skip to main content” link as the first element on every page. It should be hidden until focused. This lets keyboard users skip past your header and navigation on every page load.

Using Accessibility Plugins and Tools

If you run a WordPress site, there are tools that can accelerate the process significantly.

accessiBe is an AI-powered accessibility solution that scans your site and automatically remediates many common issues. It adds an accessibility widget that lets users adjust text size, contrast, spacing, and other settings. Plans start at $49/month. It’s not a replacement for proper development, but it covers a lot of ground quickly and helps with legal compliance while you work on permanent fixes.

For WordPress specifically, check out the best accessibility plugins for WordPress. Some handle automated fixes while others help you identify and manually correct issues.

Automated Testing in Your Development Workflow

If you have a development team (or you are the developer), integrating accessibility testing into your workflow prevents new issues from being introduced. Here’s what I recommend:

• CI/CD integration: Add axe-core or Pa11y to your build pipeline. Block deployments that introduce new accessibility failures
• Linting: Use eslint-plugin-jsx-a11y (for React) or similar tools to catch issues in your code editor before they reach the browser
• Component-level testing: Write accessibility tests for each UI component using @testing-library and jest-axe. Test that every component is keyboard-accessible and screen-reader-friendly
• Pre-launch checklist: Before any page goes live, run axe DevTools, test keyboard navigation, and do a quick screen reader check. This takes 10 to 15 minutes per page and catches most issues

The Business Case for Accessibility

Beyond avoiding lawsuits, accessibility makes good business sense. People with disabilities control over $490 billion in disposable income in the US alone. The global market is even larger.

Accessible sites also tend to perform better in search engines. Google’s ranking factors overlap significantly with accessibility requirements: proper heading structure, descriptive link text, image alt attributes, fast load times, and mobile-friendliness. Sites I’ve made accessible have consistently seen improvements in organic traffic as a side benefit.

It also improves the experience for all users, not just those with permanent disabilities. Captions help people watching videos in noisy environments. High contrast helps users in bright sunlight. Keyboard navigation helps power users who prefer keyboard shortcuts. Good accessibility is just good design.

Getting Started: Your Action Plan

Here’s what I recommend doing this week:

1. Run a free scan with axe DevTools or WAVE on your homepage and top 5 pages. Document every issue
2. Fix the quick wins immediately: add missing alt text, fix color contrast, add form labels, correct heading hierarchy
3. Consider installing accessiBe or a similar tool as a bridge while you work on code-level fixes
4. Test keyboard navigation on all your major user flows (homepage, product pages, checkout, contact form)
5. Schedule a quarterly accessibility review to catch new issues as your site changes

Accessibility isn’t a one-time fix. It’s an ongoing practice. But the first audit and round of fixes gets you 80% of the way there, and that 80% is what protects you from the vast majority of legal risk.