How to audit a staging site for accessibility
Ask any team where their accessibility issues get discovered and the honest answer is usually "in production, by someone else." The irony is that almost every one of those issues existed on staging for weeks, sitting behind a VPN or a basic-auth prompt where no scanner ever looked. Auditing pre-release environments is the single most valuable accessibility habit a team can adopt, and it is mostly a tooling problem. This guide is the process.
Why staging is a blind spot
Crawl-based accessibility scanners work from public URLs. Point one at staging.client-project.dev and it hits an HTTP 401, a VPN wall, or an SSO redirect, and stops. The vendor workarounds all have costs:
- Stored credentials. You hand a third-party service a username and password for the client's staging system. Security teams rightly dislike this, and it breaks whenever the login flow changes.
- Scripted login sequences. Fragile, maintained by whoever wrote them, broken by every auth redesign.
- IP allowlisting the scanner. Requires infrastructure changes per environment, multiplied by every client.
The result in practice: teams audit production quarterly and staging never, which is exactly backwards. Production issues are expensive and public; staging issues are cheap and private.
The session-based alternative
There is a simpler architecture: run the audit inside the browser where you are already authenticated. You log into staging as yourself, through the VPN you already use, past the SSO you already have. The page in front of you is fully rendered, with your role's permissions and real interactive state. An extension-based auditor tests exactly that DOM.
This is the approach Complaudax takes, and it eliminates the credential problem entirely: no secrets are stored anywhere, because the audit borrows nothing. It uses the session your browser already holds and never reads your cookies or credentials.
A staging audit process that sticks
1. Audit the changed pages, not the whole site. Before a release, list the pages the sprint actually touched and audit those. A focused twenty-minute pass per release beats a heroic full-site audit per quarter.
2. Audit in realistic states. The empty form is not the interesting state; the form with validation errors is. Open the modal. Expand the accordion. Fill the cart and get to payment. Automated detection only sees the DOM that exists at the moment of the scan, so drive the page to its risky states and audit each one.
3. Audit as the right role. Admin panels, member areas, and dashboards differ by permission level. If the deliverable includes an editor interface, audit while logged in as an editor.
4. Track findings against the site, not the audit. A staging finding is only useful if someone can tell, next sprint, whether it was fixed. Store issues per site with status, so a re-audit reconciles: fixed things close, new things open, and regressions get named as regressions. This is precisely the bookkeeping Complaudax does automatically between audits.
5. Cover the manual half. Software checks roughly half of WCAG AA reliably. Keyboard-only navigation of the new feature, focus behavior in that new modal, and the sense of the reading order need a human pass. A shared checklist per site keeps this from depending on individual memory.
6. Gate the release, gently. Teams that make "zero new critical violations on changed pages" a merge or release condition see their issue trend flatten within a quarter. Gate on new issues, not total issues, or the backlog makes the gate impossible on day one.
The two staging-specific traps
Trap one: staging is not quite production. Feature flags, placeholder content, and missing third-party scripts can hide or create issues. Treat the staging audit as the primary gate, but keep a light production pass after deploy, since consent banners, chat widgets, and ad scripts arrive only there, and they are frequent WCAG offenders.
Trap two: lorem ipsum hides text problems. Placeholder content defeats checks that depend on real text: contrast over real images, heading meaningfulness, link text quality. Audit with production-like content wherever possible.
What to tell the client
Staging audits change the story an agency can tell. Instead of "we ran an accessibility check before launch", the narrative becomes "accessibility was verified on every release, and here is the record." The record matters commercially now: under the European Accessibility Act, documented and maintained conformance is what an enforcement authority asks about. A per-site history of audits and fixes, exported as a conformance report, is the strongest artifact an agency can hand over at the end of an engagement, and on Complaudax's flat plans that documentation does not cost extra per project.
Start smaller than feels serious: one client, the next release, the changed pages only. The habit compounds faster than any tooling decision.