Onboarding session timeouts: warn, extend and preserve valid work
Design session expiry around the work people are doing: an operable warning, supported extension, accurate saved state and a useful return after sign-in.
In this article
A session timeout should explain the approaching interruption, offer an appropriate way to continue and preserve valid work for the person’s return. Decide those behaviors together. Adding a warning to a flow that later discards everything still leaves a poor recovery.
Authentication and task persistence are separate design decisions. A product may need a user to sign in again without needing them to recreate a workspace name, remap an import or retype an unfinished description. The retained data still needs appropriate protection and a defined lifetime.
Start by listing what actually expires. An authenticated session, an invitation, a temporary upload and a reservation can have different rules. One generic “Your session has ended” message obscures which action the person needs to take.
Choose a timing approach deliberately
W3C’s Timing Adjustable criterion is Level A. For time limits set by the content, it describes alternatives: let users turn the limit off before encountering it, adjust it before encountering it over a range of at least ten times the default, or receive a warning with at least 20 seconds to extend it through a simple action, with at least ten extensions allowed.
The criterion also includes real-time, essential and longer-than-20-hours exceptions. A security rationale does not automatically make every timeout essential. Evaluate the actual condition and applicable requirements rather than treating “security” as a blanket exemption.
Those are criterion conditions, not a universal session policy. Your product still needs a considered decision about sensitive actions, shared devices and the information it preserves. This article’s interaction example is a design proposal, not a conformance or security assessment.
Follow one setup task through expiry
Consider an illustrative service where a new administrator is configuring a project. They have named the project, selected its default view and begun writing an introductory note. They pause to check a colleague’s instructions.
The product has deliberately chosen an extension-based warning for this scenario. Its warning says: “Your sign-in session is about to end. Continue working to stay signed in. Your project settings are saved; your note is still being saved.”
That last sentence matters. If persistence has not completed, the interface cannot honestly promise that all work is recoverable. The design should resolve or clearly surface that state before redirecting.
| Stage | Product behavior | What the person needs to understand |
|---|---|---|
| Normal setup | Saves eligible progress and shows failures | Which work is actually retained |
| Warning | Offers an operable extension action | What expires and how to continue |
| Extension succeeds | Confirms the server accepted the extension | The person can keep working |
| Session expires | Stops protected actions and explains recovery | Which work remains available |
| Sign-in succeeds | Reopens the authorized task and checks its current state | Where to resume and what needs attention |
No stage should infer success solely from a button click. Clicking Continue working is a request; the session is extended only when the application confirms that result.
Make the warning usable in the current task
A warning must be perceivable and operable in the contexts your product supports. Someone using a keyboard or assistive technology needs to discover the interruption, understand its purpose and activate the extension without navigating a fresh maze.
Keep the message short. Explain the expiring session, the available action and the effect on work. A running countdown should not produce incessant announcements that obscure the action itself.
Avoid allowing the warning to erase unsaved text or unexpectedly submit the underlying form. If a dialog is used, its focus behavior and dismissal need deliberate handling. Returning from an accepted extension should put the person back in a sensible place in the task.
A warning triggered in another tab introduces a different problem. The active setup tab may still look usable after the shared session has ended. Coordinate the displayed state and recheck authorization when the person acts. A visible timer is a representation of the policy, not the authority that grants access.
Be precise about saved work
For the illustrative project, a persisted project name and view selection can be restored after sign-in. A note whose save failed should be identified as unsaved while the product still has an opportunity to help.
Do not solve this by automatically copying every value into browser storage. Choose storage and retention according to the data involved, expected device use and product requirements. A recovery mechanism should not expose one account’s draft to a different person who signs in on the same computer.
Distinguish recovery from submission. Saving a draft invitation message can preserve work without sending it. Keeping selected import options can help the user return without starting the import automatically. The product should still require an appropriate confirmation for consequential operations.
Also distinguish valid progress from stale progress. A teammate may have renamed the project or removed a destination while the user was signed out. Restore the task against its current state, and explain conflicts instead of overwriting newer work silently.
Return to the task after authentication
W3C’s Re-authenticating criterion, at Level AAA, addresses continuing an activity without losing data after an authenticated session expires. It also notes that the other timing requirements still apply. Preserving work after sign-in does not erase the need to consider the preceding time limit.
For the project example, the return screen reopens the unfinished note in the correct project. A short message states that sign-in succeeded and identifies any input that could not be retained. The next action is the same meaningful action the person had been working toward.
If the person authenticates as a different account, do not attach the previous draft to it by default. If their permission has changed, explain why the saved task cannot currently be opened and provide the relevant recovery route.
A generic dashboard is a weak landing place when the product knows which task was interrupted. The broader resume setup guide describes how to preserve that destination across longer breaks.
Review expiry as part of onboarding
Exercise the warning while a field has focus, while a save is pending and while the user is on another tab. Try an accepted extension, a failed extension, a missed warning and a return with changed permissions. Confirm saved state by reopening it, not merely by seeing a success message.
Ask a simple question at each point: can the person tell whether they are still authorized, whether their work exists and how to continue? Document any case where the answer depends on an unavailable network or a policy exception.
Use accessible onboarding for the surrounding interaction review. A well-handled timeout belongs to the same journey as the form, the first task and its result. It should leave the user with a clear next step and as little repeated work as the product can responsibly avoid.
Sources
- W3C WAI: Understanding SC 2.2.1: Timing Adjustable
- W3C WAI: Understanding SC 2.2.5: Re-authenticating
