Most accessibility statement guidance is written for a public-facing website: a marketing homepage, a blog, maybe a signup form. A SaaS product has that surface too, but it also has a second, much larger one that most published statements never mention: the authenticated dashboard a paying customer lives in after they log in. Settings pages, data tables, in-app wizards, drag-to-reorder lists, keyboard shortcuts. That is where WCAG 2.2’s newest success criteria matter most, and it is also the surface a company’s own accessibility statement is least likely to actually cover.
The Marketing Site and the Dashboard Are Different Accessibility Problems
A marketing site is mostly static content: headings, paragraphs, images, a pricing table, a signup form. It changes on a redesign cycle, maybe once or twice a year. Once a visitor becomes a customer and logs in, the interface changes shape entirely: dense data tables, modals, dropdown menus built from custom components rather than native HTML controls, and a release cadence measured in sprints, not redesigns. A statement that says “our site conforms to WCAG 2.2 Level AA” after an audit of the marketing pages is telling the truth about a small share of what a paying account actually uses. It is also the surface most likely to matter first in a complaint, because the person filing it is usually describing something they could not do inside the product they pay for, not something they could not read on the homepage.
The fix is not a second, separate statement. It is scoping the existing one honestly: naming the conformance target for both the public site and the logged-in application, and being explicit when the audit only covered one of them. A statement that is silent about the dashboard reads, to anyone who checks, as though the dashboard was never tested at all, which is often exactly what happened.
What WCAG 2.2 Added That Matters Most Behind the Login Wall
WCAG 2.2 added new success criteria on top of 2.1, and the ones added at Level A and AA, the levels almost every conformance statement actually targets, line up disproportionately with what a dashboard does rather than what a marketing page does: drag interactions, small icon-only buttons packed into table rows, focus that gets covered by sticky headers, multi-step forms, and login or two-factor screens.
WCAG 2.2 Criteria Most Relevant to a Dashboard
| What It Requires | Dashboard Failure | |
|---|---|---|
| 2.4.11 Focus Not Obscured | Focused element can't be fully hidden | Sticky filter bar covers the focused row |
| 2.5.7 Dragging Movements | Drag actions need a non-drag option | Kanban reorder only works by mouse drag |
| 2.5.8 Target Size Minimum | Targets at least 24x24 CSS pixels | Icon-only row actions in a dense table |
| 3.2.6 Consistent Help | Help stays in the same relative spot | Support widget moves across pages |
| 3.3.7 Redundant Entry | No re-asking for the same info | Wizard repeats a field across steps |
| 3.3.8 Accessible Authentication | No memorize-and-transcribe-only login | 2FA field blocks paste, forces retyping |
None of these six are exotic edge cases. They describe patterns that show up constantly in dashboard UI because dashboards are built from custom interactive components in a way a mostly-text marketing page rarely is.
Where These Failures Actually Show Up
Drag-to-reorder is the clearest example: a kanban board, a saved-view list, or a dashboard-widget layout that can only be rearranged by clicking and dragging with a mouse fails 2.5.7 outright, and the fix is usually a “move up” and “move down” button or a “move to position” menu sitting alongside the drag handle, not a redesign of the whole feature. Icon-only row actions are the second most common one: a table with edit, duplicate, and delete icons crammed into a 32-pixel-wide column often renders each icon’s actual clickable area well under the 24x24 pixel minimum, especially once table density gets tuned to fit more rows on screen. Sticky elements are the third: a filter bar or table header that stays pinned while a keyboard user tabs through rows can end up covering the very row that currently has focus, which is exactly the failure 2.4.11 was added to catch.
The authentication criterion deserves its own mention because it is easy to get backwards. 3.3.8 does not ban two-factor authentication. It bans requiring a user to solve a cognitive puzzle, memorizing a code and retyping it from memory, transcribing it character by character with no way to paste, as the only path through login. A 2FA flow that accepts a pasted code, supports an authenticator app’s autofill, or offers a passkey or email-link alternative satisfies the criterion; one that disables paste on the code field “for security” and offers no other route does not, regardless of how strong the underlying security design is.
Scoping and Maintaining the Statement Across Both Surfaces
A statement that names one conformance target and one audit date for the whole product, when only the marketing pages were tested, is not lying exactly, but it is not describing the product a logged-in customer actually uses either. Naming the dashboard as a separately scoped surface, even briefly, “this statement covers both our public site and our authenticated application; the two are reviewed on different schedules,” is a small addition that closes a real gap.
Writing the Limitations Section for Logged-In Screens
The limitations section is where a dashboard statement earns or loses credibility, and vague language does the same damage here that it does anywhere else in the document.
- Names one conformance target for the whole product
- No mention of the logged-in application separately
- Limitations list describes the marketing site only
- Last-reviewed date predates several recent feature releases
- States WCAG 2.2 AA conformance for both public and authenticated screens
- Names the specific dashboard components not yet tested, by screen
- Explains the accessible alternative offered for drag actions and 2FA
- Review date tied to the release cycle, not a fixed calendar date
Name the actual components rather than the product as a whole: “the saved-view drag-to-reorder list has not yet been tested against 2.5.7,” not “some features may not be fully accessible.” This is also where a generated statement saves real drafting time over a blank page: our Accessibility Statement generator prompts for conformance target, known limitations, and a feedback contact as required fields, so a team documenting dashboard-specific gaps has a structure to fill in rather than a paragraph to invent from scratch.
Review Cadence for a Product That Ships Every Week
A marketing site can reasonably run on an annual or biannual review cadence tied to redesigns, because the content underneath the statement barely moves between reviews. A dashboard cannot, because new screens, new table columns, and new interactive components ship on every sprint, and a statement reviewed once every twelve months is describing an interface that has changed underneath it dozens of times since the last check. The practical fix most product teams land on is not reviewing the statement after every deploy, that is not realistic either, but building an accessibility check into the release process for any new interactive dashboard component (a new drag interaction, a new icon-only control, a new multi-step flow) and updating the statement’s limitations list on a fixed shorter cycle, often quarterly, that reflects what actually shipped rather than resetting the clock to a full annual audit each time.
A dashboard’s accessibility statement is not a different document from a marketing site’s. It is the same disclosure discipline, name the target, list the real gaps, give a working contact, applied to a much more complex and much faster-changing interface. For the general version of this document and what ADA, WCAG, and EN 301 549 each expect from it, see how to write an accessibility statement that meets ADA and WCAG expectations; if the product also runs a public storefront or checkout, the ecommerce-specific version of this guide covers the retail equivalent of the same problem.
