Industry guide
SaaS & Software accessibility
SaaS accessibility means that B2B and B2C software products — dashboards, admin consoles, embedded widgets, and APIs — meet WCAG 2.2 AA so that employees with disabilities and the customers they serve can use the product, which is increasingly a procurement requirement (VPAT/ACR) and an EAA obligation for consumer-facing SaaS in scope.
78%
of enterprise SaaS RFPs now require a VPAT/ACR
Source: Forrester 2024
$3.5B
lost annually by SaaS vendors disqualified from procurement for missing VPATs
Source: Industry estimate
What does accessibility mean for SaaS products?
SaaS vendors face accessibility through two channels: their own marketing site (subject to ADA Title III), and their product (subject to procurement-driven VPAT requirements and EAA scope for consumer services). Enterprise procurement increasingly requires a current VPAT.
Compliance standards that apply
- WCAG 2.2 AA
- Section 508 (federal procurement)
- EN 301 549 (EU procurement)
- EAA (consumer SaaS)
- VPAT 2.5 documentation
Common accessibility failure points in SaaS products
- Component libraries without semantic markup
- Modal dialogs that trap focus incorrectly
- Data tables without programmatic structure
- Drag-and-drop without keyboard alternatives
- Status messages not announced to AT (4.1.3)
Most-cited violations
- Inaccessible custom dropdowns and select widgets
- Toast notifications not announced
- Charts without accessible data tables
- Onboarding tours unusable by keyboard
- Color-only state indicators
Remediation priorities
- Core admin / dashboard navigation
- Forms, validation, and error recovery
- Tables, charts, and data export
- Component library (button, input, modal, menu primitives)
- Embedded customer-facing widgets
Authoritative sources
- Section508.gov VPAT — GSA
A note on widgets and overlays
Can an accessibility widget make your site compliant?
No. Widgets adjust how content renders for individual visitors — text size, contrast modes, dyslexia-friendly fonts. They do not remediate the underlying source code. WCAG conformance is graded at source level, and US federal courts (Murphy v. Eyebobs, Suarez v. Camping World, Hernandez v. Caesars) have repeatedly held that the presence of an overlay does not preclude ADA liability.
Our product produces an IAAP-format audit report with source-level remediation guidance. If you want a preferences panel for end users, ship one separately — opt-in, disclosed, and never marketed as a compliance solution.
See the Overlay Fact Sheet, signed by 900+ accessibility professionals.
FAQ
SaaS & Software accessibility — FAQ
Cited answers. Sourced. Updated as standards and case law change.
Do SaaS vendors need a VPAT?
Increasingly yes. Enterprise procurement teams — particularly in higher education, healthcare, government, and large finance — require a current VPAT/ACR before purchase. Federal vendors require Section 508 VPATs explicitly.
Is the SaaS marketing site or the product more important for accessibility?
Both are in scope under different regimes. The marketing site is ADA Title III (public accommodation). The product is procurement-VPAT-driven and increasingly EAA-driven for consumer offerings. A vendor should not treat one as adequate cover for the other.
What is the most cost-effective way for a SaaS team to start?
Three steps: (1) accessibility-instrumented component library so new screens inherit conformance; (2) axe-core in CI for regression; (3) annual manual audit against WCAG 2.2 AA with an IAAP-certified team.
Stop guessing. Get the audit a Fortune 500 a11y team would have written.
Free audit on your live URL. No sign-up. IAAP-format report. Ready in hours.
founders@accessivepath.com · +977 9851094056