Accessible timeout notifications

When a web application has a session timeout, it’s a good idea to warn users about the impending timeout and give them the opportunity to do something about it. It’s therefore important to make sure that all users know when the warning notification appears.

When you set the timeout initially, don’t forget that some people will take longer to use your application than others. This might be because someone lacks confidence with the web or because they find reading or comprehension difficult. In both cases an extended period of inactivity might be the result of them taking extra time to read and understand the content, and a timeout notification will only exacerbate the problem. Make the initial timeout as generous as possible.

When the timeout is imminent, a common approach is to display a notification on-screen. The notification usually indicates how much time is left before the timeout occurs, and includes an option to postpone it for a further period of time.

It’s better to use DOM scripting to add the notification to the page at the appropriate time. If you rely on toggling display:none; in the CSS, the notification will be permenantly available to anyone who has CSS disabled and/or who uses their own stylesheets.

When the notification appears there are a few simple things you can do to make sure everyone is aware of it. Your basic notification might look like this:


<div>
<h1>You will be logged out soon</h1>
…
</div>

Move keyboard focus

Use the tabindex attribute with a value of -1 on the <div>. When the notification appears on-screen, use obj.focus() to move keyboard focus to the notification. This will ensure that keyboard users (including people using screen readers and screen magnifiers) are aware that the notification has appeared.

Note (added on December 30th in response to James’ comment): when the user confirms the timeout extension, keyboard focus should be returned to its original location on the page. This stops keyboard users from having to manually navigate back to their original point in the content.

Indicate group semantics

Use the group role on the <div>. This will indicate to screen readers (and other assistive technologies that support ARIA in the future) that the content contained within the <div> has a common purpose.

Provide an accessible name

Use the aria-labelledby attribute on the <div> and use the idref of the <h1> as its value. This will give the <div> an accessible name based on the content of the <h1> element so that screen readers can differentiate the group from other content.


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

In doing these things you’ll make sure that people have a reasonable amount of time to use the application comfortably, that they’re aware when a timeout is about to happen, and that they can act to postpone it in good time.

7 comments on “Accessible timeout notifications”

Skip to Post a comment
  1. Comment by James Edwards

    I don’t like this solution 🙂

    Moving the focus will draw attention to the notification, yes, but it might do so at an extremely inconvenient time. Without warning, it suddenly moves the focus to a different part of the page, and then forces users to manually navigate back to where they were before, both of which are potentially very annoying.

    Moving focus should only be done in response to a user action — e.g. opening a custom dialog would move focus to the dialog, which is useful and expected.

    I think a better solution in this case is a simple alert or confirm (alert if it’s just a message, confirm if users have the option to extend it). These dialogs are immediate and assertive, they manage focus correctly (putting it back where it was before when the dialog is closed), and they would work equally well for all kinds of users.

  2. Comment by Léonie Watson

    @James

    The alert role might not be suitable for this use case. It’s just a live region so keyboard focus shouldn’t be moved to it. Even if the alert was injected into the page somewhere inside the available viewport, I think there’s a risk that someone using magnification might miss it anyway.

    The alertdialog role could work well though. With either this or the approach in the post keyboard focus has to be provided through scripting, so your excellent point about returning focus to its original point remains whichever role you choose.

  3. Comment by James Edwards

    I agree about the alert role. It might be better for screenreader users, but it wouldn’t help sighted keyboard users.

    However that’s not what I was suggesting. I mean, use the JS alert() dialog.

  4. Comment by Steve Faulkner (@stevefaulkner)

    @james, using a JavaScript alert() will result in the same behaviour, it’s also a modal dialog, focus is trapped by the alert dialog until the user responds. Not moving focus means that some users will not get the message. I would suggest that user inconvenience is less than being kicked out of application and having to log back in without warning. The only thing that Leonie’s advice does not make clear is that once dismissed focus must be moved back to the last focused element.

  5. Comment by James Edwards

    Yes, the alert will move the focus and force the user to respond. But isn’t that exactly what’s required for this situation?

    Whether you use an alert dialog, or an alert role, you still want to be sure that the user has seen the message, and require them to confirm that they’ve seen it by clicking “ok” to dismiss the message.

    The alert is more brutal, but then so is the whole concept of session time-out. If you can’t remove the need for time-out, then shouldn’t be presented to the user with the assertiveness it represents?

  6. Comment by James Edwards

    Oh hang on, I just contradicted myself there. Starting by saying that you shouldn’t move the focus without user interaction, and then advocating a solution that does exactly that.

    I guess I don’t really think of modal dialogs as things that move the focus. Even though they literally do, it’s not quite the same thing. It’s not so much that it moves the focus, as that it temporarily puts something else in the place where the focus is.

    Maybe that’s an arbitrary distinction 🙂 It’s just that a modal dialog forces you to respond, but an in-page notification can be ignored.

    If it is ignored (or if the user isn’t required to confirm) then that creates the problem of the user having to re-navigate back to where they were. This problem can be solved by managing the focus (as we’ve all agreed), and that in turn implies that the notification must have an “ok” button.

    But an alert dialog already has all that behaviour built-in, and that’s why I think it’s a better solution.

  7. Comment by James Edwards

    I’ve been doing some ARIA testing recently, and an interesting thing stood out:

    JAWS has two different page positions — the tab focus position, and the read cursor position. Tabbing moves the read cursor, but reading doesn’t move the focus position.

    So what will happen with this (or alert, whichever way it’s done) is that moving the focus, then moving it back again, could move the read cursor to a completely different part of the page from where it was before. A JAWS users will have lost their place, whatever you do with the focus.

    So I’m tempted to go back to my original statement — don’t move the focus AT ALL except in response to a user action.

    In this specific case then, the best approach would probably be to use an aria-live region, and don’t move the focus at all, simply ensure that the notification appears on a visible part of the page — then sighted users will see it, and screenreaders user will hear it, without changing the focus or read position.

Comment on this post

Will not be published
Optional