SaaS accessibility is a product problem, not a page problem
A brochure website has a few dozen static pages. A SaaS product has an interface — dashboards, data tables, multi-step wizards, modals, comboboxes, and real-time updates that change as the user works. That’s why accessibility for software is a different job: the barriers aren’t in your marketing copy, they’re baked into the React, Vue, or Angular components your whole product is assembled from. Curbcut remediates those components in the actual codebase to WCAG 2.1 AA, by hand, and documents the result so it survives an enterprise procurement review — never with an overlay.
The barriers live in your custom components
Most of what breaks in a web app shares one root cause: teams build interactive controls out of generic div and span elements that carry no semantic meaning. A native <select> or <button> tells a screen reader its name, role, and current state for free. A hand-rolled equivalent tells it nothing unless a developer adds — and maintains — the right ARIA.
WCAG 4.1.2 Name, Role, Value is the success criterion that governs this, and it’s the one SaaS products fail most. Per the W3C’s understanding document, every interactive component must expose a programmatic name, role, and value that updates as its state changes. The recurring offenders:
- Custom dropdowns and comboboxes that announce nothing, or trap focus so a keyboard user can’t close them
- Data grids with sortable columns and inline editing that never expose sort state or cell relationships
- Modals and side panels that don’t move focus on open, trap it while open, or return it on close
- Toggles, steppers, and sliders missing
aria-checked,aria-valuenow, or a Space/Enter handler - Drag-and-drop kanban boards and reorder lists with no keyboard alternative at all
- Toasts, loaders, and live regions that update silently, so a blind user never learns the save succeeded
Each has an established pattern in the W3C ARIA Authoring Practices Guide, with defined keyboard interactions and ARIA roles. The fix isn’t a script — it’s correct implementation of the right pattern, then verification with a real screen reader. For the techniques, see our guides on ARIA labels and roles and keyboard navigation.
The dashboard behind the login is the highest-risk surface
Marketing pages are the easy part. The product itself — onboarding, the dashboard, settings, billing, admin consoles — is where SaaS accessibility lives or dies, and it’s exactly where scanners and overlays can’t reach because they never log in.
A real audit runs against a credentialed account and walks the flows a disabled employee or a procurement tester would actually use: can you complete onboarding with a keyboard alone? Does the dashboard’s data table work with NVDA? Can a JAWS user understand a chart, or is the data locked in an unlabeled SVG? Are billing-form errors announced, or only shown in red? These map to the POUR principles — Perceivable, Operable, Understandable, Robust — and none get tested if you only scan the homepage.
VPATs, Section 508, and why procurement is your real deadline
For most SaaS companies, the forcing function isn’t a lawsuit — it’s a sales blocker. Enterprise, university, and government buyers increasingly won’t sign until you hand over a VPAT.
Under Section 508 of the Rehabilitation Act, federal agencies must buy information and communication technology that is accessible, and the Accessibility Conformance Report — the completed VPAT — is how a vendor proves it. Per Section508.gov, agencies generally can’t proceed with a purchase without one, measured against WCAG 2.1 Level A and AA. State and local buyers carry the same expectation: the DOJ’s 2024 ADA Title II rule adopted WCAG 2.1 AA for public entities’ web and mobile services — including services delivered through third-party providers like your SaaS — so when an agency procures your software, your conformance becomes their compliance problem.
Here’s the trap: a VPAT is a self-attestation, and an inaccurate one is worse than none — claim “Supports” on criteria you actually fail and you’ve built a paper trail of misrepresentation. That’s why a credible report has to rest on a manual audit, not a scan. We produce yours through the VPAT / conformance report service after testing the real product.
The EU deadline has already passed
If you sell into Europe — and most SaaS does — the European Accessibility Act is now live. Per the European Commission, the EAA’s compliance date was 28 June 2025, it applies to providers serving the EU market regardless of where they’re headquartered, and it points to EN 301 549, which incorporates WCAG 2.1 AA. For a US-based company with European customers, “we’re not an EU company” is no defense. (This is general information, not legal advice — consult a qualified attorney about your exposure.)
Why SaaS gets sued — and why overlays make it worse
Software is a lawsuit target for the reason it’s hard to fix: it’s full of transactional, interactive surfaces. When the DOJ settled with online-course provider edX, the agreement required conformance to WCAG 2.0 AA across not just the website but the mobile apps and the Studio content-management system — the authoring tool itself — recognizing that a platform’s accessibility includes the tools customers use inside it (see the settlement agreement). For multi-tenant SaaS, that’s pointed: your customers’ accessibility can hinge on whether your components are sound.
Hundreds of web-accessibility lawsuits and far more demand letters are filed every year, and overlay widgets have become a specific tell that a product isn’t genuinely accessible. They can’t be the answer for software: they never touch your component code, they conflict with the assistive tech your users run, and they can’t fill in a VPAT. See overlay vs manual remediation and our serial ADA plaintiffs breakdown.
Why manual remediation is the only honest answer for software
Automated scanners detect only about 30–40% of WCAG issues — the programmatic ones like missing alt text and contrast. The criteria that matter most for web apps — whether a custom combobox works with a keyboard, whether a modal manages focus, whether a live region announces — sit in the majority that require human testing with NVDA, JAWS, and VoiceOver. A scan that “passes” can still leave your dashboard unusable.
Curbcut delivers durable fixes in your real codebase, component by component, so a button or data table fixed once is correct everywhere it’s reused. Our process:
- Audit. Manual plus automated testing of your marketing site and logged-in app flows against WCAG 2.1 AA, with real assistive technology and keyboard-only walkthroughs.
- Remediate. Hands-on fixes to your components, ARIA patterns, focus management, and forms — prioritized by user impact and procurement risk.
- Document. A defensible VPAT / ACR and accessibility statement you can hand to buyers.
- Monitor. Optional ongoing monitoring so a new feature release doesn’t reintroduce barriers into your design system.
Get started
The fastest way to see where your product stands is to look at it. Start with a free accessibility scan of your public surface, then contact us to scope an audit that includes your authenticated app. For authoritative background, see ADA.gov, the W3C Web Accessibility Initiative, and Section508.gov. [EXPERT_NAME] and the [AGENCY_NAME] team will show you exactly which components are blocking your buyers — and fix them for real.