How to Make Your Website ADA Compliant: A Complete Guide for Business Owners

The Legal and Ethical Obligation Most Websites Are Ignoring

Website accessibility lawsuits in the United States exceeded 4,000 cases in 2023, up from fewer than 300 in 2017. The plaintiffs are often blind users represented by advocacy organizations or law firms specializing in disability discrimination. The defendants range from Fortune 500 companies to small local businesses. The settlements typically include: payment of plaintiff's attorney fees, a commitment to remediate the website, and ongoing monitoring. The total cost per case routinely runs $25,000 to $100,000 or more.

The underlying legal theory: the Americans with Disabilities Act prohibits discrimination in "places of public accommodation." Federal courts, including circuit courts with authority across large regions, have increasingly ruled that commercial websites are places of public accommodation subject to ADA requirements. The Department of Justice issued guidance in 2022 explicitly stating that websites must comply with accessibility standards.

This is not hypothetical legal risk that might materialize at some point in the future. It's active enforcement happening to businesses of all sizes right now. The question is not whether the ADA applies to your website — courts have largely settled that it does. The question is whether your website meets the requirements it must meet.

This guide explains what those requirements are, how to determine whether your website currently meets them, and the practical steps to achieve compliance.

What the ADA Actually Requires for Websites

The ADA itself was enacted in 1990 — decades before the web existed in any recognizable form. It doesn't specify technical standards for website accessibility. What it requires is that people with disabilities have equal access to goods, services, and communications — and the application of that principle to websites has been developed through court interpretations and DOJ guidance.

The technical standard courts and the DOJ consistently reference as the benchmark for ADA website compliance is the Web Content Accessibility Guidelines (WCAG), developed by the World Wide Web Consortium (W3C). Specifically, courts and regulators generally require WCAG 2.1 Level AA compliance — though the DOJ has signaled it may codify WCAG 2.2 as the regulatory standard.

WCAG 2.1 AA is organized around four core principles: content must be Perceivable (users can perceive all information), Operable (all functionality is accessible via keyboard and assistive technology), Understandable (content is clear and predictable), and Robust (content works across different assistive technologies).

Within these principles, WCAG 2.1 AA specifies 50 success criteria — specific, testable requirements that determine whether a website meets the standard.

The Most Critical WCAG Requirements and What They Mean

Images Must Have Text Alternatives (1.1.1)

Every image that conveys meaningful information must have an alt attribute containing text that conveys the same information. A photo of your team on the about page needs alt text that identifies the people. A chart showing revenue growth needs alt text that communicates the chart's key findings. A product photo needs alt text that describes the product.

Decorative images — images that are purely visual decoration with no informational content — should have empty alt attributes (alt="") so screen readers skip them rather than announcing them as unlabeled images.

The most common failure: images with no alt text at all, or alt text that consists of the filename (image001.jpg) rather than a description of the content.

Videos Must Have Captions (1.2.2)

Any prerecorded video with audio must have synchronized captions. This includes:

• Product demo videos
• Testimonial videos
• Educational or instructional content
• Marketing videos
• Background videos with important audio content

Auto-generated captions from YouTube or video platforms are not sufficient — they're often inaccurate, especially for proper nouns, technical terminology, and accented speech. Accurate, human-reviewed captions are the standard. Transcripts must also be available for audio-only content (podcasts, audio recordings).

Sufficient Color Contrast (1.4.3)

Text must have sufficient contrast against its background to be readable by users with low vision or color vision deficiencies. WCAG 2.1 AA requires:

• 4.5:1 contrast ratio for normal text (under 18pt or 14pt bold)
• 3:1 contrast ratio for large text (18pt or larger, or 14pt+ bold)
• 3:1 contrast ratio for UI components and graphical objects (button borders, form field outlines, icons)

The most common failure in modern web design: light gray text on white backgrounds that fails to meet the 4.5:1 minimum. Thin gray text (#999) on white (#fff) has approximately 2.85:1 contrast — well below the 4.5:1 requirement. Check every color combination in your design.

Text Must Be Resizable (1.4.4)

Text must remain readable and functional when resized up to 200% through browser text zoom. If your website uses fixed pixel sizes for text and fixed-height containers that clip when text grows, it will fail this requirement.

Solution: use relative units (rem, em) for text sizes, use min-height rather than height on containers that hold text, and test your site at 200% browser zoom to verify nothing breaks.

No Content That Can Cause Seizures (2.3.1)

Content that flashes more than three times per second can trigger seizures in users with photosensitive epilepsy. Flashing elements, rapidly blinking animations, and strobe effects must either be below this threshold or be controllable by the user.

This requirement affects not just intentional animations but also certain types of video content and animated advertising elements.

All Functionality Must Be Keyboard Accessible (2.1.1)

Every function that a user can perform with a mouse or touchscreen must also be achievable using only a keyboard. This means:

• All navigation items are reachable with Tab key
• Dropdown menus open and can be navigated with keyboard
• Buttons activate with Enter or Space
• Forms can be completed without a mouse
• Modals and overlays can be opened and closed with keyboard
• Custom interactive components (date pickers, carousels, accordions) work without a mouse

Test this by unplugging your mouse and attempting to complete your site's primary user journeys using only Tab, Shift+Tab, Enter, Space, and arrow keys. Many websites fail significantly at this test.

Keyboard Focus Must Be Visible (2.4.7)

When users navigate by keyboard, there must be a clearly visible indicator of which element currently has keyboard focus. Many CSS stylesheets include outline: none or outline: 0 — either globally or on specific elements — to remove the default browser focus ring because designers find it aesthetically unpleasant. This is one of the most common accessibility failures on professional websites.

The fix: never remove focus styles without replacing them with an alternative focus indicator that's equally visible. Custom focus styles (a colored border, background highlight, or other visible treatment) are preferable to the default browser ring aesthetically while maintaining keyboard accessibility.

All Form Fields Must Have Labels (1.3.1 and 3.3.2)

Every form field must have a programmatically associated label. The label must be present in the HTML — not just visually placed near the field, but actually connected via a for attribute on the label element and matching id on the input, or via ARIA labeling attributes.

Placeholder text is not a label. Placeholder text disappears when the field is active, providing no label during data entry. It also has lower color contrast than labels by convention, often failing contrast requirements independently.

Error Identification and Description (3.3.1 and 3.3.2)

When a form has errors, the errors must be identified and described in text. Not just visually (a red border, an alert icon) but in text that explains what the problem is and how to fix it. Error messages must be programmatically associated with the fields they describe so screen readers can announce the error in context.

Consistent Navigation (3.2.3)

Navigation that appears across multiple pages must appear in the same order and location on each page. Users with cognitive or visual disabilities develop spatial and sequential mental models of navigation — changing the navigation between pages breaks these models and requires relearning.

Page Titles (2.4.2)

Every page must have a unique, descriptive title in the HTML <title> element. Screen reader users often rely on page titles to understand where they are and to orient themselves after navigating. Generic titles like "Home" or "Welcome" that don't identify the site, or pages with duplicate titles that don't distinguish them from each other, fail this requirement.

How to Audit Your Current Website

Automated Testing

Automated accessibility testing tools can identify approximately 30–40% of WCAG violations — the issues that can be detected algorithmically. This is a meaningful starting point, not a complete audit.

axe DevTools (browser extension, free): The most widely used automated accessibility testing tool. Install as a Chrome or Firefox extension, run on any page, and receive a detailed report of violations with severity levels and fix guidance. The free version is comprehensive for most basic auditing needs.

Google Lighthouse (built into Chrome DevTools): Open Chrome DevTools (F12), navigate to the Lighthouse tab, run an accessibility audit. Provides an accessibility score and specific violations. Uses axe's engine under the hood.

WAVE (browser extension, free): Provides a visual overlay on the page showing accessibility issues in context. Useful for understanding where issues are located relative to page content.

Run automated tests on every unique page template — not just the homepage. Different page types (product pages, blog posts, forms, checkout flows) often have different accessibility issues.

Manual Testing

The 60–70% of issues that automated testing misses require human judgment. Critical manual tests:

Keyboard navigation test: Disconnect or ignore the mouse. Navigate through the entire site using only keyboard. Can you reach every interactive element? Is there always a visible focus indicator? Can you complete all primary user flows?

Screen reader test: Install NVDA (Windows, free) or use VoiceOver (Mac, built-in). Navigate your site. Do images have appropriate alt text? Are form fields labeled? Does dynamic content announce itself? Are interactive elements identified as buttons or links correctly?

Contrast test: Use a contrast checker (WebAIM Contrast Checker at webaim.org/resources/contrastchecker, or the Colour Contrast Analyser desktop app) to verify every color combination used for text meets the 4.5:1 minimum. Don't forget disabled states, placeholder text, and text overlaid on images.

200% zoom test: Increase browser text zoom to 200% and navigate the site. Does text remain readable? Does content overflow or disappear? Do layouts break?

Remediation: Fixing What You Find

Priority Order for Fixes

Remediation should address the most impactful issues first:

1. Critical issues that make core functions inaccessible: Keyboard traps, form fields without labels, broken screen reader navigation on checkout/contact flows. These prevent entire categories of users from completing primary tasks.
2. Issues affecting large amounts of content: Missing alt text across dozens of images, contrast failures across all body text. High impact because they affect many users on many pages.
3. Issues on high-traffic pages: Problems on your homepage, primary landing pages, and checkout flows affect the most users. Fix these before obscure pages.
4. Issues on lower-traffic or secondary pages: After critical issues are resolved, work through lower-priority pages.

Working with Developers on Remediation

Most accessibility issues require code changes — they can't be fixed through content updates or design changes alone. If you're working with a developer or agency for remediation, provide them with the full audit report from your automated and manual testing, prioritized by the order above.

Common developer fixes include: adding alt attributes to images (straightforward), adding label elements to form fields (straightforward), implementing custom focus styles to replace removed defaults (moderate), fixing keyboard navigation for custom interactive components (complex, especially for carousels, dropdown menus, modals, and date pickers), and implementing ARIA attributes correctly on dynamic content (complex).

Accessibility Overlays: Not a Solution

Accessibility overlay products — JavaScript plugins that claim to make any website ADA compliant with a single line of code — are not a legitimate compliance solution. Multiple disability rights organizations and WCAG experts have formally opposed overlay products, documenting that they frequently interfere with assistive technologies that users already have configured, introduce new accessibility problems, and do not reliably remediate the underlying code-level issues that create barriers.

More importantly: the presence of an overlay product does not provide legal protection. Multiple court cases have found against defendants who were using overlay products, because the overlay doesn't make the site actually compliant — it just adds a layer on top of non-compliant code.

Real accessibility requires fixing the underlying code. Overlays are a shortcut that doesn't work.

Maintaining Compliance Over Time

Accessibility compliance isn't a one-time project — it's an ongoing practice. New content added to the site (blog posts, new product pages, new team photos, videos) may introduce new accessibility issues if the processes for creating that content don't include accessibility checks.

Sustainable accessibility requires:

• Accessibility requirements documented and communicated to anyone creating website content
• Automated testing integrated into the development process (not just done once at audit time)
• Manual testing included in QA processes for new features
• An accessibility statement published on the website (and updated when remediation occurs)
• A clear process for users to report accessibility issues and receive assistance

The Cost of Compliance vs. Non-Compliance

Website accessibility remediation is not free. Depending on the current state of the site and the complexity of issues found, remediation can range from several thousand dollars (for a straightforward small-business website with a handful of specific issues) to tens of thousands (for complex web applications with significant custom JavaScript components).

This cost must be weighed against the cost of non-compliance: ADA lawsuit settlements typically run $25,000 to $100,000 in attorney fees alone, plus the cost of the remediation you'd have had to do anyway, plus the reputational impact.

For most small and mid-size businesses, proactive compliance is significantly cheaper than reactive remediation under legal pressure. For businesses who've already received a demand letter (a common first step before a lawsuit is filed), the calculation changes — legal counsel should be consulted immediately about both the legal response and the remediation plan.

The Bottom Line

ADA website compliance is a legal requirement that courts are actively enforcing against businesses of all sizes. The standard courts and regulators apply is WCAG 2.1 Level AA. Meeting this standard requires specific code-level changes — not design changes, not overlay plugins, but genuine fixes to the HTML, CSS, and JavaScript that create the barriers users with disabilities encounter.

Audit your site with automated tools (axe, Lighthouse) and manual testing (keyboard navigation, screen reader, contrast checks). Prioritize fixes by impact. Work with qualified developers for code-level remediation. Build accessibility review into your ongoing content and development processes.

At Scalify, every website we build is constructed with accessibility as a baseline requirement — semantic HTML, proper ARIA usage, keyboard accessibility, sufficient contrast, and labeled forms — because good web development practice and accessibility compliance are the same thing done correctly.