Your marketing site passed the accessibility audit. Your actual product — the dashboard your paying customers live inside eight hours a day — has never been tested once.
That gap is one of the most common and most expensive blind spots in B2B software. And it's almost always invisible until someone outside your company goes looking for it.
The scenario every SaaS founder recognizes
Picture a SaaS founder getting ready for a Series B enterprise deal. Legal sends over a security and compliance questionnaire. Buried in it: "Please provide your current VPAT or accessibility conformance report."
The founder isn't worried. Eighteen months earlier, they'd hired someone to fix up the marketing site — the homepage, the pricing page, the blog — after a lawyer friend mentioned demand letters were getting more common. Contrast got fixed. Alt text got added. Box checked.
But the questionnaire isn't asking about the marketing site. It's asking about the product — the login flow, the dashboard, the settings panel, the reporting module the buyer's team will use every single day. Nobody has ever run a screen reader through any of it.
This is not a rare situation. It's the default situation. And it happens because marketing sites are public, easy to test with a browser extension, and the obvious target of a demand letter. The product sits behind a login wall, invisible to outside scrutiny — until an actual customer with a disability, or a procurement team's own compliance staff, tries to use it.
Why SaaS products fail WCAG differently than marketing sites
Marketing sites are mostly static content: headings, images, text, forms. A competent audit and remediation pass can get most of the way to WCAG 2.1/2.2 AA in a reasonable timeline.
SaaS dashboards are a different animal. They're disproportionately built from custom JavaScript components — dropdowns, modals, multi-step wizards, drag-and-drop builders, data grids, in-app notification systems — instead of native HTML elements like <select> or <button>.
That matters because of one specific success criterion: 4.1.2 Name, Role, Value, Level A. It requires that every UI component expose an accessible name, role, and state to assistive technology, either through native semantics or ARIA. A native <button> gets this for free. A custom <div> styled to look like a button, with a click handler bolted on, gets nothing — unless someone deliberately implements the ARIA attributes.
A custom dropdown with no role, no aria-expanded, and no keyboard handling isn't "hard to use" for a screen reader user. It's completely invisible. The user doesn't experience friction; they experience a wall they can't perceive was ever there in the first place.
The toast message problem
Here's a pattern almost every SaaS product has: the user clicks "Save," a small message flashes in the corner — "Changes saved" — and fades away after two seconds.
Sighted users get instant confirmation. Screen reader users, unless the developer specifically implemented 4.1.3 Status Messages (Level AA), get nothing. No sound, no focus change, no announcement. They're left wondering whether the save worked, whether they need to try again, or whether something silently failed.
The fix is a well-known pattern — an ARIA live region (aria-live="polite" or role="status") that announces the message to assistive technology the moment it appears. It's a small implementation detail with an outsized impact on whether a blind user can trust your product at all.
Data-dense screens need real structure, not just visual polish
SaaS dashboards are full of tables, charts, kanban boards, and calendars — interfaces designed to convey a lot of information at a glance. That density is exactly where accessibility tends to break down.
A sortable data table needs proper header markup and row/column association so a screen reader user can understand what each cell means without seeing the grid. A status column with a red dot for "failed" and a green dot for "healthy" — and nothing else — fails 1.4.1 Use of Color (Level A), because color is the only signal being used to convey meaning. That fails for colorblind users who can't reliably distinguish the dots, and it's invisible to a screen reader entirely, since color alone carries no text or programmatic information.
The fix isn't complicated: add a text label, an icon with a distinct shape, or both, alongside the color. It costs almost nothing in design terms and closes a real, common failure.
The Stat: WebAIM's annual "WebAIM Million" evaluation of the top 1,000,000 home pages has repeatedly found the vast majority — in recent years around 95-96% — have detectable WCAG 2 failures, with low-contrast text and missing alt text among the most common. If that's the state of public-facing pages that get scrutiny, authenticated product interfaces that get zero outside scrutiny are almost never better. (WebAIM: The WebAIM Million)
Why this shows up in your sales pipeline, not just your inbox
Enterprise B2B sales cycles increasingly run into accessibility as a procurement gate. Security and legal review teams at larger organizations are asking for VPATs (Voluntary Product Accessibility Templates) as standard due diligence — the same document category covered under Section 508 for government and government-adjacent buyers.
If your product hasn't actually been tested against WCAG, you have two bad options when that request lands: stall the deal while you scramble to test and remediate under time pressure, or hand over a VPAT that doesn't reflect reality and hope nobody checks. Neither is a good place to be three weeks before a signature.
The uncomfortable truth is that this risk compounds. A growing wave of demand letters targets public-facing sites first, because they're easy to scan from the outside. But roughly 1 in 4 U.S. adults live with some type of disability (CDC), and a meaningful share of them are also enterprise software buyers, IT staff, and end users inside the very companies your sales team is trying to close. The exposure isn't hypothetical — it's structural.
Where to actually start
You don't need to audit every screen in your product simultaneously. Start with the workflows a new customer actually uses in their first week:
- The signup and onboarding flow
- The primary dashboard or landing screen after login
- The most-used settings or configuration screens
- Any workflow your sales team demos live to prospects
That's both where legal exposure concentrates (it's what real users touch most) and where procurement questions actually get asked (it's what a VPAT reviewer or a trial-running buyer will click through first).
SaaS accessibility maturity: what "checked" actually looks like
| Maturity Level | Marketing Site | Authenticated Product | VPAT / Procurement Readiness |
|---|---|---|---|
| Level 0 — Unchecked | Never tested | Never tested | No VPAT, no answer if asked |
| Level 1 — Surface Pass | Contrast/alt text fixed | Untested | VPAT would be guesswork |
| Level 2 — Product-Aware | WCAG AA audited | Core flows spot-checked | Partial VPAT, gaps documented |
| Level 3 — Procurement-Ready | WCAG AA audited | Core workflows tested with screen reader + keyboard | Accurate VPAT, ready for legal review |
Most companies with a polished marketing site are sitting at Level 1 and assuming they're at Level 3. That gap is exactly what a procurement review — or a plaintiff's attorney's technical consultant — is built to find.
Get your product tested, not just your homepage
An accessibility pass on your marketing site is a good start, but it answers a different question than the one your enterprise buyers, your existing customers with disabilities, and eventually a demand letter will actually ask. The product is where the real exposure lives, and it's where almost nobody looks first.
Get your actual product audited, not just your marketing site. Talk to WCAG.World about a full authenticated-product accessibility review — covering your onboarding flow, dashboard, custom components, and the ARIA implementation your VPAT will actually need to stand behind.