"I was halfway through an application form when a phone call came in, and when I returned, I had to start over from scratch"—this complaint surfaces surprisingly often from companies operating membership sites and internal systems. The cause is usually a session timeout, a mechanism that automatically logs out users after a certain period of inactivity. A feature introduced for security silently wipes out user work, directly fueling the perception of an "unfriendly system." Even if it works as intended from the builder's perspective, for the user, it feels like an unreasonable accident.
Smashing Magazine's Session Timeouts: The Overlooked Accessibility Barrier In Authentication Design frames these session timeouts as an overlooked barrier to accessibility. It points out that carelessly implemented timeouts are not merely technical inconveniences; especially for people with disabilities, they become severe obstacles that sever essential procedures midway. From our position designing authentication in custom development, we consider this not an either-or choice between security and usability, but a matter of designing for their coexistence.
How "sudden logouts" happen
Login states do not last indefinitely. The server issues a session upon each login, giving it an expiration time. If there is no access for a set period, it invalidates that session—this is a timeout. The mechanism itself is legitimate and indispensable for protecting accounts left unattended on shared PCs from being hijacked.
The problem lies in sloppy design regarding that "set period." Many systems terminate sessions without any warning, within an overly brief duration, and without checking whether input is in progress. Even while someone is actively typing long text into a form, from the server's perspective, it is judged as "no navigation = no activity," and the moment they click submit, they are rejected with "Your session has expired. Please log in again." The written content never comes back. In many cases, the method of storing authentication state itself has flaws, an angle we also explore in The Problem with Putting JWTs in localStorage (GH Media).
Timeouts assume speed
Here lies the crux. Short timeouts rest on the implicit assumption that everyone operates at the exact same speed. In reality, that is simply not true.
Some people take time to type. People navigating item by item while listening to a screen reader, people who require extra time for key inputs due to motor limitations, and people who need time to read and comprehend text slowly. For these individuals, a 5- or 10-minute timeout becomes a mechanism that locks them out solely because of their pace of operation. This is precisely what Success Criterion 2.2.1 "Timing Adjustable" of the Web Content Accessibility Guidelines (WCAG) addresses; if time limits are set, providing extensions, removals, and ample advance warning is a requirement. For design approaches that avoid leaving diverse users behind, Inclusive UX Design Accounting for Cognitive Traits in Client Development (GH Media) is also a helpful reference.
Security and usability can coexist
If you ask, "Then should we just lengthen the timeout?", that introduces different risks. If a login state persists for hours on a shared terminal, the risk of hijacking increases. What matters is not choosing between making it long or short, but differentiating the design depending on the scenario.
| Scenario | Recommended approach |
|---|---|
| Forms with input in progress | Treat input actions as "activity" and avoid terminating heedlessly |
| Immediately before expiration | Display a warning and allow extension with a single click |
| Upon forced logout | Preserve entered content and restore it after re-login |
| Financial and sensitive data | Keep it relatively short while explicitly providing extension options |
The key is to rethink the definition of "inactivity." Rather than treating only page navigation as activity, counting form inputs and scrolling as activity prevents the worst-case scenario of "disconnecting while writing." On top of that, terminate only sessions that are genuinely abandoned. If you are considering overhauling your authentication method itself, please also read Client Implementation of Authentication Modernization in the Passkey Era (GH Media).
How we design this in client work
In our custom development, we do not arbitrarily fix session timeouts to "30 minutes for now"; instead, we work backward from the nature of the workflow.
First, we determine the baseline duration based on the sensitivity of the information handled. Next, we always include a warning before expiration. When remaining time runs low, a notification appears on screen, allowing users to extend their session with a single click asking, "Would you like to stay logged in?" Terminating silently versus checking in before terminating results in completely different user experiences.
Even more critical is preserving input content. Even if a session inevitably expires, temporarily saving draft content and restoring it after re-login eliminates the catastrophic accident of "starting over." In a project for a local government application system, complaints were rampant about having to restart from scratch after timeouts on long forms. By introducing auto-save during input and an extension confirmation before expiration, inquiries about "content disappearing midway" dropped to nearly zero. We greatly improved the experience without compromising security strength.
Common pitfalls to avoid
First, terminating without warning. Even if technically correct, it feels unreasonable to the user. At minimum, a prompt before expiration is essential. Second, extending time limits without providing extension mechanisms. Merely making it longer sacrifices security without solving the underlying issue. It must be paired with means to extend and continue. Third, testing timeouts only for happy paths. Real-world failures happen at boundaries such as "expiring during input" or "states desynchronizing across multiple tabs," so these must be tested intentionally.
Summary — Stop disconnecting in silence
While session timeouts are a mechanism necessary for security, careless implementation turns them into barriers that lock out slower operators and erase their input. The two goals do not conflict. Rethinking the definition of inactivity, warning and allowing extensions before expiration, and preserving inputs even when expiration is unavoidable—incorporating just these three principles into design prevents "disappearing without notice" while maintaining safety. In custom development, we achieve both defense and usability simultaneously through session designs backward-engineered from business workflows.
If you receive feedback that "logins expire too quickly" or complaints that "application data disappears midway," please feel free to reach out via our contact form. We can start with an audit of your current session design.
Sources
- Session Timeouts: The Overlooked Accessibility Barrier In Authentication Design（Smashing Magazine）
- Understanding SC 2.2.1: Timing Adjustable（W3C WCAG）
- The Problem with Putting JWTs in localStorage (GH Media)
- Client Implementation of Authentication Modernization in the Passkey Era (GH Media)
- Inclusive UX Design Accounting for Cognitive Traits in Client Development (GH Media)
