ADA, Section 508, and EAA Compliance for B2B SaaS

B2B SaaS used to operate as if accessibility was a problem for its customers' customers. That assumption stopped working in 2024-2025. Enterprise buyers now reject vendors whose products cannot produce a credible VPAT. Federal agencies and federal contractors require Section 508 conformance for any procured information and communications technology. The European Accessibility Act 2025 (Directive (EU) 2019/882) imposed enforceable accessibility requirements on a broad class of products and services sold into EU markets, including most consumer-facing software components embedded in B2B platforms. State governments — particularly those with strong public records and procurement laws — have tightened their accessibility-conformance requirements for vendors. And when a B2B SaaS product surface touches end consumers (an HR tool used by job applicants, a property management tool used by tenants, a healthcare scheduling tool used by patients), Title III liability can attach directly. This guide covers what changed, where the audits now look, and what compliance actually requires.

This page is informational and is not legal advice. ADA, federal regulations, and state-law obligations vary by jurisdiction and business type — consult qualified counsel for case-specific guidance.

VPATs, Section 508, EAA, and Title III — what applies when

Section 508 of the Rehabilitation Act applies directly to federal agencies and indirectly to vendors that sell ICT to those agencies. The 2018 Section 508 refresh harmonized the federal accessibility standard with WCAG 2.0 AA, and the General Services Administration's Buy Accessible procurement framework requires vendors to provide an Accessibility Conformance Report (ACR), typically using the ITIC VPAT template. A non-conforming product is not necessarily disqualified, but the procurement officer must document a determination that no conforming alternative exists or that an exception applies. Vendors with credible VPATs win procurement; vendors without them lose deals.

VPATs in private-sector procurement have become a default RFP requirement at large enterprises, healthcare systems, financial institutions, and educational institutions. The VPAT serves three procurement purposes: it lets the buyer compare vendors on accessibility, it shifts contractual risk to the vendor (the VPAT becomes a warranty), and it provides documentation if the buyer faces its own ADA or 1557 enforcement. A misrepresenting VPAT can produce both contractual breach and FTC unfair trade practice claims.

European Accessibility Act (Directive (EU) 2019/882) became enforceable June 28, 2025. The directive applies to specified products and services including consumer banking, e-commerce, e-readers, transportation booking, telecommunications, and audiovisual media services. Enforcement and penalties run through national implementing law, with monetary penalties varying by member state — Germany and France in particular have enforced substantial fines. A US-headquartered SaaS company selling into EU markets is within scope for any covered service.

ADA Title III attaches when the SaaS product is consumer-facing or when the SaaS provides the digital channel through which a place of public accommodation serves its customers. A B2B HR application used by job applicants is consumer-facing for the applicant population. A B2B property-management platform used by tenants for online rent payment is consumer-facing for the tenant. The vendor and the customer can both face Title III liability — and several recent cases have named both.

The hardest accessibility problems in SaaS UI

SaaS products encounter accessibility patterns that simpler websites do not. Complex data tables — the kind that power CRMs (Salesforce, HubSpot), analytics tools (Mixpanel, Amplitude), and project management apps (Asana, Linear, ClickUp) — combine sortable columns, expandable rows, inline editing, multi-row selection, and infinite scroll. WCAG 1.3.1 requires that all of those relationships be programmatically determinable. The native HTML <table> element with proper scope, headers, and aria-rowindex attributes is the right foundation; ARIA grid patterns extend it for complex interactions. Most SaaS implementations get this partially right and full-fail in specific corners — virtualized scrolling that drops aria-rowindex, sort controls without state announcement, inline-edit inputs without proper labeling.

Dashboard navigation patterns — left rail with collapsible sections, secondary tabs, breadcrumbs, search overlay — require careful ARIA work. The collapsible left rail in particular is often built as a custom widget without proper aria-expanded state, without keyboard support beyond Tab, and without focus management on collapse/expand. WCAG 2.1.1, 4.1.2 Name Role Value, and 4.1.3 Status Messages all apply.

Settings interfaces with deep nested menus — common in any sufficiently complex SaaS — frequently fail focus order (2.4.3) and visible focus (2.4.7). Modern design systems sometimes hide focus rings as a perceived aesthetic improvement; that single CSS choice fails 2.4.7 and is consistently cited in audit reports.

Drag-and-drop, real-time collaboration, and modal-heavy workflows

Drag-and-drop is the single most-failed interaction in SaaS accessibility. Native HTML5 drag-and-drop has no keyboard equivalent in any major browser, so any product that uses DnD as the primary interaction (Trello-style boards, Kanban workflows, Monday.com, Airtable, Asana, Notion drag-to- reorder) must implement an alternative input pattern. WCAG 2.5.7 Dragging Movements (added in WCAG 2.2) requires that functionality operable with dragging be operable with a single pointer without dragging — and the WCAG keyboard- operable requirements (2.1.1) require that the same functionality be available via keyboard. The common fix is an "Actions" menu on each draggable item that offers Move Up, Move Down, Move to Column X, etc. Many products lack this, even mature ones.

Real-time collaboration patterns — Figma, Notion, Google Docs, Linear, Coda — present a category of problems that WCAG was originally not written for. Multiple users simultaneously editing a shared document raises questions about how to announce remote changes, how to manage focus when another user's cursor enters the same region, and how to handle the constant DOM mutations that characterize collaborative editing. The pragmatic implementation pattern uses a debounced ARIA-live region for remote-edit announcements, keeps focus locked to the local user's input target, and provides keyboard shortcuts for navigating to other collaborators' cursors. Few SaaS products implement this well; Figma in particular has been the subject of accessibility complaints.

Modal-heavy workflows compound focus-management requirements. A product that opens a modal to open another modal (common in setup wizards, integration configuration flows, and bulk-action confirmations) needs to push and pop focus correctly through the stack, manage inert attributes on background content, and ensure keyboard escape unwinds in the right order. Most implementations get the first level right and fail on second-level modals.

Why SaaS is increasingly named in lawsuits and procurement disputes

Two trends drove the 2024-2026 increase in SaaS-specific accessibility risk. First, enterprise buyers stopped accepting boilerplate VPATs that consisted of generic "Supports" checkmarks against every criterion. Sophisticated procurement teams now require evidence: which specific feature areas were tested, which automated tools were used, which manual testing was performed, which assistive technologies were validated against, and what known issues remain. The shift is partly driven by the Atos v. Tyler Technologies dispute and similar public-sector breach claims where buyers alleged that the vendor's VPAT misrepresented actual conformance. Vendors who cannot back their VPATs are increasingly losing deals or facing post-sale remediation demands.

Second, the consumer-facing edge of B2B SaaS has expanded. HR application platforms (Workday, Greenhouse, Lever, iCIMS) present application forms directly to job seekers. Property management platforms (Buildium, AppFolio, Yardi RentCafe, RealPage) present resident portals to tenants. Healthcare scheduling (NexHealth, Tebra, Solv) presents booking flows to patients. Each of those consumer-touching surfaces creates Title III exposure for both the SaaS vendor and the customer. Several recent cases have specifically named applicant-tracking systems alongside the employer using them, and the resolution typically requires the SaaS vendor to remediate.

Reseller liability is the third factor. SaaS products distributed through resellers, marketplaces (AWS Marketplace, Salesforce AppExchange, Microsoft AppSource, Google Workspace Marketplace) inherit accessibility expectations from the marketplace operator's standards. Apple and Google have both removed apps from their stores for accessibility violations; AWS Marketplace and Salesforce AppExchange listings increasingly require VPAT submission.

Cost and timeline reality for B2B SaaS

SaaS remediation is more expensive than ecommerce because the surface area is larger (every screen of the product is in scope), the components are more complex (custom data tables, virtualized lists, drag-and-drop), and the engineering organization typically has to retrofit accessibility into a design-system foundation that did not include it. The work is also harder to amortize: enterprise buyers want VPAT updates with each major release, so accessibility becomes ongoing operational cost rather than a one-time project.

What to do today

Pull your most recent VPAT and read it critically. If it consists of "Supports" with no detail on testing methodology, what specific assistive technology was validated, and what known issues remain, you are at risk both in procurement (sophisticated buyers will reject it) and in litigation (a misrepresenting VPAT is itself actionable). Commission an honest audit, document specific issues with severity, and rewrite the VPAT to reflect actual conformance with explicit caveats.

Then identify your consumer-touching surfaces. Any flow where an end user (not your customer's administrator, but the actual person being served) interacts with the product is a Title III risk surface and a likely complaint source. Audit those flows first: applicant-tracking job application forms, tenant portal payment flows, patient scheduling, customer self-service. The B2B nature of the sale does not protect the consumer-facing path.

Finally, if you sell into the EU, confirm whether your product is within EAA scope. The directive's coverage list is specific and the national implementing laws have divergent enforcement profiles. Treating EAA as a US problem extension is a mistake; the conformance baseline (EN 301 549) overlaps heavily with WCAG but adds requirements that pure WCAG conformance does not satisfy.