Getting Session Timeouts Right: An Accessible Approach
Accessibility conversations tend to focus on the visible stuff: color contrast, alt text, keyboard navigation, screen reader compatibility. Though what often gets overlooked is one of the things that can frustrate and alienate users with alternative browsing modes, Session Timeouts.
A session timeout is one of those features that feels purely technical, its usually a security decision made in the backend, made by during a platform’s development, but are rarely revisited. However, how you handle session expiration has real consequences, and for a significant portion of your audience, a poorly designed timeout isn't a minor annoyance. It's a barrier.
The Real Impact on Users With Motor, Cognitive, and Visual Impairments
Eleanor Hecks makes the case clearly in this article: session timeouts disproportionately affect users with motor, cognitive, and visual. In her breakdown, she notes that an estimated 20% of people are neurodivergent, meaning timeout barriers affect a substantial portion of any site's audience, not an edge case.
For users with motor impairments, slower input speeds can make them appear inactive when they're actively working through a form. Muscle stiffness, tremors, or reliance on adaptive devices all slow the pace of interaction. A 30-second warning countdown isn't a solution when it takes longer than that to respond.
For users with cognitive differences, such as ADHD, dyslexia, memory-related conditions, the issue is different. Hecks points to time blindness as a particular problem: the documented experience where people with ADHD genuinely cannot track how much time has passed. As neurodivergent technology leader Kate Carruthers describes it, ADHD means you can't reliably estimate remaining time, which makes any warning system that depends on that estimation fail before it starts. When a session expires mid-task because a user was reading carefully and thinking through their inputs, the system has effectively punished them for processing information at their own pace.
For screen reader users, the problems compound further. Web developer Bogdan Cerovac documented this firsthand: a countdown timer that announced remaining time every single second, making it impossible to navigate the page while being bombarded with constant status messages. As Cerovac put it, the timer worked fine, the screen reader experience was horrible. The feature functioned as designed. It was still inaccessible.
Pitfalls to Avoid
A few common implementations show up repeatedly in accessibility audits and they all have the same problem: they treat session management as a security concern only, with no consideration for the user on the other end.
Silent timeouts, those that comes with no warning, just a redirect to the login screen, are the worst offender. A user who spent an hour on a complex form loses everything with no notice. Even sites that do provide warnings often fall short: a brief pop-up that appears 30 seconds before expiry gives most users no meaningful time to respond, and may not be announced to screen reader users at all.
Non-extendable sessions are a related failure. If a user can't extend their session when warned, the warning itself is functionally useless. And if the site doesn't preserve form data on expiry, the user isn't just logged out, they're starting over.
What Good Looks Like
The WCAG guidelines on timing (SC 2.2.1, 2.2.5, and 2.2.6) address session expiration: users should be warned before a session expires, given the ability to extend it, and not penalized for needing more time. SC 2.2.1 (Timing Adjustable) is what Section 508 and most ADA requirements reference; SC 2.2.5 (Re-authenticating) and SC 2.2.6 (Timeouts) are considered best practice.
Beyond compliance, the practical fixes are straightforward. Warn users well in advance, at minimum two minutes, ideally more for complex forms. Make the extension mechanism a single, obvious action. Auto-save form progress so that even if a session does expire, the user isn't starting from zero. And if the task doesn't involve sensitive data or shared access, question whether the timeout is necessary at all.
Activity-based timeouts that clock inactivity are generally harder on users with disabilities than absolute timeouts with a known end time. If a user knows their session expires in 60 minutes regardless of activity, they can plan around it. If they're being watched for "inactivity" by a system that doesn't understand what inactivity means for their situation, they can't.
Why This Matters for Your Product
Remember accessibility isn't a checklist item we work through at the end of a project. It shapes decisions from the start, including decisions that live in the backend, like session management. The WebAIM Million report consistently finds that accessibility failures are concentrated in exactly the kind of details that don't make it onto design reviews: form labels, error handling, and yes, timeout behavior.
If your site handles any kind of form completion, applications, purchases, service requests, account management, it's worth reviewing how session expiry is handled and whether your current implementation would hold up against WCAG criteria. The DWP Accessibility Manual's guidance on testing session timeouts is a useful starting point if you want a practical framework for evaluation.
Building accessible products means accounting for the full range of how people actually use them. Session timeouts are a small piece of that, but for the users they affect, they're not small at all.
