Use AI to summarize this article
There is a moment in an enterprise deal that almost no SaaS founder sees coming.
The deal is sitting in legal. Security review is done. The economic buyer is nodding along. Then procurement sends one email: "Can you share your VPAT and confirm your site meets WCAG 2.1 AA?"
And the room goes quiet. Because most companies at seed or Series A have never heard the acronym, have never run an audit, and have no idea their marketing site is about to get scored against a checklist they have never read.
Here is the uncomfortable part. If they did run that audit, it would surface the same handful of failures that show up on nearly every B2B SaaS site. The 2026 WebAIM Million report scanned the top one million homepages on the web and found that the vast majority carried detectable WCAG failures, with low contrast text alone appearing on 83.9% of them. These are not exotic bugs. They are the same six or seven issues, repeated across the web, year after year.
This post walks through the seven that matter most on a SaaS marketing site, in plain language, and maps each one to what enterprise procurement actually checks. It is written for two people: the founder who just got the VPAT email and needs to know what they are looking at, and the marketing or engineering lead who would rather build it right the first time than patch it under deadline.
Why procurement suddenly cares about your marketing site
Five years ago, enterprise accessibility reviews looked at the product and ignored the marketing site. That has flipped, for three reasons.
Legal exposure got wider:
WCAG applies to public websites, not just the logged-in app. ADA-based digital accessibility lawsuits have become one of the fastest-growing categories of civil litigation in the US. UsableNet, which has tracked these cases for six years, counted more than 5,000 digital accessibility lawsuits filed in 2025, and has logged over 4,000 every year since 2021. Most of those target ecommerce, but the precedent has made every legal and compliance team nervous about the vendor sites they sign off on.
The checklists got systematic:
Banks, hospitals, universities, government contractors. They have all standardized vendor onboarding, and an accessibility attestation is now a line item in it. The question is no longer "is your product accessible." It is "has this company shown it takes accessibility seriously across everything it puts in public."
It reads as a quality signal:
Experienced procurement people have spotted a pattern. Companies that ignored accessibility on the marketing site usually ignored it in the product too. So a homepage full of contrast failures gets treated as a proxy for how mature the rest of the engineering is. Fair or not, that is the read, and you do not get to argue with it during a deal.
The combined effect: accessibility moved from a post-close cleanup task to a pre-close gate, especially in financial services, healthcare, education, and anything touching a government contract.
The standard, in one paragraph
WCAG is maintained by the W3C and built on four ideas: content should be Perceivable, Operable, Understandable, and Robust. There are three conformance levels, A, AA, and AAA. Enterprise procurement almost always asks for 2.1 AA. AAA is aspirational and nobody requires it across a whole site. A-only is not enough for regulated buyers. WCAG 2.1 AA has 50 success criteria in total, 25 at Level A and 25 at Level AA. The seven failures below are the ones that break most often on SaaS sites, and the ones tied most directly to whether a deal keeps moving.
The 7 WCAG failures on most SaaS sites
Failure 1: Text without enough contrast (WCAG 1.4.3)
The rule is simple. Normal text needs a contrast ratio of at least 4.5:1 against its background. Large text (18pt, or 14pt bold) needs 3:1. That is what keeps text readable for people with low vision or colour vision deficiency.
The most common violation in B2B SaaS is light grey body text on white. A hex like #999999 on white lands at roughly 2.85:1, well under the line. Muted secondary buttons fail. Form placeholder text fails almost universally, because it is designed to look faint. A slate-grey "Book a Demo" button, a light-grey hero subhead, the tiny "Already a customer? Sign in" link at the bottom of a pricing page. All readable to you, all illegible to the roughly 8% of men with some colour vision deficiency and the much larger group dealing with glare on a phone in daylight.
Contrast is also the single most-checked criterion in automated procurement scans, because tools like axe, WAVE, and Lighthouse flag it on their own and spit out a report a procurement officer can read without any accessibility training. Multiple contrast failures produce a report that looks, to them, like a company that has never run a single check.
Fix complexity: low. A palette audit and correction takes a few hours. No redesign. You darken the affected values in the design system by 20 to 40% and move on.
Failure 2: Missing or useless alt text on images (WCAG 1.1.1)
Every non-decorative image needs a text alternative that conveys the same information. That is what lets screen reader users understand what an image is doing on the page.
On SaaS sites it breaks in predictable ways. Customer logos with alt text that just says "logo." Product screenshots with no alt text, or worse, the raw filename like "screenshot-2024-03-14.png." Hero images described by appearance ("person smiling at laptop") instead of purpose. Functional icons, like the mobile menu button, with nothing at all. A screen reader hitting a logo wall with missing alt attributes reads "image, image, image, image," which tells the user nothing.
In audits, alt text is the second most-flagged item, and it gets noted as systemic rather than isolated, because alt text is added by a content process, not page by page. Widespread failures signal an accessibility-blind content workflow, which procurement reads as "their docs will need remediation before our team can use them."
Fix complexity: medium. Fixing existing alt text is quick. Building a process so new images get it too takes a small workflow change.
Failure 3: Form fields without real labels (WCAG 1.3.1 and 3.3.2)
Inputs need labels that are both visible and programmatically tied to the field. The classic mistake is using placeholder text as the only label. It vanishes the moment someone starts typing, and then the field has no label at all. A screen reader user who tabs in cannot tell what is expected. Someone with short-term memory difficulty who looks away mid-form cannot find their place when they look back.
This one stings more than the others, because forms are your conversion path. An enterprise buyer whose assistive tech cannot complete your demo form is a lost prospect before a single sales conversation. And a procurement note that says "demo form is inaccessible" becomes a formal record of non-compliance that can stall approval.
Fix complexity: low to medium. Adding proper <label> elements (or aria-label where a visible label does not fit) is under a day of dev work on most sites.
Failure 4: Keyboard navigation that dead-ends (WCAG 2.1.1 and 2.4.7)
Everything you can do with a mouse has to work with a keyboard, and the focused element has to be visibly marked. This covers users with motor disabilities, switch-device users, and plenty of power users who navigate by keyboard for speed.
Where it breaks: nav menus that will not open or close by keyboard. Modals (demo overlays, cookie banners, video lightboxes) that do not trap focus, so a keyboard user tabs behind them into dead content, or cannot reach the close button. Custom dropdowns built with no keyboard handling. And the worst offender, outline: none slapped on globally, which strips the focus ring and leaves keyboard users with no idea where they are on the page.
This is the failure procurement weights most heavily, because it affects the broadest group. A reviewer who tabs through your site and hits a wall is unlikely to approve you without a written remediation commitment.
Fix complexity: medium to high. It is CSS (restore focus indicators) plus JavaScript (keyboard handlers, focus trapping). A good front-end dev clears most of it in one to three days. Big custom component libraries take longer.
Failure 5: Videos without captions (WCAG 1.2.2)
Any prerecorded video with audio needs captions. That covers your homepage product demo, customer testimonial clips, hero videos with narration, and embedded webinar recordings.
A deaf user lands on your product walkthrough, sees the video, and leaves with an incomplete picture of what you do. So does anyone in an open office who has muted their browser, which is a far larger group than people with permanent hearing loss. Captions are assessed directly in Section 508 audits (required for federal vendors, increasingly adopted by state contractors and public institutions) and under Title II of the ADA for educational buyers.
One catch worth knowing: auto-generated captions alone do not meet 1.2.2. They have to be reviewed and corrected for accuracy.
Fix complexity: low for new content (build captioning into production). Medium for a back catalogue (auto-caption with a tool, then have a human clean it up).
Failure 6: Broken heading structure (WCAG 1.3.1 and 2.4.6)
Headings have to reflect actual content hierarchy, not just font size, and they have to describe what follows. Screen reader users navigate by heading, so this is core to whether your page is usable at all by assistive tech.
The usual mistakes: multiple H1s on one page, H2s used purely to make a line look big, skipped levels (H1 straight to H3), section headers built as styled divs with no heading markup, and vague heading text like "Section 2." A screen reader user pulling up the heading list on a pricing page cannot tell which headings are real navigation points and which are just decorative emphasis. The structure that should help them navigate becomes noise.
Fix complexity: low. These are HTML changes, no visual redesign. A heading audit is usually under a day.
Failure 7: No skip navigation link (WCAG 2.4.1)
There has to be a way to skip past the blocks repeated on every page. In practice that is a "Skip to main content" link a keyboard user can hit to jump past the nav straight to the page content.
It is missing from the vast majority of SaaS sites, which is strange, because it is one of the easiest criteria to satisfy. Probably because it is invisible to sighted users (it only appears on focus), so it never gets caught in visual QA. The cost of skipping it: a keyboard user landing on a homepage with eight nav items, two dropdowns, and a language selector has to tab through all of it before reaching the headline, and then repeat that on every page in the session.
For reviewers, this is the fastest tell there is. Press Tab on page load, see if a skip link appears. Thirty seconds. Its absence is treated as proof that keyboard accessibility was never considered, which then casts doubt on everything else.
Fix complexity: very low. Ten to fifteen lines of HTML and CSS, zero visual impact on sighted users. The cheapest accessibility win available.
What actually gets checked in a procurement audit
Reviews run from a ten-minute scan to a multi-day formal audit. Knowing the tiers tells you what to fix first.
The pattern across all three: a self-attested VPAT that claims more than you have tested is not a compliance document. It is a liability document. If a buyer later audits the product and finds failures you marked as supported, that VPAT becomes evidence of misrepresentation. An honest VPAT with "Partially Supports" entries and a dated remediation plan is both more credible and more defensible than one that overclaims.
The pre-VPAT checklist
Before you send a VPAT or answer a procurement questionnaire, run these checks. The first few you can do in a browser in ten minutes. The rest need a manual keyboard pass.
What this means for a Webflow or custom build
Accessibility failures are not random. They cluster around specific build decisions.
In Webflow, the markup is semantically clean by default, which handles a lot of the structural criteria for free. The failures that do creep into Webflow builds are predictable: global CSS that kills the focus ring, forms built with placeholder-as-label, and animations shipped without a prefers-reduced-motion fallback (which matters for people with vestibular disorders). A Webflow build that has been accessibility-reviewed almost always outscores a custom site that has not.
In custom builds, the damage usually happens at the component library. Dropdowns, modals, tooltips, and accordions built without keyboard handling, ARIA, or focus management. Fixing those after launch means refactoring at the component level. Building them right from the start, using the ARIA Authoring Practices patterns, costs roughly 20 to 30% more dev time and erases the remediation bill entirely.
[INSERT Component 14: Suggested Read here]
At Flowtrix, accessibility is part of the Webflow build process, not an audit we run after launch. The sites we ship pass Tier 1 automated scans on day one, and they carry the structural foundations (semantic headings, programmatic form labels, skip nav, visible focus) that Tier 2 manual reviews look for. For clients with enterprise procurement ahead of them, we produce a VPAT-ready conformance report as part of the launch deliverable, so the first time procurement asks, the answer already exists. It is the same approach behind the enterprise builds we have shipped for companies like Databahn and Akirolabs.
The seven failures in this post are all fixable. Five of them need no design work at all. The only real mistake is waiting until a procurement checklist forces the issue, because by then you are fixing under a deadline instead of building it in.
.avif)
.svg)
.svg)
