Skip to content
wcagc
Create account
←Back to blog
how-toWCAGtestingauthenticationcheckout

How to test authenticated pages for accessibility

How to test login, onboarding and checkout for accessibility: sign in safely, scan every step, and do the manual checks automation can't.

P

Pavel Charkasau

To test authenticated pages for accessibility, give your test tooling a dedicated test account, sign it in once, and then check every step of the flow in the state a real user sees it: the login form, each onboarding screen, the cart, the payment step and the confirmation. Run an automated engine such as axe-core at each checkpoint, then walk the same flow by keyboard and with a screen reader. The order matters because of one rule in WCAG. Conformance requirement 5.2.3 says that when a page is part of a process, every page in that process has to conform, or none of them can be claimed as conforming at that level (W3C, WCAG 2.2). W3C's own example is an online store, start to checkout. So a clean scan of your marketing site tells you nothing about the signup flow behind it. This guide covers how to sign in without leaking credentials, which WCAG criteria bite hardest behind a login, and which checks still need a person.

Why do crawler scans miss authenticated pages?

A crawler requests a URL and sees whatever the server returns to an anonymous visitor. For /account/settings that is usually a redirect to /login, so the report contains one login page and nothing else. Onboarding wizards and checkouts are worse, because their steps often share a single URL and change state in the browser. There is no URL to crawl for "step 3 of 5, billing address, with a validation error showing".

Those are the pages where the most consequential barriers live. Signup, sign-in and payment are where a person either becomes a customer or gives up. They are also where forms, session timers and third-party widgets pile up, and those are the components I see fail most often in audits.

How do you sign in a test tool without leaking credentials?

Use a dedicated test account, never a staff member's real login. Give it the minimum role needed to reach the flows you test, seed it with realistic data (an order history, a saved address), and keep it out of your analytics.

For scripted tests, sign in once and reuse the session. Playwright's documented pattern is a setup project that logs in and saves cookies and storage with page.context().storageState({ path }), which other test projects then load through the storageState option (Playwright, Authentication). The same page warns that the saved file "may contain sensitive cookies and headers" and should be added to .gitignore (playwright/.auth). Take that seriously. A committed session file is a working login for anyone who can read the repo.

Multi-factor authentication is the usual blocker. An automated sign-in cannot read an SMS. The common answers are a test account in a non-production environment where MFA uses a TOTP secret your test runner can generate, or a separate test login policy agreed with whoever owns security. Do not switch MFA off on a production account to make a scanner happy.

Which WCAG criteria matter most behind a login?

Four criteria come up again and again in sign-in and checkout flows. Two are new in WCAG 2.2 and aimed straight at these flows.

3.3.8 Accessible Authentication (Minimum), Level AA. A cognitive function test, "such as remembering a password or solving a puzzle", must not be required for any step of an authentication process unless there is an alternative or a mechanism to help (W3C). In practice the mechanism is a password manager. The Understanding document is explicit that blocking paste or password-manager fill fails the criterion, and that a one-time code the user must type by hand does not comply; the code field has to accept paste. So onpaste="return false" on a password or OTP input is a defect, and so is a six-box code input that rejects a pasted value.

3.3.7 Redundant Entry, Level A. Information the user already entered in the same process must be auto-populated or available to select, unless re-entering it is essential, needed for security, or no longer valid (W3C, WCAG 2.2). The classic failure is a billing address form that ignores the shipping address typed two steps earlier. Onboarding has its own version: asking for a company name on step 1 and again on step 4.

2.2.1 Timing Adjustable, Level A. For each time limit set by the content, the user can turn it off, adjust it to at least ten times the default, or be warned and given at least 20 seconds to extend it with a simple action (W3C, WCAG 2.2). Session expiry is the obvious one. If your app logs people out after 15 minutes idle and throws away a half-filled form without warning, that is a failure, and a screen reader user filling a long form is exactly who hits it.

4.1.3 Status Messages, Level AA. Status messages must be programmatically determinable so assistive technology can present them "without receiving focus" (W3C, WCAG 2.2). Behind a login this means "Saved", "Item removed from cart", "Invalid code, 2 attempts left". If those are just a <div> that appears in red, screen reader users never hear them.

Two older criteria fill out the list. 2.4.3 Focus Order (A) breaks whenever a wizard advances to the next step and leaves focus on a button that no longer exists. 3.3.1 Error Identification (A) breaks when a login error says "something went wrong" without identifying the field.

How do you scan each step of a multi-step flow?

Treat the flow as a list of checkpoints, and run the automated check at each one after the page has settled. With Playwright and @axe-core/playwright, that looks roughly like this:

import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("checkout flow", async ({ page }) => {
  await page.goto("/cart");
  await check(page, "cart");

  await page.getByRole("button", { name: "Checkout" }).click();
  await page.getByLabel("Postcode").fill("bad");
  await page.getByRole("button", { name: "Continue" }).click();
  await check(page, "address-with-error"); // the error state is a checkpoint too
});

async function check(page, label) {
  const results = await new AxeBuilder({ page })
    .withTags(["wcag2a", "wcag2aa", "wcag21a", "wcag21aa", "wcag22aa"])
    .analyze();
  expect(results.violations, label).toEqual([]);
}

withTags limits the run to rules tagged for the WCAG levels you target, and include() can narrow it to one region of the page (Playwright, Accessibility testing). Note the second checkpoint. The error state is a different page, as far as a user is concerned, and it is where missing aria-describedby links and unannounced messages show up. Scan the open modal, the expanded menu and the empty state too, not only the happy path.

If you would rather not maintain test code, our authenticated scanning and saved journeys do the same thing from configuration: you store a test account against a verified site, the password is encrypted and never shown again, and a journey replays your steps and records findings per checkpoint. For a one-off look at a screen you are already signed into, including localhost or staging, the browser extension runs axe-core on the page as it is in your browser.

What can't automation catch in a login or checkout flow?

Most of what makes the flow usable. Deque's analysis of more than 2,000 audits found automated testing identified about 57% of issues by volume (Deque, 2021), Count by success criteria instead of by issue and the figure drops toward 30%, because many criteria can't be evaluated by a machine at all. Playwright's own guide says "automated testing cannot detect all types of WCAG violations" and recommends pairing it with manual and inclusive user testing (Playwright).

Here is what the manual pass looks like for a sign-in and checkout, in about an hour:

  • Sign in using only the keyboard, with a password manager filling the fields. Then try pasting a one-time code. If either is blocked, you have a 3.3.8 problem a scanner may never flag.
  • Submit the login form with a wrong password while a screen reader runs (NVDA or VoiceOver). Is the error spoken, and does focus go somewhere sensible?
  • Advance through each onboarding step and listen for what is announced. A new step heading should be reached without hunting for it.
  • Leave a long form idle until the session timeout. Do you get a warning you can act on?
  • Complete a purchase with a test card. The hosted card iframe from your payment provider is part of your flow. Check it has a title and that its fields are labelled.

I would argue this hour is the best-value accessibility testing most product teams can do. The marketing site gets scanned constantly because it is easy to scan. The flows that earn the revenue get looked at least, because they need a login and a card. Flip that ratio. Our WCAG checklist separates the checks a tool can make from the ones that need a person.

How should you record what you tested?

Write down which account, which environment, which steps and which date. A list of checkpoints with findings per step is far more useful evidence than a site-wide score, both for the team fixing things and for anyone who later asks how you test. In the EU, the European Accessibility Act applies to e-commerce and other consumer services and names identification, security and payment functionality specifically in Annex I (Directive (EU) 2019/882). In the US, the Department of Justice's guidance says the ADA applies to "all the goods, services, privileges, or activities offered by public accommodations", including those offered online (DOJ, 2022). Either way, a record of what you tested and fixed supports an accessibility statement that describes real effort. It does not prove conformance, and nothing a scanner produces does.

Frequently asked questions

Can an accessibility scanner test pages behind a login?

Yes, if it can sign in. That means giving it a dedicated test account and either a scripted login or a saved session, then scanning each step of the flow. A plain URL crawler without credentials only sees your login page.

Does blocking paste on a password field fail WCAG?

Yes, under WCAG 2.2 Level AA. W3C's guidance for 3.3.8 Accessible Authentication (Minimum) says blocking paste or password-manager fill fails the criterion unless another method is provided, and one-time code fields must accept pasted codes.

Do I have to test every step of a checkout, or just the main pages?

Every step. WCAG conformance requirement 5.2.3 says all pages in a process must conform for any page in that process to conform, and W3C's example is an online store from product selection to checkout.

How do I handle MFA when automating authenticated scans?

Use a test account in a non-production environment where MFA can be completed by your test runner, such as a TOTP secret it can generate, or agree a test login policy with your security owner. Don't disable MFA on a production account.

Is a clean automated scan of my login flow enough?

No. Automated tools catch roughly 30–57% of issues depending on how you count. Whether errors are announced, focus moves sensibly and a password manager works needs manual testing with a keyboard and a screen reader.

Start with the flow that earns the revenue

Run a free scan to clear the machine-detectable issues on your public pages, then pick one authenticated flow, usually sign-in or checkout, and test it end to end this week with a keyboard and a screen reader. You will finish with a short, concrete defect list and a record you can build on.

Pavel Charkasau, founder, wcagc.com. Last updated 3 November 2026.

Sources