Skip to content
wcagc
←Back to blog
ADASaaSSection 508VPAT

ADA compliance for SaaS and web applications

What the ADA asks of a SaaS product: which rules reach you, why buyers want a VPAT, and where app UIs fail behind the login.

P

Pavel Charkasau

ADA compliance for SaaS starts from an awkward fact: no US regulation tells a software company which version of WCAG to hit. The Justice Department's guidance says the ADA's requirements "apply to all the goods, services, privileges, or activities offered by public accommodations, including those offered on the web," and in the next breath that the Department "does not have a regulation setting out detailed standards" for private businesses (ADA.gov).

That gap is why SaaS teams get contradictory advice. The more useful question is which route reaches you, because they arrive from different directions:

  • Title III, through your marketing site, pricing page and signup flow.
  • Title I, because your customers' employees use your app to do their jobs, and their employer owes them an accommodation.
  • Section 508 and the DOJ's Title II web rule, through procurement, the moment a federal agency or a public university wants to buy your software.

The working answer is the same for all three. Build to WCAG 2.2 Level AA, test the screens behind the login, and publish an accessibility conformance report you would defend on a renewal call.

Does the ADA apply to a SaaS product?

Partly settled, partly not. Your marketing site, pricing page and signup form sit in the same position as any other commercial website, and DOJ reads Title III to cover what a business offers online (ADA.gov).

The application itself is the unsettled part: sold to businesses, reachable only after a login, with no premises anywhere. Federal courts have not answered that the same way. The First Circuit has held that a website can be a place of public accommodation independent of any connection to a physical location, while the Third, Sixth and Ninth Circuits apply a "nexus" test tying the online service back to a physical place (Locke Lord / Troutman Pepper). In Robles v. Domino's Pizza the Ninth Circuit applied the ADA to a website and a mobile app because their inaccessibility "impedes access to the goods and services of its physical pizza franchises" (Ninth Circuit, 15 January 2019).

So a pure B2B tool with no storefront has an argument in several circuits. I would not build a plan around winning it: the other routes below do not care about the nexus question at all. Our ADA overview covers the statute and the case law.

Which rules actually reach a B2B SaaS company?

RouteWhat triggers itThe standard in practice
Title IIIYour public site, pricing and signupNo version named by regulation; WCAG 2.1 or 2.2 AA in settlements
Title IA customer's employee needs your app to do their jobWhatever makes the task possible for that employee
Title II, through your customerYou license to a state or local government or a public universityWCAG 2.1 AA, by April 2027 or April 2028
Section 508, through procurementA federal agency buys or uses your softwareWCAG 2.0 Level A and AA, documented in a report

The Title I row is the one SaaS founders rarely see coming. The ADA lists "acquisition or modification of equipment or devices" among the reasonable accommodations an employer may owe (42 U.S.C. § 12111(9)(B)). When a screen-reader user at your customer cannot finish a task in your admin panel, that is their employer's accommodation problem, and the employer solves it by escalating to you or by switching tools.

The Title II row has dates attached. Under the rule DOJ adopted in 2024, state and local government web content and mobile apps generally have to meet WCAG 2.1 Level AA, and an interim final rule published on 20 April 2026 moved the compliance dates to 26 April 2027 for entities serving 50,000 people or more and 26 April 2028 for everyone else (Federal Register, 91 FR 20902; what changed). What pulls a vendor into a rule written for governments is the exception language: some third-party content is exempt, but DOJ says content posted by "a state or local government's contractor or vendor" is not (ADA.gov). If a public university runs your product, your interface sits inside their obligation. That is why their counsel emails you and not the other way round.

Why does procurement ask for a VPAT before they ask for a demo?

Because the buyer carries the obligation and needs evidence before signing. For federal buyers the source is the Revised Section 508 Standards: ICT procured, developed, maintained or used by agencies has to conform (E201.1), and software user interfaces have to meet WCAG 2.0 Level A and AA (E207.2), under a final rule the Access Board issued on 18 January 2017 (U.S. Access Board). Our Section 508 overview covers what that means for a vendor.

The document is a VPAT, the Voluntary Product Accessibility Template published by ITI. The current version is 2.5Rev, dated April 2025, in four editions: Section 508, EN 301 549 for the EU, WCAG, and an international edition combining them (ITI). Filled in with real test results, it becomes an Accessibility Conformance Report. European buyers ask for the EU edition, alongside the obligations in our EAA overview, and we have a walkthrough of how to fill one out.

For a B2B SaaS company, the thing that actually forces this work is almost never a lawsuit. It is a procurement questionnaire landing three days before a renewal, from a customer who has just been handed a deadline of their own.

One honest caveat: nobody audits your report before you send it. Writing "Supports" beside a criterion you never tested is the failure mode I see most, and a buyer's accessibility team finds it in twenty minutes.

Which WCAG version should a SaaS product target?

WCAG 2.2 Level AA, because it is the union of everything above. Section 508 points at 2.0 AA, the Title II rule points at 2.1 AA, and W3C states that content conforming to WCAG 2.2 also conforms to WCAG 2.1 and WCAG 2.0 (W3C, Recommendation of 12 December 2024). One target clears all three, and you write one report instead of three.

Four criteria added in 2.2 land squarely on application UIs:

  • 3.3.8 Accessible Authentication (Minimum), Level AA. At least one authentication method must not depend on a cognitive function test. Blocking paste into the one-time-code field is the classic way to fail it.
  • 2.5.7 Dragging Movements, Level AA. Drag interactions need a single-pointer alternative unless dragging is essential. Kanban boards, reorderable lists and custom sliders sit here.
  • 2.4.11 Focus Not Obscured (Minimum), Level AA. The focused component must not be entirely hidden by content you added. Sticky headers and frozen table rows are the usual culprits.
  • 3.3.7 Redundant Entry, Level A. Step four of onboarding should not ask for what step two collected.

To sort them by level while you triage, use the WCAG checklist.

Where do web applications actually fail?

Application failures cluster around state and time, which is exactly what a static page does not have.

Application patternWhat breaksSuccess criterion
Data grid with a frozen headerFocused row sits behind the sticky element2.4.11 Focus Not Obscured
Autosave "Saved" chipNothing announces that the change was stored4.1.3 Status Messages
Drag-to-reorder boardNo keyboard or menu alternative to the drag2.5.7 Dragging Movements
Combobox assembled from divsNo role, no expanded state, arrow keys do nothing4.1.2 Name, Role, Value
Dense table at 400% zoomContent needs scrolling in two directions1.4.10 Reflow
Tooltip on a settings iconDisappears on mouse-out, cannot be hovered or dismissed1.4.13 Content on Hover or Focus
One-time-code login fieldPaste is blocked3.3.8 Accessible Authentication

The one I hit most in real audits is the autosave chip. A settings page saves in the background, a "Saved" label appears for two seconds, and no screen reader mentions it. Usually the live region was created in the same render as its text, and an aria-live container has to be in the DOM before the message goes into it, or there is no change for the accessibility API to observe. 4.1.3 is Level AA and requires status messages to be programmatically determinable through role or properties without receiving focus (W3C). Forms have their own version of this, in our guide to accessible forms.

Why a homepage scan says almost nothing about your app

WebAIM's February 2026 run across a million home pages found detectable WCAG failures on 95.9% of them, averaging 56.1 errors per page (WebAIM). Every page in that study is a home page. Your product is not in the dataset, and neither is any competitor's, because the crawler cannot log in.

That is the shape of the problem for SaaS. Your marketing site is the smallest surface you own and the only one most tools see, while the workspace customers sit in all day is behind an email, a password and possibly a 2FA code. Homepage-only scans miss the real risk for that reason.

Automation has a ceiling on top of that. Deque's analysis of its own audit data put automated coverage at roughly 57% of issues (Deque), and other studies land nearer 30%. Full conformance needs human review, and the gap is not random: our scanner will tell you a dialog has no accessible name, and it will not tell you whether focus came back to the button that opened it. That is a sequence of states over time, not a property of one snapshot (manual versus automated testing covers the split).

What should a SaaS team do first?

  1. List the flows that carry the contract. Signup, login including 2FA, the main workspace screen, settings, billing. Five flows, not five hundred URLs.
  2. Do each one with the keyboard only. Most teams hit their first blocker inside three minutes, usually a custom dropdown.
  3. Scan the authenticated screens, not the landing page. Same product, entirely different findings.
  4. Fix by component. A SaaS app is a dozen components rendered four hundred ways, so one corrected combobox closes hundreds of instances.
  5. Write the conformance report from test results, not from what the design system was supposed to do.
  6. Re-test on release. You ship weekly, so a report dated last quarter describes a product that no longer exists.

FAQ

Does the ADA apply to B2B software?

No regulation names a WCAG version for private companies, and courts disagree about whether an online-only service is itself a place of public accommodation (Locke Lord / Troutman Pepper). In practice B2B software is reached through employment accommodation under Title I and through public-sector procurement, whichever way that question is resolved.

Do I need a VPAT to sell software to the US government?

Effectively yes. Federal agencies must procure ICT conforming to the Revised Section 508 Standards, which require software user interfaces to meet WCAG 2.0 Level A and AA (U.S. Access Board), and the VPAT is the template buyers use to collect that evidence (ITI).

Which WCAG version should a SaaS product target?

WCAG 2.2 Level AA. W3C states that content conforming to WCAG 2.2 also conforms to WCAG 2.1 and WCAG 2.0 (W3C), so one target covers Section 508's 2.0 AA and the Title II rule's 2.1 AA.

Can an accessibility overlay make a web application ADA compliant?

No. In January 2025 the FTC ordered the overlay vendor accessiBe to pay $1 million over claims that its product could automatically make a website conform to WCAG (FTC). A script that runs after your markup loads cannot know that the div you styled as a listbox was meant to be a listbox.

Does a scanner check the pages behind our login?

Only if it can authenticate. A standard crawler stops at the login form, which is why most SaaS accessibility reports describe the marketing site rather than the product.

See what your product looks like behind the login

Start with the flows that carry your contracts rather than the pages that carry your traffic. A scan returns each finding with the exact selector, so you can fix the unlabelled icon button in your app shell before you touch a decorative image on the pricing page. Run a free accessibility scan.

Written by Pavel Charkasau, founder of wcagc.com. I read the source documents so the guidance here matches what DOJ, the Access Board and W3C actually published.

Last updated: September 9, 2026

Sources