Acceptance Criteria for a Login Page: States and Examples
By SayCraft Team · 2026-08-17 · 3 min read
Login acceptance criteria should cover more than successful sign-in. Define required inputs, validation timing, invalid-credential feedback, loading and retry behavior, password recovery, session outcomes, keyboard operation, and what happens after authentication. Keep security implementation decisions with qualified engineering review.
Community signal: Vibe-coding discussions repeatedly mention an almost-done gap where the happy path works but recovery and failure behavior remains unreviewed.
Build the right deliverable for acceptance criteria for login page
Create a login-state matrix with one Given, When, Then scenario for each user-visible outcome. Login acceptance criteria should cover more than successful sign-in. Define required inputs, validation timing, invalid-credential feedback, loading and retry behavior, password recovery, session outcomes, keyboard operation, and what happens after authentication. Keep security implementation decisions with qualified engineering review.
- Success and failure are separately testable
- Feedback does not reveal whether an account exists
- Keyboard focus and errors are reviewable
A worked example for acceptance criteria for login page
Given valid credentials, when sign-in succeeds, then the permitted destination opens and no password remains visible. When the request fails, loading stops, only safe input is preserved, actionable feedback appears, and the appropriate retry or recovery path remains available.
Review acceptance criteria for login page before relying on it
Review a login-state matrix with one Given, When, Then scenario for each user-visible outcome against these conditions: Success and failure are separately testable; Feedback does not reveal whether an account exists; Keyboard focus and errors are reviewable; Authorization is not confused with hiding UI. A preview is not evidence of production security, compliance, or launch readiness.
- Success and failure are separately testable
- Feedback does not reveal whether an account exists
- Keyboard focus and errors are reviewable
- Authorization is not confused with hiding UI
Use the evidence for acceptance criteria for login page
OWASP guidance supports keeping authentication feedback and account behavior from leaking unnecessary information, while W3C form guidance makes errors and status messages perceivable and understandable. Translate those principles into user-visible scenarios: missing input, invalid credentials, slow requests, retry, recovery, successful authentication, expired sessions, keyboard movement, focus placement, and the permitted destination after sign-in.
- OWASP: Authentication Cheat Sheet
- W3C WAI: form user notifications
- Reddit: the almost-done gap in vibe-coded apps
Keep acceptance criteria for login page within its boundary
Write each scenario with a starting state, user action, visible result, and recovery path. Do not encode a specific library, token format, or authorization architecture as acceptance criteria unless the engineering design has already selected it. A page can look correct while still mishandling rate limits, session invalidation, server-side authorization, credential storage, or audit requirements; those remain technical review items.
- Success and failure are separately testable
- Feedback does not reveal whether an account exists
- Keyboard focus and errors are reviewable
- Authorization is not confused with hiding UI
Hand off the acceptance criteria for login page result
Review the matrix with product, accessibility, security, and engineering owners. Test the final wording in the rendered page, including screen-reader announcements and keyboard focus, and confirm that the response does not reveal whether an account exists. Keep authorization checks on the server-side boundary even if the interface hides unavailable actions. The matrix documents expected behavior; it does not certify the implementation.
- a login-state matrix with one Given, When, Then scenario for each user-visible outcome
- Success and failure are separately testable
- Feedback does not reveal whether an account exists
Sources and discussion
- OWASP: Authentication Cheat Sheet (official)
- W3C WAI: form user notifications (official)
- Reddit: the almost-done gap in vibe-coded apps (community)
Community posts describe individual experiences and questions; they are not treated as universal proof.
Related resources
Build the next step with SayCraft
Turn each state into a reviewable scenario before treating the login preview as complete. SayCraft can keep the conversation and preview together; production security still requires engineering review.