SaaS Company Website ADA Compliance: The Complete 2026 Guide for B2B Software Companies and Tech Startups

1. The Two-Front Accessibility Challenge for SaaS

Unlike a restaurant or retail store, a SaaS company has two distinct digital surfaces that face accessibility obligations:

Many SaaS teams treat accessibility as a product concern and neglect the marketing site — or vice versa. In practice, both carry real legal and business risk, and they need to be addressed together.

2. Marketing Site ADA Requirements

Your marketing website must meet WCAG 2.1 Level AA standards. The DOJ's April 2024 rule update for Title II entities and consistent Title III enforcement has made this a clear legal obligation for any publicly accessible website.

Highest-Risk Marketing Pages

Free Trial & Demo Request Forms

If a person with a disability cannot sign up for your free trial, that's an ADA violation. Common issues: unlabeled form fields, inaccessible password strength indicators, multi-step signup flows without progress announcements, and email verification flows that don't work with screen readers.

Pricing Page

Pricing comparison tables are notoriously difficult to make accessible. A pricing table where the plan name isn't associated with the feature checkmarks is meaningless to screen reader users. Use proper HTML table markup with headers or ARIA grid patterns — don't build pricing layouts with CSS grid and div elements that have no semantic structure.

Interactive Demos and Embedded Product Tours

Tools like Navattic, Storylane, Walnut, and similar interactive demo platforms vary wildly in accessibility. Many are built as iframe embeds with no keyboard support. If your marketing site includes an embedded product tour or interactive demo, verify it works with keyboard navigation and screen readers — or provide an accessible alternative (video with captions + transcript).

Login Page

Your login page is used by every customer. Common failures: username and password fields without labels (using placeholder text only), "Remember me" checkboxes that aren't keyboard- accessible, CAPTCHA that blocks screen reader users, and error messages that aren't announced.

3. Product UI Accessibility: ADA, Section 508, and WCAG

The product itself — the actual SaaS application customers use — faces accessibility requirements from multiple angles:

4. How Accessibility Affects Enterprise SaaS Sales

This is the business case that gets engineering attention when legal compliance alone doesn't. Accessibility is becoming a hard requirement in enterprise procurement — not a nice-to-have.

The Enterprise Procurement Shift

Over the past three years, accessibility has moved from a "do you have a VPAT?" checkbox into a genuine evaluation criterion. Enterprise procurement teams at companies in regulated industries now:

• Request a VPAT/ACR before demos — Some enterprise procurement teams won't schedule a demo until they've reviewed your accessibility conformance report
• Run their own accessibility audits — Large companies with accessibility teams will test your product directly rather than relying on your self-reported VPAT
• Include accessibility requirements in RFPs — RFPs for enterprise software in healthcare, education, finance, and government now routinely include WCAG AA compliance as a requirement
• Require remediation commitments — Contracts may include accessibility milestones and the right to terminate if known accessibility issues aren't resolved

5. VPAT Guide for SaaS Companies

A VPAT (Voluntary Product Accessibility Template) is a standardized document published by the IT Industry Council (ITI) that describes how your product conforms to WCAG 2.1 and Section 508 standards. The completed document is called an ACR (Accessibility Conformance Report).

Do You Need a VPAT?

You should create a VPAT/ACR if you:

• Sell to any government agency (federal, state, or local)
• Sell to K-12 schools, universities, or other educational institutions
• Target enterprise customers (particularly in healthcare, finance, or regulated industries)
• Have been asked for a VPAT in any sales process in the past 12 months
• Are currently responding to RFPs that include accessibility requirements

How to Create a VPAT

1. Download the current VPAT template from itic.org/policy/accessibility/vpat/ — use the WCAG 2.1 edition for most cases, or the Revised Section 508 Edition for government customers
2. Audit your product against each criterion — for each of the 50 WCAG 2.1 AA success criteria, document whether your product Supports, Partially Supports, Does Not Support, or where the criterion is Not Applicable
3. Be honest — inaccurate VPATs create legal risk — a VPAT claiming full compliance when your product has known issues can be cited as fraudulent misrepresentation in litigation
4. Have it reviewed by an accessibility specialist — self-reported VPATs are better than nothing, but a specialist- verified ACR carries more weight in procurement
5. Date and version your VPAT — enterprise customers expect your ACR to reflect the current version of your product. Update when you make significant UI changes.

6. Section 508 for Government SaaS Contracts

Section 508 of the Rehabilitation Act requires that federal agencies ensure any ICT they develop, procure, maintain, or use meets specific accessibility standards. For SaaS companies, this means:

• Your product must conform to the Revised 508 Standards, which incorporate WCAG 2.0 Level AA as the baseline (with plans to update to WCAG 2.1)
• Government contracting officers will request your ACR/VPAT as part of procurement evaluation
• If you win a contract with accessibility deficiencies, you may be required to provide an accessibility roadmap with committed remediation timelines
• Some contracts include Equal Access to Information clauses that make accessibility a material contract requirement

State and Local Government

Many states have their own technology accessibility laws that apply to state agency technology procurement. California Government Code 7405, Texas Government Code Chapter 2054, and similar laws in Washington, New York, and other states create additional requirements for vendors selling to state agencies. The requirements broadly align with WCAG 2.1 AA but have state-specific details.

7. The 10 Most Common SaaS Accessibility Violations

Based on accessibility audits of SaaS products and marketing sites, these violations appear most frequently:

1. Pricing table accessibility — CSS grid pricing tables built with divs that don't use table semantics or ARIA grid patterns, leaving screen reader users unable to understand which features correspond to which plans
2. Unlabeled form inputs on signup/login — Using placeholder text instead of proper label elements; placeholder disappears when users start typing and is never read by screen readers as a true label
3. Inaccessible modal dialogs — Modals that don't trap focus, don't announce their presence to screen readers, and can't be closed with the Escape key
4. Data tables without headers — Analytics dashboards and data tables that use visual layout instead of proper table markup with scope attributes
5. Keyboard-inaccessible dropdown menus — Custom dropdown components that require mouse hover and don't respond to arrow keys or Enter
6. Color-only status indicators — Using only red/ green/yellow to indicate status without text labels or icons — fails color blindness requirements
7. Toast notifications that disappear too quickly — Timed notifications that screen reader users can't catch because they dismiss before the reader announces them
8. Inaccessible date/time pickers — Calendar widgets and time inputs that require mouse interaction with no keyboard alternative
9. Missing skip navigation links — No way to skip the header/nav on every page, forcing keyboard users to tab through dozens of links to reach main content
10. Insufficient color contrast in dark mode — Products that added dark mode as an afterthought often have contrast failures in dark themes that were never tested

8. ADA Lawsuit Risk for Tech Companies

Tech companies have become increasingly common ADA lawsuit targets. The pattern is similar to retail and restaurant cases: a serial ADA plaintiff or advocacy organization tests accessibility, documents WCAG violations, and files suit. The tech-specific wrinkle is that many SaaS products have especially complex interactive UIs that are difficult to make accessible — making violations easier to find.

Who Is Most Targeted

• Consumer SaaS — Products used by individuals (personal finance, health, productivity) face the same ADA exposure as retail sites
• Job boards and recruiting platforms — An inaccessible job application platform creates ADA employment discrimination exposure beyond just the website
• E-commerce SaaS (Shopify app partners, etc.) — Tools that power storefronts inherit some of the accessibility obligations of the stores they power
• VC-backed startups — Startups with recent funding rounds are attractive targets because they have resources and may settle to avoid publicity

9. Building Accessible vs. Retrofitting: Cost Reality

The single most important fact about accessibility in product development: it is dramatically cheaper to build right than to retrofit. This is especially true for SaaS products with complex UIs.

For early-stage startups: this is the time to choose an accessible component library and establish accessibility practices. Doing so during initial development adds minimal cost. Retrofitting a three-year-old React codebase with 200+ custom components can take months and hundreds of thousands of dollars.

10. Implementation Roadmap for SaaS Teams

For Marketing Sites

1. Run a free automated accessibility scan — covers the most common WCAG failures automatically
2. Fix all critical failures in your signup, trial, and demo forms first — these have the highest legal exposure
3. Audit your pricing page for table accessibility and keyboard navigation
4. Verify login page accessibility manually with a screen reader
5. Add a public accessibility statement

For Product UIs

1. Audit your component library — if you built custom components, most will have keyboard and ARIA issues
2. Consider migrating to an accessible component library (Radix UI, Headless UI, React Aria) rather than fixing ad-hoc custom components
3. Prioritize: fix the onboarding flow, main dashboard, and core features first — these are what enterprise customers test
4. Add automated accessibility tests (jest-axe, Playwright axe-core) to your CI pipeline to catch regressions
5. Create and publish a VPAT once you have meaningful WCAG conformance to report

11. Frequently Asked Questions