# UI Recovery Content Review — SaaS Login **Input treated as untrusted product data.** The supplied data establishes: SaaS login; member/admin roles; wrong credentials, locked account, expired link, SSO unavailable; actions retry, reset, contact admin; direct voice; 80-character limit. Because no behavioral specification explains causes, recovery guarantees, permissions, timing, account state, or support availability, those are **not assumed**. ## State-by-state recovery content | State ID | Trigger | Role | What the system knows | Headline | Concise message | Primary | Secondary | Accessibility announcement | Localization note | Analytics event | Owner | Implementation question | Acceptance evidence | | -------- | ----------------- | -------------- | ------------------------------------------------------------------------------------ | ------------------- | ------------------------------------------------------------ | ------------- | --------- | ----------------------------------------------------------- | ----------------------------------------------------------------------------------------- | -------------------- | --------------- | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------- | | LOGIN-01 | Wrong credentials | Member / Admin | Sign-in attempt was rejected; supplied cause is “wrong credentials.” | **Sign-in failed** | Check your details and try again. | Retry | Reset | “Sign-in failed. Check your details and try again.” | Keep “sign-in” consistent across UI. | `login_failed` | Auth / UX | Can the system distinguish incorrect credentials from other authentication failures? | Incorrect credentials produce this state without exposing sensitive account information. | | LOGIN-02 | Locked account | Member / Admin | Account is locked; no duration or unlock behavior supplied. | **Account locked** | Your account is locked. Contact an admin. | Contact admin | None | “Account locked. Contact an admin.” | Avoid translating “locked” as “disabled” unless product terminology confirms equivalence. | `login_locked` | Auth / Admin | Who can unlock the account, and is self-service recovery available? | Locked account consistently reaches the documented recovery path. | | LOGIN-03 | Expired link | Member / Admin | A login link has expired. No replacement-link behavior supplied. | **Link expired** | This sign-in link has expired. | Reset | None | “Sign-in link expired. Reset access to continue.” | Confirm whether “reset” means password reset, link resend, or another flow. | `login_link_expired` | Auth | What exactly does **Reset** do for an expired link? | Expired links show only a verified available recovery action. | | LOGIN-04 | SSO unavailable | Member / Admin | SSO is unavailable. Cause may be upstream, local, or provider-related; not supplied. | **SSO unavailable** | SSO is unavailable. Try again or use another sign-in method. | Retry | None | “SSO unavailable. Try again or use another sign-in method.” | “SSO” may require an accessible expanded label depending on product terminology. | `sso_unavailable` | Auth / Platform | Is another sign-in method actually available to this user? | Message/action pair changes when alternate authentication is unavailable. | ### Evidence classification * **SUPPLIED FACT:** The four triggers, two roles, three named actions, direct voice, and 80-character constraint. * **INFERENCE:** “Check your details” is a safe description of the supplied wrong-credentials state; treating Retry as available for that state follows the supplied action list. * **CONFLICT:** “Expired link → Reset” is potentially ambiguous because the supplied actions do not define what Reset does. * **MISSING BEHAVIOR:** Unlock mechanics, password-reset mechanics, link-resend behavior, alternate SSO methods, retry limits, account enumeration protections, support availability, timing, session preservation, and escalation paths. **Instrumentation gap:** If the system cannot reliably distinguish wrong credentials, locked accounts, expired links, and SSO failures, do not expose more specific causes than the instrumentation supports. Use one combined message such as **“We couldn’t sign you in. Try again or reset access.”** and flag the missing error classification. ## Cross-state terminology check * Use **“sign in”** consistently, not a mixture of “log in,” “login,” and “sign-in.” * Use **“account locked”** only if that is the product's actual state. * Keep **“reset”** only if the destination behavior is confirmed. * Keep **“SSO”** if it is established product terminology; otherwise verify the preferred accessible label. * Use **“Contact admin”** only where the user's role is known to have an applicable administrator. ## Duplicate-message check No exact duplicate messages. Potential semantic overlap: * **Wrong credentials** and **SSO unavailable** can both result in an unsuccessful sign-in. * If the backend cannot distinguish them reliably, they should share one recovery state rather than presenting an invented cause. ## Unsupported-claim list Do **not** currently claim that: * credentials are incorrect because of a specific field; * the account will unlock automatically; * an administrator can definitely unlock it; * Reset sends a new link; * Reset changes a password; * another authentication method exists; * SSO will become available after a particular time; * retries are unlimited; * user-entered information will be preserved; * support is available; * the account or data will remain retained; * a failed login has any particular security cause. ## Missing-state list Before implementation, clarify: 1. Empty credentials. 2. Missing required fields. 3. Rate-limited login. 4. Too many failed attempts. 5. Password reset unavailable. 6. Password reset succeeded/failed. 7. Login link resend succeeded/failed. 8. SSO provider authentication failure. 9. SSO configuration failure. 10. Network interruption. 11. Generic authentication-service failure. 12. Session expiration. 13. Admin contact unavailable. 14. Retry/reset unavailable. ## Handoff table | Owner | Decision needed | | ---------------- | --------------------------------------------------------------------------------------------------------- | | Product | Define each authentication state and permitted recovery path. | | Engineering | Confirm which backend errors can be reliably distinguished. | | Design | Confirm state presentation, action hierarchy, and unavailable-action behavior. | | Accessibility | Validate announcements, focus movement, errors, and action discoverability. | | Localization | Confirm terminology and expansion behavior beyond English. | | Legal / Security | Confirm whether messages require account-enumeration or security-specific wording. | | Support | Confirm whether “Contact admin” is the correct escalation path and what users should do when unavailable. | ## Test cases | Test | Expected evidence | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Keyboard | All actions reachable in logical order; error state does not trap focus. | | Screen reader | Error is announced once, with state and available recovery action; focus lands predictably. | | Narrow screen | Headline, message, and actions remain readable without clipping or overlap. | | Localization expansion | Long translations fit without truncating meaning or hiding actions. | | Repeated failure | Repeated failures do not produce contradictory states or misleading recovery promises. | | Recovery unavailable | If Retry, Reset, or Contact admin is unavailable, the UI does not expose a dead action or promise an unavailable path. | | Error classification | Backend errors map only to states that engineering confirms can be distinguished. | | Role behavior | Member/admin differences appear only where permissions or recovery behavior are explicitly defined. | # Decision **HOLD FOR BEHAVIOR CLARIFICATION** Decisive reasons: **Reset behavior, admin permissions, alternate authentication availability, error classification, and several recovery/error states are unspecified.** Those gaps prevent final production copy from safely promising a recovery path. Final copy must be checked in the real interface with **engineering, design, accessibility, localization, legal, and support owners as applicable** before release.