Session timeouts

Users affected by session timeouts

Although session timeouts are designed to protect users, if implemented incorrectly, they can easily make it impossible for some users to complete a task.

Users with certain access needs find timeouts particularly challenging because they require more time to read content and to perform functions such as filling in forms. These include people with:

• blindness and low vision
• dexterity and cognitive limitations
• mental health issues
• cognitive difficulties.

Key considerations

• User testing
  Gauge how accessible the timeout is with a broad range of users.
• Providing other options
  Inactivity with a mouse or keyboard does not necessarily mean a page is not being used. It’s essential we provide options to disable time limits, customise the length of time limits, or request more time before a time limit occurs.
• Notifications
  Make sure every user is notified when the timeout is close to ending – including those using screen readers – and given the opportunity to extend the timeout.
• Returning a user
  A user will not necessarily be on a keyboard-focusable element when the session timeout message is displayed. Therefore, it’s important to return the focus to the user’s previous position after they have interacted with the message.

Duration

WCAG states, we should multiply the time it takes someone to perform an action by 10 when deciding on a timeout duration.

For example, if it takes 15 seconds for a user to respond and hit a switch, 150 seconds should be the duration. This would be sufficient to allow almost all users to hit a switch even if they had trouble.

Timeout warnings

Warnings should include the following information as an on-screen alert:

• The remaining time available before the session expires.
• Offer an extension of time.

Implementation (developer)

• Inject the timeout message container into the DOM rather than relying on CSS to ‘unhide’ a pre-existing message as this would make the message available at all times to anyone with CSS disabled.
• Keyboard focus must be moved to the message container when it is injected so that it is immediately announced to a screen reader, and so that keyboard focus is captured. To make the container focusable, set the tabindex attribute to -1 on the containing element. When the notification appears, use JavaScript to move keyboard focus to the element and contain focus there until the user has interacted. When a user extends to timeout and the message removed from the DOM, return focus back to their previous location on the page*
• Give an accessible name to the container by referencing the H1 within the timeout message using the aria-labelled by attribute.
• Add a role of ‘group’ to the container. This will indicate to screen readers (and other assistive technologies that support ARIA in the future) that the content contained within the container has a common purpose.

Example:

<div tabindex="-1" role="group" aria-labelledby="notification">
<h1 id=""notification">You will be logged out soon</h1>
…
</div>