WCAG 2.1 AA checklist for B2B SaaS: 20 criteria to audit

Most accessibility audit checklists on the public web are written for marketing sites — hero sections, blog posts, contact forms. B2B SaaS products are different. The user journeys that matter are behind a login: dense dashboards, multi-step wizards, filterable data tables, modal flows, keyboard shortcuts. A WCAG 2.1 AA checklist that ignores those patterns will pass your homepage and miss every screen your customers actually use.

This is a 20-criterion checklist scoped specifically to B2B SaaS interfaces. It maps each item to the relevant Web Content Accessibility Guidelines (WCAG) success criterion and the UI pattern where it most commonly fails. It is the audit list we run when verifying conformance against the European Accessibility Act baseline, which adopts WCAG 2.1 AA as the legal floor for in-scope digital services.

Why B2B SaaS needs its own accessibility audit

The EAA brought private-sector digital accessibility under EU law in June 2025, and the first wave of enforcement activity is now visible across France, Germany, and the Nordics. Most of the early scrutiny has landed on consumer-facing sites — e-commerce checkouts, banking portals, transport booking — because they sit cleanly inside the EAA’s product/service categories.

B2B SaaS sits in a more contested zone. If your product is sold to businesses but the end user is an individual employee performing a consumer-like transaction (booking a flight on a corporate travel platform, viewing a payslip, applying for a job), the EAA applies. Even where it does not directly apply, two things matter: large enterprise buyers now demand a Voluntary Product Accessibility Template (VPAT) or equivalent accessibility statement as part of procurement, and the WCAG 2.1 AA baseline is the standard those documents are evaluated against.

The audit criteria below are organised by the UI patterns most common in SaaS — not by WCAG principle number — because that is how engineering teams actually fix things.

The accessibility audit checklist for B2B SaaS

Login, sign-up, and authentication flows

1. Keyboard-only completion (WCAG 2.1.1 Keyboard). Every step of the sign-in flow — including SSO redirects, MFA prompts, and password-reset links — must be completable with Tab, Shift+Tab, Enter, and Space. No mouse-only widgets.

2. Visible focus indicator (WCAG 2.4.7). The default browser focus ring is often killed by global CSS resets. Restore it, or replace it with an indicator that meets the 3:1 contrast minimum against both states it sits over.

3. Error identification (WCAG 3.3.1). When a login fails, the error message must be programmatically associated with the offending field (aria-describedby or inline text linked to the input), not just shown as a banner the screen reader will not read in context.

4. Time-limited sessions warned (WCAG 2.2.1). If the session times out, warn the user at least 20 seconds before expiry and offer an “extend” option. Silent forced logouts during form fills are a recurring source of complaints.

Dashboards and data-dense screens

5. Logical heading order (WCAG 1.3.1). A typical SaaS dashboard ships with five widgets and no headings at all — everything is a div. Each card or section needs a real h2/h3, and the order must reflect the visual reading order, not the DOM accident.

6. Landmark regions (WCAG 1.3.6 / 4.1.2). nav, main, aside, header, footer — or their ARIA equivalents. A screen-reader user navigating a complex dashboard needs landmarks to jump between regions; otherwise the only way through is line-by-line.

7. Text resize without breakage (WCAG 1.4.4). Set the browser default to 200%. Your dashboard should still be usable — text not clipped, controls not overlapping, horizontal scroll only on data tables (not on the chrome).

8. Charts have text alternatives (WCAG 1.1.1). Every chart, sparkline, or progress visual needs either a summary table or descriptive prose nearby. “Revenue chart” as an alt is not a text alternative; the data is.

Data tables and filtering

9. Proper table semantics (WCAG 1.3.1). Real <table> with <th scope="col"> and <caption>. Grids built from <div> need role="grid" plus the full ARIA grid pattern; in practice, native tables are easier to ship correctly.

10. Sortable column state announced (WCAG 4.1.2). Sort buttons in column headers must expose aria-sort="ascending|descending|none". The visual triangle alone tells a sighted user; the ARIA state tells everyone.

11. Filter and search results announced (WCAG 4.1.3). When the user applies a filter and the row count drops from 412 to 7, an aria-live="polite" region should say so. Otherwise the user types into a search box and hears nothing back.

12. Bulk-action controls keyboard-reachable (WCAG 2.1.1). The “select all” checkbox and the bulk-action dropdown are commonly Tab traps or Tab-skipped entirely. Verify both directions.

Forms, modals, and wizards

13. Labels and instructions (WCAG 3.3.2). Every input has a <label> or aria-labelledby. Placeholder text is not a label. Hint text and format requirements are exposed before the user errors, not only after.

14. Required-field markers programmatic (WCAG 1.3.1). The visual * becomes aria-required="true" or a textual “required” inside the label. A red asterisk alone is invisible to assistive technology.

15. Modal focus management (WCAG 2.4.3). Opening a modal moves focus into it; closing returns focus to the trigger element. Tab is trapped inside the modal while open. Escape closes it.

16. Wizard step indicators (WCAG 2.4.8 / 4.1.3). Multi-step flows expose the current step and total via aria-current="step" on the active item; transitions between steps announce the new step’s heading.

Navigation, links, and global UI

17. Skip-to-content link (WCAG 2.4.1). The first focusable element on every authenticated page is a “skip to main content” link that becomes visible on focus. Saves screen-reader and keyboard users from re-traversing the navigation on every page load.

18. Distinguishable link text (WCAG 2.4.4). No “click here”, no “learn more”. The link text describes the destination. This is also where in-app help text most often fails an audit.

19. Colour-contrast minimums (WCAG 1.4.3 / 1.4.11). Text against background: 4.5:1 for body, 3:1 for large text. Non-text UI (focus rings, input borders, icon-only buttons): 3:1 against adjacent colours. The disabled-state grey is the most common quiet failure.

20. Motion and animation respect (WCAG 2.3.3). Honour prefers-reduced-motion. Skeleton shimmers, autoplay carousels, and parallax effects that ignore the user preference are vestibular hazards and a recurring audit finding.

How do you actually run this checklist?

Manual testing catches what automated checks cannot: context-dependent errors, alternative text quality, focus order logic, the “is this colour actually used to convey meaning” question. Reserve a focused half-day per major flow (sign-in, primary dashboard, the top three data tables, the most-used form) and walk each criterion.

Automated checks catch the high-volume mechanical issues — missing labels, contrast failures, ARIA misuse — across every screen in your product on every commit. Industry benchmarking has long converged on the figure that automated rules catch roughly 30–40% of WCAG issues; the rest is human judgment work. The two are complementary, not substitutes.

A B2B SaaS product with even a moderately complex UI will accumulate accessibility regressions faster than a half-yearly external audit can catch. Continuous coverage on the mechanical 30–40% is how you keep the manual audit cycle focused on the work that actually needs human eyes.

A practical next step

If you want a baseline against the items above without setting up tooling, run a free accessibility and privacy compliance audit on Elgarde. The platform evaluates your public surfaces against WCAG 2.1 AA — colour contrast, ARIA semantics, focus indicators, alt text, form labelling — and surfaces each finding with the specific success criterion and remediation pointer, so the engineering work to close the gap is concrete rather than abstract. The full WCAG 2.1 specification, including the precise wording of each success criterion referenced above, is published by the W3C Web Accessibility Initiative.