Accessibility in B2B SaaS: What WCAG 2.2 AA Compliance Actually Requires

WCAG guides are typically written for marketing sites, with color contrast on a homepage and alt text on a blog. But a B2B SaaS product has a different accessibility problem entirely. The failure points are custom dropdowns, live-updating dashboards, drag-to-reorder lists, and multi-step workflows that a generic accessibility checklist fails to address.

WCAG 2.2 AA compliance means meeting 55 success criteria: everything from 2.0 and 2.1, plus six new additions. For B2B SaaS, four matter most: keyboard focus visibility, dragging alternatives, minimum target size, and accessible authentication. These are the patterns custom product interfaces get wrong far more than marketing sites do. Accessibility is also now part of enterprise procurement and vendor security review, not just a legal risk. That means gaps can cost you a deal before they ever cost you a lawsuit.

Why WCAG guidance written for websites doesn't transfer cleanly

Generic WCAG checklists are built around content, and a B2B SaaS product is built around interaction: custom components, real-time data, and workflows that span multiple screens and states. Most of the accessibility gaps that show up in SaaS products aren't things a content-focused checklist catches, because the failure is in the interaction pattern itself.

That gap matters because product teams often assume a marketing-site accessibility audit covers the product too, but it doesn't. A custom dropdown, a drag-and-drop kanban board, or a dashboard that updates without a page reload all need their own accessibility treatment that a page-level checklist was never built to catch.

What WCAG 2.2 AA adds, and why it hits SaaS products hardest

WCAG 2.2 added six new success criteria at Level AA, and several of them map directly onto patterns common in B2B SaaS interfaces.

Focus visibility with sticky UI. When a user tabs through a page, the focused element can't be hidden behind a sticky header, a chat widget, or a fixed footer. SaaS products are full of sticky navigation and persistent panels, which makes this a far more common failure point in a product than on a typical marketing page.

Dragging alternatives. Any interaction that relies on a drag gesture, whether reordering a list, resizing a column, or moving a card between columns, needs a way to complete that action without dragging. Drag-based interactions show up constantly in SaaS product UI (kanban boards, file managers, dashboard customization) and rarely on marketing sites, which is why this criterion catches so many product teams off guard.

Minimum target size. Interactive elements need to be at least 24 by 24 CSS pixels, or have enough spacing around them, unless a specific exception applies. Dense product interfaces, especially data tables and toolbars packed with icon buttons, are where this criterion gets violated most often, since the instinct in dense UI is usually to shrink targets to fit more in.

Accessible authentication. Login flows can't rely purely on a user's ability to remember, solve, or transcribe something, unless an alternative method is also offered. This applies directly to every SaaS product's login and account recovery flow, an area consumer-facing marketing sites don't have to think about at all.

Why this is increasingly a procurement issue, not just a legal one

WCAG compliance is usually framed around litigation risk, and that risk is real. What gets less attention is how much it's become a procurement checkbox for enterprise buyers evaluating SaaS vendors. Security and vendor review processes at larger companies increasingly ask for accessibility conformance documentation alongside SOC 2 reports and data handling policies, before a deal ever reaches a courtroom.

That shift has been reinforced at the standards level. WCAG 2.2 was formally approved as an ISO/IEC international standard in October 2025, which makes it easier for more countries and procurement frameworks to formally reference it going forward. For a B2B SaaS company selling into enterprise accounts, that trend line points toward accessibility conformance becoming a more common item on a vendor questionnaire.

What this means for product teams

Treat accessibility as part of the interaction design process. The criteria that matter most for SaaS products (focus visibility, drag alternatives, target size) are interaction-level decisions, which means they're far cheaper to get right during design than to retrofit after a component ships. Building accessibility into the product design process itself catches these patterns before they reach engineering.

Audit custom components specifically. A generic page-level scan will miss most of what breaks in a SaaS product, since the failures live inside components: the custom multi-select, the drag-to-reorder list, the dense data table. Component-level review catches what page-level scanning doesn't.

Have an answer ready before a prospect asks. Enterprise buyers increasingly include accessibility conformance in vendor security and procurement review. A company that can point to a specific WCAG 2.2 AA conformance statement moves through that step faster than one that's answering the question for the first time in a deal cycle.

Ready to build accessibility into your product from the start?

At BRIGHTSCOUT, our app development team designs and builds interaction patterns, custom components, drag interactions, and dense interfaces, all with WCAG 2.2 AA requirements built in from the start.

Let's talk about what your product needs.