Time out warning - Design decision

🤔 What is a time out warning and how is it used?

Whilst working on a Government facing service, we needed to create a time out warning for users which warns them about their session timing out. According to the WCAG all public services with session timeouts of less than 20 hours should be doing something similar, otherwise they're not meeting this bit of WCAG 2.1 here:


Success Criterion 2.2.1 Timing Adjustable

If a session is discarded after less than 20 hours, we must provide the facility to either:

  • Turn off the timeout

  • Adjust the timeout via a setting (make it longer)

  • Offer to extend the timeout with at least 20 seconds notice

Our service was following this rule, however in order to implement this feature, it would require the use of JavaScript and this impacts the way we design quite a lot.

Within government services websites are designed with a progressive enhancement first approach, ensuring the site is in layers of HTML, CSS and then JavaScript only if it's necessary. This is because we might not know what kind of systems our users access our sites on, so we build them in a way to make our site accessible for all.

❓Problem statement

Keeping progressive enhancement in mind, we had to design a time out warning which would consider a core element approach first. There were a few designs that were explored (with and without JS) and compared to other designs from GDS directly.

📊 Solution hypothesis

  • hoping to come to a conclusion on a design which is resilient and inclusive for all our users

  • the decision will be successful if it has been thoroughly investigated and all possible options have been explored

🌈 Design options

1️⃣ A simplified approach

This is a simple design which uses the error summary component from GDS and shows the user the timeout warning as an error. Letting them know that their session has time out and they will need to sign in again if they want to continue from where they left off.

⛔ Limitations of this approach: This uses no JS and can be good for a core HTML/CSS approach. However, there is no warning for when this may show up so it doesn’t really solve our problem.

✅ Solution: To have a time-out which consists of a warning message as research from GDS shows that when there is no warning it can prove disorienting for users; a warning must be provided and where possible the option to delay the time out.

2️⃣ An enhanced approach

The enhanced approach consists of using a modal dialogue box to pop up when the user is about to timeout and if no action is taken they get signed out (timed out) to another page letting them know of what has happened and they need to sign in again.

⛔ Limitations of this approach: This uses a JavaScript modal which would mean that we'd have to use progressive enhancement for this component.

✅ Solution: To revert to original option of a simplified warning message when user will time out.

As this seems like the most user intuitive solution, our team carried out a technical spike in which we deemed it doable.

💭 What did GDS think of all this?

During our design process we went through extensive research into what kind of components already exist in the GOV.UK Design System. In the course of our research, we found that GDS were 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.

Their example

This modal dialogue was tested by a government department to meet the WCAG 2.1 Guideline 2.2 Enough Time.

Here is a link to some more of their modals which are still experimental but open for anyone to use within their own service (after appropriate research and testing of course)

Accessibility:

Here is some of the accessibility acceptance criteria provided by GDS when they decided to start work into building a modal dialogue component for the design system:

  • Must meet WCAG 2.1 AA guidelines

  • Not depend on colour to communicate information

  • Handle cases where user changes their default colours

  • Be focusable with a keyboard (If an element eg. button triggers the dialog, that element must also be keyboard focusable.)

  • Inform user that an alert dialog has opened

  • Constrain focus to dialog

  • Return focus to element that had focus before the dialog was invoked.

  • Be possible toclose. Be clear how to close. Examples of ways to close are pressing Esc and a close button.

  • Underlying page content must not look actionable.

  • Prevent scrolling of the underlying page.

  • Should always be visible - regardless of scrolling, screen size or orientation changes

  • The controls must be large enough to tap accurately with one finger

  • It must be possible to activate the controls using voice commands (see Coding criteria).

  • The contrast between the modal text label and its background must meet (or exceed) a ratio of 4.5:1

  • The markup must validate against HTML5 validator

  • The content must be in a logical order in the source code

🕵🏻‍♀️ Getting in touch with a GDS advisor and speaking to other colleagues within the department

At this point we were torn between using a simplified approach or using the enhanced approach as our developers had already tested to make sure it could work - however for future design assessments we needed to be sure our decision was a well thought out one and we had explored all areas before concluding.

💪 Conclusion

After going through all the possible design options and speaking to various people, we eventually decided to proceed with a progressive enhancement approach which consists of a modal dialogue as it was the option that was tested by our developers and also user friendly.