SiteBrace

All industries » SaaS website accessibility

SaaS website accessibility: marketing site, app, VPAT, and procurement

B2B SaaS marketing websites are commercial public accommodations under ADA Title III. The 9th Circuit's Robles v. Domino's reading has been applied to SaaS company websites in several federal district cases since 2021. On top of that, SaaS companies that sell into US federal, state, or local government must meet Section 508 (which references WCAG 2.0 Level AA) and produce a VPAT for procurement review. SaaS companies serving EU customers face the European Accessibility Act (EAA), which took effect 28 June 2025 and adopts WCAG 2.1 Level AA as its conformance standard for "consumer-facing" software services. Site Brace audits the marketing site plus 25 pages of the highest-traffic product surfaces for $149 flat and produces the WCAG evidence procurement and legal teams ask for.

Short answer: the highest-risk surfaces on a SaaS site are the marketing homepage and product pages (form-heavy demo requests, video players, modal popups), the login and signup screens, the in-app onboarding flow, and the help center or docs site. A WCAG 2.1 AA audit gives you the substantiation a Section 508 VPAT needs and the evidence buyers in regulated industries (healthcare, education, public sector) request during procurement. Site Brace audits up to 25 pages for $149 flat. Try a free single-page check on your homepage first.

The rules that apply to SaaS companies

1. ADA Title III (always applies if you have US customers)

The Americans with Disabilities Act Title III applies to any commercial public accommodation, and federal courts have read SaaS marketing websites into that category. The plaintiffs' bar that drives most ADA web cases against e-commerce defendants has begun targeting SaaS companies whose marketing sites have visible accessibility failures. The exposure pattern is familiar: a demand letter, a six-figure settlement offer, no opportunity to fight the case past the pleading stage.

2. Section 508 and the VPAT (if you sell to US government)

Section 508 of the Rehabilitation Act requires federal agencies to procure information and communication technology that meets WCAG 2.0 Level AA (the standard the 2018 refresh adopted). The practical mechanism is the Voluntary Product Accessibility Template, or VPAT, which the vendor produces and the procurement office reviews. A VPAT is a self-attestation; an honest VPAT requires a real WCAG audit underneath it. State and local government procurement frequently mirrors Section 508 or references WCAG 2.1 Level AA directly. If your sales motion targets public-sector buyers, your VPAT is procurement-blocking until it exists.

3. The European Accessibility Act (if you serve EU customers)

The EAA came into force in EU member states on 28 June 2025. It applies to "services" provided to EU consumers, which includes SaaS sold to small businesses (B2B sales below a member-state-defined threshold are exempt). The conformance standard is WCAG 2.1 Level AA, mirrored from EN 301 549. Enforcement is per-member-state; fines are in the same order as GDPR fines and have been imposed in early enforcement actions in Germany and Ireland.

4. State accessibility laws

State human-rights and accessibility statutes (California's Unruh Act, NY's Human Rights Law, the Colorado Privacy Act's accessibility provisions, etc.) apply to SaaS companies the same as to any other commercial entity selling in the state. California in particular has been the venue for the largest share of SaaS-targeted ADA cases. See the California ADA compliance guide for the state-stack details.

The high-risk surfaces specific to SaaS sites

Marketing site: forms, videos, modals

SaaS marketing sites lean on three patterns that fail accessibility consistently: demo-request and contact forms (often built in HubSpot, Marketo, or Pardot, with placeholder-only labels), embedded product videos (Wistia, Loom, Vidyard, YouTube embeds without captions or transcript), and modal popups (newsletter signups, exit-intent overlays, cookie banners that trap keyboard focus or hide focus indicators).

Login and signup screens

Login forms are the highest-conversion surface on a SaaS site and the place where an accessibility failure prevents a paying customer from completing the work they came to do. SSO buttons rendered as icon-only links, password-strength meters announced as color-only signals, and CAPTCHA challenges without audio alternatives are the common failures. The signup flow extends the same pattern across multiple steps.

In-app onboarding and the product itself

A SaaS audit usually does not cover the entire authenticated product (that is months of work, not one audit). It does cover the public-facing onboarding pages and a representative sample of the marketing-adjacent product screens (dashboard landing, the first few product flows visible after signup). For procurement-blocking VPATs, the audit needs to extend into the authenticated app; we can scope that separately.

Help center and documentation

Most SaaS companies run a documentation site on Readme, GitBook, Mintlify, Docusaurus, or a custom Next.js setup. Documentation sites are large surface areas with consistent template-driven failures: code-block contrast, search input labels, sidebar navigation keyboard traps, and copy-to-clipboard buttons rendered as icon-only.

What we typically find on a SaaS marketing site

Findingaxe-core ruleTypical cause
Demo-request form fields have placeholder text instead of labels label HubSpot, Marketo, or Pardot form embed with default styling
Color contrast on primary CTA buttons color-contrast Brand palette (often purple, teal, or coral) tuned for design comp rather than 4.5:1 on white
Modal popup traps keyboard focus or hides focus ring Manual finding Custom-built or older popup library (Optimonk, Privy, Sumo) without focus-trap escape
Product video has no captions or transcript Manual finding Wistia or Loom embed of a marketing video produced without captioning
Hero or feature illustration lacks alt text image-alt CMS auto-populates alt from filename ("hero-illustration-final-v3.svg")
SSO buttons on the login screen are icon-only button-name "Sign in with Google" rendered as a G logo without a visible label or aria-label
aria-label on generic header div aria-prohibited-attr Theme customization or overlay injection. See aria-label on a div.
Cookie consent banner not keyboard-reachable before the rest of the page Manual finding Banner positioned by z-index but focus order leaves it last in the tab sequence

A note on VPATs

A VPAT is the document procurement officers ask for. It is not a substitute for an audit; it is a self-attestation that summarizes audit findings against the Section 508 / WCAG criteria. Vendors who produce a VPAT without a real audit produce a VPAT they cannot defend if challenged. Vendors who run an audit and produce a VPAT from the findings produce a VPAT that survives procurement scrutiny.

Site Brace does not produce VPATs directly. The Site Brace audit gives you the per-criterion conformance evidence a VPAT needs. Most SaaS companies have an internal compliance lead or external accessibility consultant who builds the VPAT from the audit; if you want a referral, ask and we will point you at someone who specializes in VPAT preparation.

Why overlays are a poor fit for SaaS sites

Accessibility overlays are heavily marketed to SaaS marketing teams as a "set-and-forget" alternative to remediation. We have written about why accessibility overlays do not make sites WCAG-compliant in detail. For SaaS specifically:

  • Overlays do not enter authenticated product surfaces. The onboarding flow, the dashboard, the in-app help widget all live behind login and an overlay script never reaches them.
  • Procurement review treats overlays as a red flag. A VPAT that says "we use an accessibility overlay" is an instant disqualification at most federal and many state procurement offices.
  • The FTC's $1 million settlement with accessiBe in April 2025 makes overlay-based compliance claims a documented liability that procurement legal teams will surface during diligence.
  • The EAA enforcement environment in the EU is hostile to overlay-based remediation. Several early member-state enforcement actions specifically called out overlays as insufficient.

How Site Brace audits a SaaS site

The standard page mix for a SaaS audit:

  • Marketing homepage
  • Product pages (top 3-5 by traffic, usually the platform overview plus the top features)
  • Pricing page
  • Customers or case studies page (and 1-2 customer-story detail pages)
  • Demo request page (with its form)
  • Contact page
  • Blog index plus 1-2 representative blog posts
  • Login page
  • Signup page (the first step of the flow)
  • Top help-center pages (1-3 highest-traffic articles)
  • Trust center or security page (if separate)
  • Accessibility statement (if one exists)

That mix covers up to 25 pages for a typical SaaS site. The audit runs axe-core 4.10 against each page, captures element-level screenshots of every contrast failure, and packages the findings into a written report with copy-paste fix code and 12 re-scans included over 12 months.

Pricing is $149 flat, one-time. To see what the report looks like, view a sample report we built for a fictional DTC apparel brand. The SaaS findings overlap heavily in shape (forms, modals, contrast, icon-only buttons) even though the underlying business is different. For procurement-blocking VPATs the deliverable shape is the same; the per-criterion mapping is the artifact procurement reviewers cite.

Want to check your own site first? Run a free single-page check on your homepage or your demo-request page - one URL, about a minute, no signup needed to see the result.

Start a SaaS website audit, $149

Related: