ADA compliance for apps: Digital accessibility laws in the US

In 2016, Guillermo Robles tried to order pizza from the Domino's app. Robles is blind and uses a screen reader. The app didn't work with screen readers. He couldn't navigate the menu, customize his order, or complete checkout.

Robles sued under ADA Title III. Domino's fought it all the way to the Supreme Court, arguing that the ADA doesn't cover websites and apps. The Supreme Court declined to hear the case in 2019, letting the Ninth Circuit's ruling stand: the ADA applies to Domino's digital properties. The case settled in 2022 after six years of litigation.

Domino's spent millions in legal fees to avoid making their app accessible. The accessibility remediation would have cost a fraction of that. It's one of the clearest cases in business law where the preventive investment is cheaper than the cure by an order of magnitude.

And Domino's isn't unique. Over 4,000 ADA digital accessibility lawsuits were filed in federal court in 2023 alone - a 300% increase from 2018. The trend line is going in one direction.

Who does this apply to?

The ADA was written in 1990. It doesn't mention websites, apps, or the internet. But the law prohibits discrimination based on disability in "places of public accommodation" - and courts have interpreted this broadly.

Your app is almost certainly covered if:

• You sell goods or services to the public: e-commerce, food delivery, booking platforms, financial services, any app connected to a business open to the public.

• You offer a service that has a physical counterpart: a restaurant's ordering app, a hotel's booking app, a bank's mobile app are digital extensions of physical places of public accommodation.

• You're a SaaS product used by businesses that serve the public: your customers' ADA obligations flow to you. If a hospital uses your patient portal, that portal needs to be accessible.

• You receive federal funding: Section 508 of the Rehabilitation Act requires accessible technology. If your software is used by a federal agency, Section 508 applies.

• You serve state or local government: the DOJ's 2024 rule under ADA Title II explicitly requires WCAG 2.1 AA compliance for state and local government web content, with compliance deadlines in 2026 and 2027 depending on population size.

The practical answer: if your app is used by the public, treat it as covered. The legal cost of assuming you're exempt and being wrong is far higher than the engineering cost of building accessible.

According to CDC data released in 2024, 28.7% of US adults - more than 70 million people - report having a functional disability. That's not a niche audience. Cognitive disability is the most common type, affecting 14% of US adults.

What the law requires

The ADA doesn't specify technical standards for digital accessibility. It requires "effective communication" and "full and equal enjoyment" of goods and services. Courts fill in the technical details - and they consistently point to WCAG 2.1 AA.

WCAG 2.1 AA - the four principles

WCAG is built on four principles, commonly called POUR:

1. Perceivable - Users must be able to perceive the information presented.

2. Operable - Users must be able to operate the interface.

3. Understandable - Users must be able to understand the information and interface.

4. Robust - Content must be robust enough that assistive technologies can interpret it.

The numbers: WCAG 2.1 AA has 50 success criteria

You don't need to memorize all 50. But your development team needs to test against them. The most impactful ones for reducing legal risk:

• 1.1.1 Non-text Content: alt text for all images and non-text content

• 1.3.1 Info and Relationships: semantic HTML that conveys structure (headings, lists, tables, form labels)

• 1.4.3 Contrast (Minimum): 4.5:1 for normal text, 3:1 for large text

• 2.1.1 Keyboard: all functionality operable via keyboard

• 2.4.4 Link Purpose: link text that makes sense out of context ("Read more" without context fails)

• 3.3.2 Labels or Instructions: form fields have visible labels

• 4.1.2 Name, Role, Value: custom components communicate their role and state to assistive technologies

The legal landscape: Why lawsuits are surging

ADA digital accessibility lawsuits have grown from about 800 in 2017 to over 4,000 annually. UsableNet's 2024 Year-End Report tracked 4,187 digital accessibility lawsuits filed in 2024 across federal and state courts. WebAIM's 2024 accessibility analysis found that 95.9% of the top 1 million websites had detectable WCAG 2 failures - the average home page had 56.8 detected errors. Several factors drive the lawsuit volume:

Serial plaintiffs and plaintiff firms. A handful of law firms and individual plaintiffs file hundreds of suits per year. They use automated scanning tools to identify non-compliant websites and apps, then file suits or demand letters in bulk. This is legal and the courts have allowed it.

Low barrier to filing. An ADA lawsuit doesn't require proving damages. The plaintiff only needs to show they encountered a barrier and intend to return to the business. Statutory damages, injunctive relief (requiring you to fix it), and attorney's fees make these cases profitable for plaintiffs' firms even with small individual settlements.

Consistent plaintiff wins. Courts have repeatedly ruled that digital properties must be accessible. The Domino's case removed the last major defense businesses were using ("the ADA doesn't cover digital"). Post-Domino's, the question in most cases isn't whether the ADA applies - it's whether the specific app meets the standard.

DOJ enforcement. The Department of Justice has entered settlements requiring WCAG 2.1 AA compliance with companies including H&R Block, Peapod, Rite Aid, and multiple universities. The DOJ's 2024 Title II rule for government websites signals increasing enforcement expectations for private businesses under Title III.

Industries most targeted

How it affects your app architecture

Accessibility isn't a feature you add at the end. It's a set of constraints that influence your component architecture, your CSS strategy, your JavaScript behavior, and your testing pipeline.

Component architecture

Every UI component needs to handle three concerns: visual presentation, semantic meaning, and interactive behavior.

Visual presentation is what sighted users see. Semantic meaning is what screen readers understand. Interactive behavior is how keyboard users navigate. Most accessibility bugs happen when one of these three is broken or missing.

Buttons that are divs. If you build a clickable element as a <div> with an onClick handler, it looks like a button to sighted users. But it has no semantic meaning (screen readers don't announce it as a button) and no keyboard behavior (you can't tab to it or activate it with Enter/Space). Use a <button> element or add role="button", tabindex="0", and keyboard event handlers.

Custom dropdowns. Native <select> elements are accessible out of the box. Custom dropdown components need ARIA attributes (role="listbox", aria-expanded, aria-activedescendant), keyboard navigation (arrow keys to move between options, Enter to select, Escape to close), and focus management (focus returns to the trigger when the dropdown closes).

Modal dialogs. When a modal opens, focus must move to the modal. Tab navigation must be trapped inside the modal (users shouldn't be able to tab to content behind it). When the modal closes, focus returns to the element that triggered it. Screen readers need role="dialog", aria-modal="true", and an accessible name.

Color and contrast

WCAG 2.1 AA requires:

• 4.5:1 contrast ratio for normal text (under 18pt / 24px)

• 3:1 contrast ratio for large text (18pt+ / 24px+ or 14pt+ bold / 19px+ bold)

• 3:1 contrast ratio for UI components and graphical objects (borders, icons, form fields)

This constraint affects your design system from day one. A light gray (#999) on white background fails at 2.8:1. Your "disabled" state styling, your placeholder text, your secondary labels - all need to meet the threshold.

Architecture decision: Build contrast checking into your design system. Define accessible color pairs in your token system and flag any usage that doesn't meet the ratio. Catching contrast issues in the design token layer is cheaper than finding them in a lawsuit.

Focus management

Every interactive element must have a visible focus indicator. The default browser focus ring works, but many design teams suppress it with outline: none for aesthetic reasons. That's an accessibility violation.

Architecture decision: Build a custom focus style into your design system that's visible against all backgrounds - a 2px solid ring with sufficient contrast. Apply it globally. Never remove focus indicators without replacing them.

Focus order must follow a logical reading order. If your layout uses CSS Grid or Flexbox to reorder elements visually, the DOM order still determines the focus sequence. A screen reader reads the DOM, not the screen.

Dynamic content

Single-page applications create a specific accessibility challenge: when content updates without a page reload, screen readers don't know something changed.

Architecture decision: Use ARIA live regions (aria-live="polite" or aria-live="assertive") to announce dynamic content changes. Announce successful form submissions. Announce toast notifications as they appear. For asynchronously loaded content, announce when it's ready.

Route changes in SPAs need special handling. When the user navigates to a new "page," manage focus to the new content area and update the document title. Otherwise, screen reader users have no indication that anything changed.

Testing pipeline

Automated accessibility testing catches about 30-40% of WCAG violations. The rest require manual testing.

What to automate:

• axe-core or similar tools integrated into your CI/CD pipeline

• Contrast ratio checks in your design system

• HTML validation (invalid markup breaks assistive technologies)

• Automated screen reader testing for component libraries

What requires manual testing:

• Keyboard navigation flow through the entire application

• Screen reader testing (VoiceOver on Mac/iOS, NVDA or JAWS on Windows, TalkBack on Android)

• Focus management during dynamic interactions (modals, dropdowns, notifications)

• Reading order vs visual order verification

• Meaningful alt text review (automated tools can check existence, not quality)

What it costs: Build accessible vs. defend inaccessible

A mid-complexity app that costs $200,000 to build costs roughly $210,000-$220,000 to build accessible. Retrofitting that same app after a lawsuit costs $40,000-$80,000 for remediation, plus $75,000-$225,000 in legal fees and settlements. And the settlement typically includes ongoing monitoring for 2-3 years.

"We build accessibility into the component architecture from sprint one - semantic HTML, ARIA attributes, keyboard navigation, focus management as standard requirements on every component. When a team tries to retrofit this after launch, they're rebuilding the component library. That's not a patch job, it's a rewrite." - RaftLabs Engineering Team

Questions to ask your development partner

1. How do you build accessibility into your component library? The answer should reference semantic HTML, ARIA attributes, keyboard event handling, and focus management as standard component requirements, not add-ons.

2. What does your accessibility testing pipeline look like? Look for automated testing (axe-core in CI/CD), manual screen reader testing, and keyboard navigation testing. If testing is only automated, they're catching less than half of potential issues.

3. Can you walk me through how you handle focus management in modals, dropdowns, and route changes? These are the three most common failure points in single-page applications. If they can't give specific answers, they haven't built accessible SPAs before.

4. What's your approach to color contrast in the design system? The answer should describe contrast ratio enforcement at the token level, accessible color pairs, and testing for both light and dark modes if applicable.

5. Have you had a project pass an independent accessibility audit? An independent audit by a third-party accessibility firm is the strongest evidence that the team can deliver accessible work. Ask for the audit results or a reference.

6. How do you handle accessibility in third-party components? Most apps use UI libraries, date pickers, charting libraries, and other third-party components. Some are accessible, some aren't. The team should have a vetting process and remediation strategy for third-party dependencies.

Your ADA compliance checklist

Digital accessibility isn't just a legal requirement. It's a market. According to the WHO's 2023 disability fact sheet, over 1.3 billion people worldwide - 16% of the global population - live with some form of significant disability. In the US alone, adults with disabilities have a disposable income of over $490 billion. Building accessible means serving a larger market while avoiding the lawsuits that are growing every year. The engineering cost is small. The legal and business cost of ignoring it is not.