Timeout warnings pattern

[StephanieLongden]

This post includes key information about the new research done in June 2023 on timeout warnings.

For guidance on implementing an accessible modal see our Accessibility acceptance criteria.
Accessibility Acceptance criteria for modals.pdf

Design specifications and functionality: (https://www.figma.com/file/eFx2NUHEIcAkcEEiuyqqZJ/Timeout-modal-designs?type=design&node-id=0%3A1&mode=design&t=T3i14H2Hxing969K-1)

For previous research findings on other Home Office services, see this previous thread #383.

Summary

We have been working to research and improve the pattern and guidance for helping users to stop a service timing out. Our aim was to design the most accessible pattern for timeout warnings.

We conducted A/B research on a modal dialog and a warning page with 8 participants using assistive technology. The users were visually impaired or had dyslexia.

Gaps

We wanted to explore:

• how participants with access needs experience modals
• effectiveness of a countdown timer on the warning
• how screen reader users experience receiving the timeout warning
• what other timeout warning approaches there were
• when timed out, where users expected to be taken if they signed back in
• users' expectations of what would happen to their data when they had been signed out/ timed out

Assumptions

Our assumptions going in to research were:

• users are familiar with timeouts​
• a design approach using a warning page would be more accessible than a modal ​component
• using a countdown timer would not induce anxiety ​
• the sign out option would not be used ​
• users wanted to know why they had been signed out

Designs tested in research

Research aims

Our aims in the research were:

• to understand how the current timeout modal supported users with access needs​
• identify pain points and barriers to the timeout modal
• explore an alternative approach to the timeout modals using a timeout warning page

A/b Usability testing

 We did moderated usability testing and rotated scenarios. Participants shared their screens when accessing the prototype.

Our research sample of 7 users and 1 helper included:

• proxy users who were external to the Home Office​
• users with visual impairments
• users with dyslexia

Assistive tech used in sessions:

• NVDA​
• JAWS
• VoiceOver on mobile
• Screen magnifying software​
• Braille display
• Dragon​

Caveats and limitations

Our participants were proxy users who do not have a UKVI account​ and were unfamiliar with this account model and sign in process.
It is difficult to replicate the inactivity that would trigger a timeout warning​. In the sessions, participants were not inactive for long enough. We decided to trigger the timeout warning after two minutes to gauge their reaction, then explained later that this would not normally happen. 

Research findings

We found that:

• on balance, users of assistive technology were alerted more quickly to the warning on the timeout modal than the page
• users were clear on how to remain signed in and that they would be signed out if they took no action
• on the warning page some screen readers read out the standard page elements before the timeout message, which introduced distractions and meant it was not immediately clear users had received a timeout
• when the timeout modal was triggered on mobile devices, screen readers focused on the CTA button before reading the rest of the warning content - however, this was not a blocker for users
• counting down by minutes, and then 20 second intervals in the final minute, worked best for both sighted and non-sighted users
• having a secondary action (sign out) did not impact users’ understanding

Conclusion

From these findings, we decided that an accessible modal should be the primary approach to warn users of a service timeout. The timeout warning page design was still accessible for users of assistive technology so could be used if JavaScript is not running on the user's device.

[tomyems]

Clearly ideally we'd use a modal timeout, however due to technical and delivery constraints sometimes this isn't possible. We know from your research that:

warning users in advance that the service will time them out after a period of inactivity caused confusion and anxiety – generally they misunderstood it as having a time limit to complete the task

However, where a modal isn't possible, then warning users in the only thing you can do. For https://www.ask-question-about-electronic-travel-authorisation.homeoffice.gov.uk/start, we used (without research):

If you do not do anything for 20 minutes, your answers will not be saved. Your question is only saved when you submit the form.

[tomyems]

Afternoon :)

We had a question from one of our delivery teams about the vertical alignment of the 'Sign out' link/button with respect to the Stay signed in button - in particular in the desktop layout? What would you recommend?

[StephanieLongden]

Hello @tomyems
We followed the GDS guidance for multiple actions and aligned them horizontally. There are not likely to be more than 2 actions that will be added to a timeout so it will not get unwieldy. We didn't have any findings in our research to suggest that this horizontal pattern of the actions should be changed for desktop so would recommend this.

However, I can see an argument that they are a different sort of action as 'sign out' isn't directly related to the form so have seen some designers place this kind of link below the primary action button.

Interested to hear your thoughts :)

[tomyems]

Ahhh I phrased this badly (sorry!), so the button and link are in a horizontal row - I agree and makes the most sense. How do you decide where the best place to position the link (as I think it has a smaller height than the button), do we align it so that the bottom of the link text is in line with the bottom of the button text?

[StephanieLongden]

Ah I misunderstood, apologies! Yes, I'd suggest aligning the bottom of the link text and the bottom of the button text.

[benjest85]

As part of design system working group call, the use of timeouts inconsistently across services was questioned. It was mentioned that some services might not have any timeout warnings at all, which conflicts with WCAG requirements that services should warn users if timeout is within 20 hours.

Separately, Will Richard's team has uncovered some findings regarding the pattern and will look try encourage contributing them to this discussion.

A good example of where this is applied elsewhere is HMRC DS

[benjystanton]

Hi all, we've discovered some evidence around when not to use this pattern.

We have a service that allows operational staff to monitor tasks in different regions. They need to constantly watch a dashboard in case new tasks arrive or existing tasks become high priority. They also have to monitor other dashboards at the same time. These other dashboards might obscure our service. So they may not be directly interacting with our service all the time.

Currently our service times out after 30 minutes and forces users to log in back in. We've had strong feedback from user groups that this is frustrating for them.

We have written a new user story to cover this…
As a [user] I want my [service] to remain active and open in the background while I work on other applications, so that I do not miss any important updates, and so I don't have to log back in every 30 minutes during the day.

For these specific user groups and scenario, we plan to turn off the automatic timeout. We think this is safe, because this user group are small, work in relatively closed environments, and we can control who gets this feature by using our existing role profiles.

Perhaps we can add a summary of the above to the "When not to use this pattern" section in the design system?

[benjystanton]

Have had some challenges on this, don't have all the answers yet, but there are the things I'm looking into…

• have we spoken to any data security folks about removing the timeout?
• do they have any guidance about when it is and isn't appropriate to remove the timeout?
• would it be safer to just extend the time out, rather than turn it off completely? Even in controlled environments, perhaps there is still a risk that having no timeout might be exploited?

[benjystanton]

Initial response from security team is…

• They would prefer extending the timeout, not switching it off completely
• Whether or not the devices themselves also have a timeout will affect the decision

[GenevieveParke]

Has anyone implemented timeout when javascript has been switched off?