Timeout warning

[govuk-design-system]

What

Warn users that their session is about to time out and let them extend it if possible.

Why

All services that use sessions already use, or should use this pattern.

Anything else

• Demo
• Prototyped component code and demo (patterns/components)
• Draft guidance
• Code on GitHub
• Accessibility acceptance criteria
• User research on Google Docs

Related patterns

#103 Timeout page

[ignaciaorellana]

I had a chat with @hannalaakso and the example component still needs to be separated into: Timeout waring & Modal Dialogue (aka Modal window, pop-up). We recommend for now to look at both issues in the backlog.

[hannalaakso]

Context: The Patterns and Components team (now GOV.UK Design System team) built a prototype timeout warning component for user research and for exploring what it would take to publish a production ready component.

Code for prototype that the team tested with.

The below proposes guidance for the above mentioned timeout warning component that was tested

Draft guidance for Timeout warning component

Use this component to warn users that their session is about to time out.

A timeout warning helps services meet WCAG 2.0 success criterion 2.2.1 - that services warn users before a timeout occurs and allow them to extend it.

Example:

When to use this component

The timeout warning should appear 5 minutes before the timeout is due to occur.

Follow the session timeout pattern to ensure your timeout is well designed.

How it works

After a period of inactivity, the timeout warning is shown the user. The user is given a period of time to take action, with a count down to show amount of time left.

The actions presented would typically be to continue with the application (thus resetting the timer), or a secondary action suitable to the service - such as cancelling the application or saving it.

If the user does not choose to continue the application within the time limit, they will be redirected to a timeout page that explains what has happened and give options for how to continue. The session timeout pattern contains an example of this page.

Services should watch for user activity and extend the timeout appropriately. This is particularly important for services or pages which may take users longer than the timeout duration to complete.

How client side and server could potentially communicate - draft

When the user loads a page, the server records this as the last interaction in the session.
When the user interacts with the page, the client side sends periodic heartbeats (at most every 30 seconds and these should be debounced) to the server which updates the last interaction time accordingly.
When the user stops interacting with the page, the client begins a countdown to 25 mins of user inactivity. Once elapsed, the client checks the last inactive time with the server to verify last active time (user could have been interacting with the page in another window) and opens modal. If user does not interact with the modal for another 5 minutes, client will check last active time with server. If server confirms last inactive time was 30 mins ago, client will redirect user appropriately.
Once the modal is open, the client needs to know if user has closed the modal in another tab.
The inactive time until user is redirected should match session length on server: we recommend waiting 25 minutes until showing the timeout warning and giving users a 5 minutes to dismiss the warning warning.
If user dismisses the modal, client notifies server of new time user was active and server extends session appropriately.
An alternative could be to use local storage to replace some of the server interaction.

Note that this is all hypothetical and probably too much detail, the service team should consider what works best for them.

Progressive enhancement

Users who have JavaScript enabled can extend their session. This is progressive enhancement since it is possible for users without JavaScript to use and interact with the service.

No JavaScript solution

For situations where the user does not have Javascript, the service could consider the following:

Tell user by which time they'll need to have completed the form (include name of timezone) and hide this message with JavaScript.
Use a meta refresh tag inside Noscript tags that matches the session timeout time (Unfortunately Noscript won't catch users whose JavaScript has been blocked by a firewall but there is no way to reliably way to remove the meta tag across browsers with JavaScript: the header is not part of the DOM and the browser will process the meta tag on page load).
If user does not submit the form by the specified time, meta refresh will take them to a timeout page.

The following enhanced solution where user is able to extend their session without JavaScript was discussed but was deemed to add too much complexity:
Have an Extend session button on the page. Extend session button will submit the form and refresh the page. It resets the session on the server and prints out the new timeout time on the page. No validation and saving of data in the database should happen.

Accessibility

Having a timeout warning helps services meet WCAG 2.0 success criterion 2.2.1 - that services warn users before a timeout occurs and allow them to extend it.

Services should not limit the number of times users can extend their session.

In addition, the timeout warning:

• Announces the remaining time to assistive technology (using less frequent intervals than the visible countdown)
• Makes the underlying page content non-actionable and non focusable.
• Content variations
• Services will require at least two versions of content for the timeout warning (and subsequent timeout page).

These are:

• warning shown during application
• warning shown after completing application

The first will warns that users will need to start again, whilst the second should advise how users can track / get more information about a completed application.
Services with sign-in / accounts
Services will need to vary the content if they have account functionality or otherwise save user data.

Research on this component

We carried out research lab sessions in autumn 2017 with various different types of users.

Findings:
Users have high awareness of timeouts and timeout warnings
Users will often dismiss / acknowledge the timeout quickly without reading the content
Users were often unaware of the secondary option as they closed the warning so quickly.

Devices tested on

Chrome, Firefox, Safari (desktop) - latest version at the time of writing
Internet Explorer 11
Microsoft Edge 14, 15
Android Galaxy S8, Pixel 8, Nexus 7: Chrome and Firefox
iPhone 6, iPhone 5s: Safari, Chrome

Accessibility

AT technology that the component has been tested with:
Jaws 14/15 + IE11 + Windows 7
Jaws 17/18 + IE11 + Windows 10
NVDA + Firefox (latest version at time of writing) + Windows 10
VoiceOver + Safari + iOS 10.3.2 + iPhone 5s
VoiceOver + Safari + Mac OS 10.11.6
Dragon NaturallySpeaking 13

On AT, the timer updates every 15 seconds. These timings are currently being reviewed by the GDS accessibility team.

We have written accessibility acceptance criteria that was reviewed by GDS Accessibility team:
https://gist.github.com/hannalaakso/2641fc16d2158e60d551cd9da960b5da
The component currently fails number 7 as no browser supports this.

List of accessibility attributes on the component:

Attribute and value	HTML element	Reason for using
aria-live="polite"	modal-dialog	When AT reads content, modal content does not interrupt other content
aria-labelledby=”dialog-title”	modal-dialog	Heading is read out by AT
aria-describedby="at-timer"	modal-dialog	Timer is read out by AT
role="dialog"	modal-dialog	Ensures backward compatibility if no browser support for “dialog” element.
role="status"	at-timer	Timer is read by AT on iOS VoiceOver
aria-hidden="true"	timer	Element is hidden to AT (Instead, AT reads out “at-timer” that updates less frequently)
aria-relevant=”additions”	timer	There is a bug in Jaws 17/18: it ignores aria-hidden and reads out contents of element. This is a hacky solution to get around the issue. The bug has been reported to Freedom Scientific.

More research needed to find out:

The steps leading to the appearance and dismissal of the modal when user has site open across multiple tabs, see card
Where exactly users look on the timeout modal to determine what type of content they are likely to read; we would like to test this with an eye scanner.
User behaviour with other type of content than a timeout, for instance a warning not to enter personal sensitive information, or a form inside the modal.

User research on Timeout warning (from User research on Google Docs

Context: The Patterns and Components team (now GOV.UK Design System team) built a prototype timeout warning component for user research and for exploring what it would take to publish a production ready component.

The below details the findings from user research

Timeout warning findings

Overview
We have been testing a group of components and patterns as a project in the Design System team. In here we discuss the work and findings for the timeout warning component.
You can read a project summary here which will explain in more detail about the work we did and the team behind it.

We tested timeout warning with 17 users in total.
Session 1 and 2: 7 users that confident or expert level digital users
Session 3: 7 users that are low confident digital users
Session 4 and 5: 4 users with access needs

You can find the guidance document for timeout warning here

About timeout warning

We are building a modal dialog with a timeout warning. Also referred to as ‘session timeout warning’. It is basically a message that comes up on the screen after the user has been inactive for a period of time and warns them that their application or session will be timed out. It then should give the user a few options like continue with their application or perhaps cancel the application.

We tested with three different options presented for the users:

Continue with the application
Cancel the application
Save application

Example

Why a modal dialog?

Modal dialogs - better known as popups - are a window that appears on the screen and requires the user to interact with it before continuing. There’s a lot of guidance and discussion around modal dialogs and when not to use them.

But they are useful when you need the user to focus on one task and one task alone. Often they are used to inform the users about something important that needs an action from them. For example, a good use case of modal dialogs could be divided into after two different types.

The first type is when the user by an action has triggered it. For example this could be after the user has clicked on closing or deleting something.

*** Replace with Gov example?

And the second type is what we’ve been working on for the last couple of months - a timeout warning modal dialog that only comes up if the users has not performed any actions on the screen for an extended period of time.

Our findings

1st version

We set this to appear after two minutes of inactivity, which we obviously understands is a very short and unrealistic time, but for the purpose of testing the component we felt it was fine.

Instant but correct reactions?
We learned from the first two research sessions that most users responds to close down the timeout warning very quickly when it appears on the screen. All of the users that showed this behaviour did click on the green ‘Continue application’ button which was positive and indicated that they did understand what the modal dialog was.

We also asked the users at that point or when it appeared later on what their understandings was about the modal dialog, and what their options were. When asked they all responded that the timeout warning had appeared to them not being active on the application. So in all cases it validated that they understood what it was for and why it had appeared on the screen.

Mixed understandings
We did however see some mixed results about the understanding of what options they had available to them when the modal dialog appeared. Most of them were quick to close down the modal dialog and didn’t take time to look at what was said on it or knew if they had another option to click on.

When asked what would have happened to the information that they had already filled in if their application would have been timed out it appeared that not all users understood that their data would have been lost if they didn’t click on ‘Continue application’.

This had us thinking, did the user really understand what their options were? Could we test this by adding another option on the modal that they could interact with?

So we decided to tweak our component slightly and remove the ‘Cancel application’ button and instead replace it with a ‘Save application’ button instead. This was something a couple of the participants had also mentioned themselves during the session as something they’d like to have seen.

2nd version

Users didn’t click on ‘save’
It was expressed by several users during the testing that a save feature would have been useful. This was shared amongst several users when discussing how they would have felt about losing the data they had filled in. But what became clear in the last rounds of research that only two user out of 15 did actually click on the ‘save’ link in the end.

Users seem clear that it’s for security reasons
What was clear for most if not all users when asked about it, is that they knew that timeout warnings and taking users out from a service journey if they still idle for too long, is that it’s for security reasons. Which was really positive to hear. They might find features like this too be very annoying (using their own words) but they understand that it’s there to protect their data.

Summary

Users have high awareness of timeouts and timeout warnings
Users will often dismiss / acknowledge the timeout quickly without reading the content
Users were often unaware of the secondary option as they closed the warning so quickly
Conclusion

We assume that the most common scenario for when a timeout warning will appear is if a user has left their computer to do something else. A timeout warning should not appear ifthe user has not progressed through a page after a long time but has still been active on it. For example, if they need to write something that is more complex than selecting a radio button the timeout needs to be longer.

Modal dialogs works well for timeout warnings
One of modal dialogs more common use cases is definitely for timeout warnings. And there are good reasons for it. A modal dialog can easily grab the user’s attention. And from our research we feel confident that modal dialogs serves the purpose of a timeout warning well.

What is a reasonable time limit?
The limit for when a timeout warning should appear needs to be a realistic number. It of course can’t be coming up after just a few minutes like in our research sessions. The limit needs to be set by service teams. But a potentially reasonable limit is between 20 and 30 minutes.

Save and return?
Having a save feature was something many users mentioned as a desired feature. This was very much the case when discussed further with the users about the possibility to be redirected out from a service and losing their data. So if you have a timeout warning feature in your service application it might be a good idea for you to at least explore the idea of having a save and return feature. But this very dependant on the type and length of a service.

Outstanding research required:

Additional testing with assistive technologies - general testing
Dragon

Additional research of interest:

Additional testing with users of various access needs;
Dyslexia, autism
Save and return features

Lab testing

Desktop (windows), laptop (windows), iPhone, Android, iPad
JAWS, Voiceover (iPhone and iPad), Zoomtext 10, physical magnifier

Devices tested on

Chrome, Firefox, Safari (desktop) - latest version at the time of writing
Internet Explorer 11
Microsoft Edge 14, 15
Android Galaxy S8, Pixel 8, Nexus 7: Chrome and Firefox
iPhone 6, iPhone 5s: Safari, Chrome

Assistive technology tested with

AT technology that the component has been tested with:
Jaws 14/15 + IE11 + Windows 7
Jaws 17/18 + IE11 + Windows 10
NVDA + Firefox (latest version at time of writing) + Windows 10
VoiceOver + Safari + iOS 10.3.2 + iPhone 5s
VoiceOver + Safari + Mac OS 10.11.6
Dragon NaturallySpeaking 13

[ignaciaorellana]

that's amazing @hannalaakso thanks for this!

[NickColley]

The new WCAG 2.1 (Level AAA) guidelines specify that: "Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions."

https://www.w3.org/TR/WCAG21/#timeouts

[edwardhorsford]

The new WCAG 2.1 (Level AAA) guidelines specify that: "Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions."

https://www.w3.org/TR/WCAG21/#timeouts

I should note that over the years we've had several reports from other services that have warned users upfront about timeouts and found that those users' concern was greatly increased - as generally they read it as '30 minutes to complete the application' rather than 30 minutes of inactivity.

[jennifer-hodgson]

We've been discussing the service timeout pattern in our HMRC Working Group. At present, our timeout is set at 15 minutes by default and our discussion have mostly been around the legitimacy of increasing this to, for example, 30 minutes where there's a strong user need. Whether designers are able to do this or not is currently quite hazy, and we have been fielding requests that when this pattern is documented it is made more transparent that times can be increased and guidance is given about the process for doing this. I'm wondering - is this something that should be dealt with on a departmental level, or can this be covered within the GOV.UK Design System?

[terrysimpson99]

Does anybody have any comments on Jennifer's question?

[StephenGill]

Hi there,

I think we can deal with the question of how to use session timeouts separately from the question of how/when to warn users that the timeout is going to happen.

So I've raised a new issue and added it to the backlog: #207