Accessibility test cases for login & checkout flows

Accessibility advice is often abstract — "use semantic HTML," "support keyboard navigation." Useful, but hard to turn into a test pass on a Tuesday. So here are the specific cases for the two flows that matter most, because they're the ones where a barrier directly blocks a core task: signing in and paying. If a screen-reader or keyboard user can't complete these, nothing else about the product's accessibility matters. This is the applied version of the pre-release accessibility smoke test.

Login flow

Login is small, which is exactly why its accessibility bugs get overlooked. Run these:

• Keyboard only: Tab reaches username, password, show/hide toggle, submit, and "forgot password" in a logical order; Enter submits. No mouse, full completion. This is the keyboard pass on the highest-traffic form you have.
• Labels: each field has a real, programmatic <label> — not just placeholder text, which vanishes on input and isn't reliably announced.
• Error handling: a failed login announces the error to a screen reader (via a live region or focus move), not just a red border. The user must know it failed and why, without seeing the colour.
• Password reveal: the show/hide control is a real button, keyboard-operable, with a state a screen reader can read ("Show password" / "Hide password").
• Error focus: on submit failure, focus moves to the error or the first invalid field — not left where the user can't find what went wrong.

Checkout flow

Checkout is longer, more dynamic, and higher-stakes — every barrier here is lost revenue and a frustrated customer:

• Full keyboard completion: the entire flow — address, shipping options, payment, confirm — completes with the keyboard alone. Any custom control (a styled dropdown, a date picker, a card-type selector) must be operable without a mouse.
• Field labels and grouping: every input labelled; related fields (card number/expiry/CVC) grouped so their relationship is announced.
• Inline validation announced: "invalid card number" reaches a screen reader, doesn't just turn red. Errors are associated with their field programmatically.
• Focus order matches visual order: no scrambled tab path through a multi-step form; focus is managed sensibly as steps appear.
• Dynamic updates announced: when the total recalculates, a discount applies, or a step expands, the change is announced — not silent. A sighted user sees the total change; a screen-reader user must be told.
• Errors don't lose the user: a validation failure moves focus to the problem; the user isn't dumped back to the top with no idea what's wrong.

Login & checkout accessibility cases

• Complete both flows with the keyboard only — every custom control operable
• Every field has a real programmatic label (not placeholder-only)
• Login and validation errors are announced to a screen reader, not colour-only
• On error, focus moves to the message or first invalid field
• Related fields grouped; errors programmatically associated with their input
• Dynamic changes (totals, discounts, new steps) are announced
• Focus order matches visual reading order through every step
• Password reveal / custom selectors expose state and are keyboard-operable

Why these two flows first

You can't make a whole product accessible in one sprint, so prioritise by consequence. A barrier on a marketing page is bad; a barrier on login locks someone out of their account, and a barrier in checkout stops them paying — both are direct, high-impact failures of a core task, and both are legally and commercially the ones you least want to ship. Get login and checkout genuinely operable by keyboard and screen reader, with errors that announce themselves, and you've covered the accessibility cases that matter most before touching anything else.