govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
alphagov
Timeout warning
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
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.
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
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
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.
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?
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: https://github.com/alphagov/govuk-design-system-backlog/issues/207
Comment by @mikeash82, copied from #175 (duplicate issue):
@gavinwye commented on 31 Jan 2017
Originally discussed on HMRC internal Slack by @adamfenwick in collaboration with @roblav
@roblav commented on 9 Feb 2017
Feedback from Repayments project DAC report:
Page refresh
WCAG 2.0 References: Provide users with disabilities enough time to read and use content.
WCAG 2.0 reference 2.2 - Enough time https://www.w3.org/TR/WCAG20/#time-limits
Pages that are refreshed periodically can cause access problems for people with disabilities. Some with disabilities simply need more time to finish reading a page or completing a form. Refreshing the page before the user has finished using it can be a very frustrating experience; particularly if the session is reset and any interaction with the page, such as a partially completed form is lost.
Although we appreciate that session time-outs are important for security, these must not prohibit disabled users from using the website.
Result = Fail
A time-out was present that resulted in users being logged out after a certain time of inactivity. As it may take some users longer than others to complete tasks online, it is important that a warning is presented to inform of this functionality and where possible the option to extend this time.
High priority A
Technical Comment: Time-out without warning
Issue ID: DAC_TECH_Refresh_Issue1
Screen Shot:
There is a time-out feature present on the service that does not warn users that this is the case. This can prove disorienting for users; a warning must be provided and where possible the option to delay the time out.
Issue ID: DAC-USER-SRTB-T1-02
-
What type of issue did you experience? Time out function without warning for blind users.
-
Where was the issue? Please give the URL. Identified on the ‘happy path’ section (journey 1.)
Screen shot 2 showing time out message:
-
Describe the issue in detail and where it occurred on the page While attempting to enter account details, I found that blind Talkback users will be logged out without warning if no activity has been detected.
-
How did you work around this issue? There is currently no work around for this issue.
Solution
For each time limit that is set by the content, at least one of the following is true:
Turn off: The user is allowed to turn off the time limit before encountering it; or Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times; or Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or Essential Exception: The time limit is essential and extending it would invalidate the activity; or 20 Hour Exception: The time limit is longer than 20 hours.
@roblav commented on 9 Feb 2017
Here's the pattern that was created by Jen Rahman and Billy Adamson.
We followed the guidance of Chris Moore, our very own Accessibility champion, about the implementation using a modal box, implementing our solution using the criteria that follows.
Make sure the modal dialog box is accessible
- If you use a modal dialog box then you must make sure it is accessible by doing these things:
- set the role attribute to 'dialog' - give the containing element of the dialogue the 'dialog' role. This will inform screen readers they’re dealing with a dialogue
- on open, keyboard focus must be assigned to the dialogue (give it tabindex=-1 to allow this)
- give the dialog a name using either aria-label (to put the name in an attribute) or aria-labelledby (to link it to the id of an element with its name like a heading) that is recognised by assistive technologies
- whilst open, keyboard focus must be constrained within the dialogue
- it must be possible to close the dialogue via a close button and/or with the escape key
- on close, keyboard focus must be returned to the original point on the page
- visually fade the underlying page whilst a modal dialogue is open. This helps users of screen magnifiers understand why they’re unable to interact with the underlying page
- prevent scrolling of the underlying page whilst a modal dialog is open. The user should not be able to interact with the original page whilst it's open.
- test thoroughly on a range of screen sizes to make sure they work properly
Online references
- https://designpatterns.hackpad.com/Modal-dialog-boxes-ZJNqssq4Dll
- http://www.nczonline.net/blog/2013/02/12/making-an-accessible-dialog-box/
- http://www.w3.org/WAI/GL/wiki/Using_ARIA_role%3Ddialog_to_implement_a_modal_dialog_box
@feedmypixel commented on 9 Feb 2017
@roblav thanks for the contribution. Some comments we had in slack that are worth exposing in this issue:
IMO what is needed from session timeout:
- explain when a user is logged out and why they have been logged out
- if possible save data they have submitted in the journey so far
- if possible return user to same place in journey before they were logged out when they log back in so any disruption is minimal
Thoughts:
- if a user is not using the page then it should timeout (granted)
- if a user is not using a page it's highly possible they will not see a modal window telling them they are going to timeout
- the user doesn't know or care about the session
- the user will be reassured we log out for security reasons after a period of time
To start with I'd ask what is the user need? and how can we address this in a progressive and accessible way?
A good read around modals
https://developer.appway.com/screen/ShowSingleRecipe/selectedRecipeId/1390246496349
@adamliptrot-oc commented on 9 Feb 2017
Whilst inline alerts described by the linked article are generally preferable to dialogs, the difference between this and the examples cited is that those examples are the result of direct user interaction triggering the dialog and user focus is on the particular part of the screen where the alert will be inlined. Here we are talking about something which is not a result of user interaction and needs to be brought front-and-centre for the user. For example, in the case of a user employing a screen magnifier, what would the solution be for an inline alert given the user might be quite literally focussed on a different part of the page?
In addition, the examples don’t have any major consequences if the user does not interact with the dialog, whereas in the case of the timeout they can be signed out.
What we don't want is for this dialog pattern to be taken as a reason to introduce more dialogs where inlined alerts would be preferable. So if progressed I think we'd need a set of preferred patterns developing to cover other instances where people might think to employ a dialog (such as those in the linked article).
@adamliptrot-oc commented on 9 Feb 2017
I think the 20-hour exemption quoted in https://www.w3.org/TR/WCAG20/#time-limits feels a little arbitrary. We’re currently running with an extended session timeout of 30 mins on our service and will be gathering data about how this additional time assists all users by preventing unwanted session ends.
@roblav commented on 9 Feb 2017
In response to your the above comments:
IMO what is needed from session timeout:
- explain when a user is logged out and why they have been logged out
The content provided in the modal has been supplied by the content/design team, and has been approved by Chris Moore. It explains that it is for the users security that they will be signed out.
- if possible save data they have submitted in the journey so far
This isn't an issue as they are still on the page, at the same point in the service.
- if possible return user to same place in journey before they were logged out when they log back in so any disruption is minimal
This happens already as required by the criteria given in Make sure the modal dialog box is accessible - on close, keyboard focus must be returned to the original point on the page
@feedmypixel commented on 9 Feb 2017
In response to your the above comments:
@roblav thanks. My thoughts were about providing these needs without a modal. Then potentially there may be no need for one.
The question for me is what is the original pain point for users and how we can mitigate against those, that was what my thoughts were around.
Also if these things can be solved without JavaScript it makes it all the bit more resilient.
@timsb commented on 23 Feb 2017
Hi all, I found this this morning and thought it might be helpful - http://blog.barrierbreak.com/2017/02/14/modal-dialogs-and-accessibility-a-tricky-minefield/ It has some useful points on creating accessible modal windows but I must admit that the mailing list I got this from had the sub-heading 'Of course, the simplest solution is to stop using them'.
@david-mcdowell commented on 22 Mar 2017
Hi, I've recently created some new timeout screens for lost creds and 2SV registration.
Lost creds - the user will see this error during a lost credentials flow. I think the inactivity is set to 7 minutes
2SV - this one is displayed when access code text (or call back) takes too long to arrive
@david-mcdowell commented on 22 Mar 2017
We also use this one in the IV journey, usually appears if the user takes too long to find evidence options. e.g. they've gone to find a payslip to prove their identity and it takes too long.
@david-mcdowell commented on 22 Mar 2017
this one also got sent round the design team and I thought it was useful to inform my thinking.
@alex16wake commented on 25 Jul 2017
On SCRS we have a modal window that someone else has mentioned and we used this because it has been approved for accessibility and tested well with users when we did some scenario testing. Example below
@stevenaproctor commented on 26 Jul 2017
I think we need to look at the content of all these suggestions. There is a lot of jargon that could be made simpler. Things like timeout, inactivity, session are web jargon.
For a modal, screen readers must announce the title and set focus to the link or button at the same time. Not all content may be read out.
Something like:
Your application has timed-out
We have reset your application because you did not do anything for 10 minutes. We did this to keep your information secure.If you don’t want to start again, you can Return to GOV.UK</link.
link>Delete data
Comment:
We usually advise that the page title and H1 should mirror each other, but they don’t in this pattern.
Has it been determined that 10 minutes is all we now need to allow before a product or service times out? We are currently giving 15 minutes on HMRC services
The wording above refers to the service as an application. Is this wording being used because the service is enabling the user to apply for something?
Are we able to amend the wording to meet our BTA/PTA needs?
For example:
“
You’ve been signed out
We have signed you out of your account. because you did not do anything for 15 minutes.
We did this to keep your information secure."
I am not sure what timed out wording we are currently using within Robert’s prototypes, but I’ll leave the crafting to Steve and Fred.
On 30 Aug 2017, at 18:34, Gavin Wye [email protected] wrote:
Meeting notes
Attendees
@roblav https://github.com/roblav @bethnoble https://github.com/bethnoble @gavinwye https://github.com/gavinwye Notes
The work on the pattern to date has been done by @roblav https://github.com/roblav without support from an interaction designer. We need to find people to support this side of the work. The pattern will be owned by the pattern library and in time will be supported by the patterns working group. @edwardhorsford https://github.com/edwardhorsford at GDS has been working on a similar pattern. We prefer the design of this compared to our pattern but think we may have done more work to make the pattern accessible. @chrismoorembe https://github.com/chrismoorembe is doing an accessibility review of the two patterns. We will try to combine the interface design of @edwardhorsford https://github.com/edwardhorsford's pattern with the accessibility improvements of @roblav https://github.com/roblav's version. We need to ensure that the content for the pattern covers all services at HMRC. We will try to make the content as generic as possible adding additional content as necessary for individual services We don't want to use terms like time out, interactivity and session as @stevenaproctor https://github.com/stevenaproctor pointed out in his comment above. Once we consider the pattern to be usable by a number of services we will review it again and submit the pattern to the HMRC working group for review and inclusion in the HMRC pattern library. More user research is needed on the pattern. There has only been one round of research to date. However, as we will be iterating the design of the pattern we will need to ensure that the pattern is useful for users. We will aim to upstream any useful work to the rest of Government. Actions
@gavinwye https://github.com/gavinwye to help out from an interaction design perspective @gavinwye https://github.com/gavinwye to speak to @fred-jackson https://github.com/fred-jackson about supporting from a content design perspective @roblav https://github.com/roblav to build the pattern into the design pattern's prototype https://github.com/hmrc/design-patterns @fred-jackson https://github.com/fred-jackson to review content for the pattern and suggest content variations that meet the needs of HMRC services @gavinwye https://github.com/gavinwye to ensure that the interface and interaction design is consistent with the rest of government. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hmrc/design-patterns/issues/89#issuecomment-326063739, or mute the thread https://github.com/notifications/unsubscribe-auth/ATkM54gg7e-Z-d7ILiNOE1QAT23XyppFks5sdZ0IgaJpZM4Ly3E0.
@stevenaproctor commented on 31 Aug 2017
@gavinwye @bethnoble
I worked with @roblav on the content of his alert and me and @rebekah-barry from DWP made suggestions to @edwardhorsford for GDS's.
I totally agree with @chrismoorembe that the content is too long. Do people need that much explanation? Does it add value at that moment in time?
We should avoid 'sorry' because we are not sorry, 'modal', 'timed out' or any kind of web jargon.
There needs to be at least 2 versions: one for a service you are signed in to, and one where you are not. I have taken a look at the content we suggested and refined it a little. Hopefully this will help @fred-jackson.
For a service you are signed in to Title: For your security, we will be sign you out of this service in 5 minutes. Any information you do not send or save will be deleted. Button: Stay signed in Link: Sign out
The second sentence in the title is optional. If you have save and return you could say "Your details have been saved."
The link should be under the green button not floating to the right of the button. That looks odd to me and means the button is on the left of the box and not full width like it is on a transaction page.
For a service you are not signed in to Title: For your security, we will clear your details in 5 minutes. Button: Continue Link: Clear my details now
Again, the link should be under the green button not floating to the right of the button.
The link should take them to the service's start page. It is not logical to take them to GOV.UK because they may never have been there during their journey.
When you have been signed out Again, there needs to be 2 versions of this.
If they are signed in to the service:
Title: You have been signed out H1: You have been signed out Paragraph: For your security, we signed you out of this service because you did not do anything for 15 minutes. Any information you did not send or save was deleted. Button: Sign in
Again, the second sentence in the paragraph is optional and could say "Your details have been saved." if the service has save and return.
If they are not signed in to the service:
Title: You will have to start again H1: You will have to start again Paragraph: For your security, we cleared your details because you did not do anything for 15 minutes. Paragraph: If you do not want to start again, you can explore GOV.UK. Button: Start again
@edwardhorsford commented on 31 Aug 2017
Hi @chrismoorembe / @stevenaproctor @gavinwye ,
I worked on our modal design with @hannalaakso. She can hopefully take a look at the HMRC modal and your findings. Ideally we'd get the best of both. Our intention (and the bulk of the work) has been on accessibility.
We've so far taken it through 2 rounds of user research, with 2 more to follow. So far it as worked very well, with some content tweaks in the last round. Understanding of it has been really high - everyone seems to know what 'timed out' means.
Has anyone observed users using browser back when the modal opens? I'm planning adding something to the history when it opens so that if they do use browser back, they stay on the current page (and delete from history when closed).
@chrismoorembe going through your comments in turn:
The first thing that struck me about the modal is that it has been coded to use the
It's meant to - must be a bug. This is a similar implementation to the one I shared with you last year that you liked.
When testing with IE11, the modal doesn’t behave completely as expected as there is no keyboard trap, and the button that has default focus is not automatically announced. Also, the modal completely falls over while using Safari on iOS. This is a deal breaker for me, as in the last GOV.UK assistive technology survey, both IE11 and Safari for iOS were the 2 most commonly used browsers with screen readers.
Sounds like a bug for @hannalaakso to look at. We intend to support a wide range of AT.
I also feel that the content being used inside the modal is more verbose than it needs to be, and that having 3 actions falls short of simplicity.
Agreed. I am going to work with our content designer on it. I don't think we need to say so much. We're trying to satisfy our accessibility acceptance criteria that users know when a modal has opened - I think we can do this whilst saying less.
I also didn’t expect the ‘Cancel’ link to take me back to the GOV.UK home page.
I'd consider this placeholder / prototype. There will likely be a secondary link and it will likely go somewhere.
To keep things simple, I think there should be only one action within the modal to extend the time-out. The user should be able to trigger this by the escape key to dismiss the modal, activate the default action button by spacebar, enter, tap or mouse click. If the time out is extended, the user can either save their current information or continue with the application.
The intention is for there to be only one way to extend. Do you see more than one? I'm unsure whether esc should extend it though.
The timed out page on offer by GDS also enables the user to go back to the GOV.UK modal, so I feel that including ‘Cancel’ within the modal offers little value. The user also has the option to delete their data, but how this differs to the application being reset may not be clear to users. If the user chooses to leave the page, go back to the GOV.UK home page or close the application, we should automatically delete the data.
This is a artefact of the prototype. In a real service, once you've timed out, you won't be able to return to where you were.
This could be much simpler, less verbose and I don’t think real users will know what a modal is.
Agreed - will talk with a content designer about this, and making it simpler.
Continue using application (button)
I suspect many services will need / want a secondary action - either to quit the application, or to save and return later. This will be for services to decide.
We usually advise that the page title and H1 should mirror each other, but they don’t in this pattern.
This is a mistake in the prototype.
Has it been determined that 10 minutes is all we now need to allow before a product or service times out? We are currently giving 15 minutes on HMRC services
We're using an artificially short time in user research so the modal shows up more frequently. Ultimately the timeout will be for services to decide. I expect our guidance to be that it shouldn't be less than 15 minutes, ideally 30 minutes or more. We'll likely advise the timeout warning comes up 5 minutes before timeout.
The wording above refers to the service as an application. Is this wording being used because the service is enabling the user to apply for something?
Yes. Aspects of the wording will need to change depending on the type of service - particularly whether it includes any form of 'save and return'.
@stevenaproctor
We're hoping to have two sets of content - but services will obviously have to adapt these to suit their needs. There's actually a third case as well where users have successfully applied for a thing (and are on the completion page), but then time out. In that case, they don't need to start again, because they're done.
The link should be under the green button not floating to the right of the button. That looks odd to me and means the button is on the left of the box and not full width like it is on a transaction page.
I'm unconvinced about this - we do it in several places on GOV.UK. Whats your thinking? FYI buttons are only full width on mobile, not on desktop. If you open this modal on mobile, you'll get a full width button.
Any information you do not send or save will be deleted.
I'm wary of this sentence - I don't think it's clear how you might go about 'sending' something or what the user needs to do. They can't actually send or save anything from this page - so what are they meant to do with this sentence? The real answer is that if they do nothing, any information on the current page will be lost.
@stevenaproctor commented on 31 Aug 2017
@edwardhorsford
We're hoping to have two sets of content - but services will obviously have to adapt these to suit their needs. There's actually a third case as well where users have successfully applied for a thing (and are on the completion page), but then time out. In that case, they don't need to start again, because they're done.
This is a good point. You could drop the optional line or put something in to reassure them that we still have whatever it is. This would need to follow through to the timed out page.
I'm unconvinced about this - we do it in several places on GOV.UK. Whats your thinking? FYI buttons are only full width on mobile, not on desktop. If you open this modal on mobile, you'll get a full width button.
Great that you get a full width button on a mobile.
I think having a button and a link next to one another looks odd because they are so different to one another. Two buttons next to each other looks OK.
Floating the link in the middle of the button may be bad for horizontal scanning in the same way that vertically aligning content to the middle of a cell is bad in a table. It definitely stops me when I see it like this.
I'm wary of this sentence - I don't think it's clear how you might go about 'sending' something or what the user needs to do. They can't actually send or save anything from this page - so what are they meant to do with this sentence? The real answer is that if they do nothing, any information on the current page will be lost.
I agree this could be better but it is optional. All of the services I have worked on have a ‘confirm and send’ button at the end. The GDS content style guide says 'send' is better than 'file' or 'submit'. This is what I mean by 'sending'.
It is not just information on the current page you may lose. You could be 20 screens into a 21 screen journey and lose everything if you are timed out. It depends on the service.
A tax credits version because we do not have save and return would be something like ‘Any changes you do not confirm and send will be deleted.’
@gavinwye commented on 31 Aug 2017 Thanks for the comments everyone.
I think the next steps are to get the HMRC version of this built into the pattern library prototype taking account of all the feedback above and we can then discuss once we have something to look at.
@hannalaakso commented on 8 Sep 2017
Hi @gavinwye
Thanks for taking a look at the modal prototype. We are actively developing and testing it, it’s not yet entered our alpha phase so we are cataloguing and prioritising bug fixes.
We've got a card in the backlog for the IE11 issue where the focus gets lost when you tab "past" the modal.
I'm reviewing the iOS VoiceOver bug. I did testing on VoiceOver before but the timer countdown was a late addition and I kept tweaking it for AT so I suspect that could be the reason.
The component takes advantage of the native dialog element and polyfills with Google's Modal Dialog polyfill for browsers that don't support the dialog element. We’ve so far found the combination to be robust in cross browser/device and AT testing.
I wrote some accessibility acceptance criteria for the component: https://gist.github.com/hannalaakso/2641fc16d2158e60d551cd9da960b5da
I sent this to the X-Gov Accessibility mailing list for review and it was reviewed by our Accessibility team here too.
The modal currently fails number 7 since no browser supports this.
HMRC modal:
We did some AT testing on the link you provided for the modal. A couple of bugs were discovered:
On NVDA + Firefox 53.0.3 + Windows 10, the contents of the modal do not get read out so there is no AT notification that a timeout is about to happen.
On iOS + Safari and Jaws 18.0 + IE11, the count down only gets read out only once “For your security, you’ll be signed out in 1 minute” before time out. The user would miss hearing this first announcement if they return to the application after the modal is triggered.
We’re getting around the above by announcing the changed countdown time once a minute to screen readers until the count is down to the last minute which is when we announce every 20 seconds and then every 10 seconds for the last 30 seconds. These timings are still due to be reviewed but that's the general idea.
Really happy to share work and thinking.
@adamliptrot-oc commented on 8 Sep 2017
Something to be aware of if using js to count down, is that browsers will 'sleep' tabs which are not in focus (eg not the active tab in a window), which will throw out this timing. On our modal I did a timestamp comparison when the page regained focus to check if the user would have been timed out already and act appropriately.
@edwardhorsford commented on 8 Sep 2017
Thanks @adamliptrot-oc good advice. I think we're going to have to do more work on how we calculate the times - really the decision of when / whether to timeout is something for the server. The timeout should ultimately be communicating with the server to know when to display / delay.
@roblav commented on 8 Sep 2017
I've created a PR for the HRMC version which looks like this,
User Research
The pattern was tested in July 2017 with 5 users. Two of them have special needs: one is dyslexic, and the other was 70 at the time of testing.
The 5 users understood the message and managed to used it – all of them stayed signed in.
Browser & device testing
This pattern has been browser and device tested based on the following the GDS guidelines https://www.gov.uk/service-manual/technology/designing-for-different-browsers-and-devices
Accessibility testing
The modal works fine with ZoomText. The modal to be fully accessible and both visually and audibly accurate.
Configuration options:
To make the session timeout modal as useful as possible there are default settings with the options to pass in custom values. Here is an overview of those configuration options.
<script type="text/javascript"> $.timeoutDialog( { timeout: @appConfig.defaultTimeoutSeconds, countdown: 60, title: 'You’re about to be signed out', message: "@Messages("taxcalc.timeout.message")", keep_alive_url: '/tax-you-paid/keep-alive', logout_url: '/tax-you-paid/timeout' }); var dialogOpen; </script>
| Key | Value | Description |
|---|---|---|
| timeout: | @appConfig.defaultTimeoutSeconds | The default timeout setting on the platform is 15 minutes. |
| countdown: | 60 | This sets the countdown timer in seconds. This value minus the timeout value will determine when the session timeout modal appears i.e. 15 mins - 60 seconds = 14 minutes. |
| title | You’re about to be signed out | Adds a heading to the modal, if required, by default this is not displayed. |
| message: | "@Messages("taxcalc.timeout.message")" | Message to display in the modal. |
| keep_alive_url: | '/tax-you-paid/keep-alive' | This endpoint needs to be set up in the service to return a 200 OK when the user selects the link to extend their time. |
| logout_url: | '/tax-you-paid/timeout' | If the user doesn’t select the link to extend their session they get automatically directed to this URI |
@gavinwye commented on 8 Sep 2017
A thought. The configuration of the time out is good for a per service basis as not all services will have the same requirements for this.
@stevenaproctor commented on 11 Sep 2017
I still think the content is too passive.
title: We are about to sign you out
message: For your security, we will sign you out of this service in 2 minutes.
Is the title and the message read out automatically by a screen reader? Or do you have to go through the dialog the way you would go through a screen?
@stevenaproctor commented on 25 Oct 2017
@gavinwye Do we need a separate pattern for the timed out page we send someone to?
@gavinwye commented on 25 Oct 2017 @stevenaproctor I think there are two things here:
- the component
- the pattern that explains the whole thing end to end.
@gavinwye commented on 30 Oct 2017 I'm starting to put this into the design system
@stevenaproctor commented on 16 Jan 2018
@roblav This has been added to the design system as a work in progress. See http://hmrc.github.io/assets-frontend/components/timeout-dialog/index.html
We will still need to work on the documentation and the wider timeout pattern.
@lizhitchcock commented on 10 May 2018 I understand why 'We signed you out' (I think it's now For your security we signed you out'.) However I've been struggling with We saved your stuff and We did not save your stuff. It sounds intentional or worse as though we made a choice. The signing out is our choice as we decided this timing to keep information secure. The saving or not saving is just what happens after that, so it should revert to the less personal Your answers have not/have been saved.
Similarly I think it's OK to say For your security we cleared your details (but never OK to say 'Explore GOV.UK - it's not a mysterious mansion).
@stevenaproctor commented on 16 May 2018 @lizhitchcock The saving or not saving is kind of our choice. It depends if the service does it or not. I think changing from active to passive would be odd.
I totally agree about the 'Explore GOV.UK' link. I have always thought it odd when it appears on sign out pages and error pages.
@stevenaproctor commented on 10 Oct 2018
This is on the GOV.UK Design System backlog. There are 3 relevant issues.
Comment by @kim-code, copied from #175 (duplicate issue):
In relation to this, we have received a DAC report stating that we should be warning the user BEFORE this pattern even appears, that there is a timeout feature in place, potentially at the start of a service. Is this something that has been implemented elsewhere? Worth noting that this is a AAA standard, so classed as "low" priority, but none the less a becoming a more common comment in DAC reports.
Comment by @edwardhorsford, copied from #175 (duplicate issue):
In relation to this, we have received a DAC report stating that we should be warning the user BEFORE this pattern even appears, that there is a timeout feature in place, potentially at the start of a service. Is this something that has been implemented elsewhere? Worth noting that this is a AAA standard, so classed as "low" priority, but none the less a becoming a more common comment in DAC reports.
I'd be cautious about this - something to test. I've heard several times from other services that putting mention of things like this up front concerns / scares users. They frequently misunderstand the meaning of timeout - and for a 30 minute timeout think they'll have a limit of 30 minutes to complete their application rather than them needing to have 30 minutes of inactivity and have unlimited time overall.
Timeouts depend heavily on the service - for many services you can fill them in quickly and will rarely encounter the timeout - for these services, warning up front may unduly concern users where they wouldn't otherwise worry.
For services where you're more likely to encounter the timeout it's more important to talk about what information you might need up front and for the service team to consider how users might recover / continue their application (accounts, save & return, codes and whatnot).
Comment by @terrysimpson99, copied from #175 (duplicate issue):
I'm happy to see the phrase "Ultimately the timeout will be for services to decide. I expect our guidance to be that it shouldn't be less than 15 minutes, ideally 30 minutes or more. ".
What would happen if we acted on that?
Comment by @terrysimpson99, copied from #175 (duplicate issue):
There's a 30 minute timeout on the following service:
Comment by @terrysimpson99, copied from #175 (duplicate issue):
There's a 1 hour timeout on
Comment by @terrysimpson99, copied from #175 (duplicate issue):
The current timeout can result in user being timed out 121 seconds after being active (e.g. a key press). This is barely enough to answer the door, make a cup of tea, or have a call of nature. Has anyone developed a timeout (perhaps client-based) that measures user activity (key presses, mouse moves)?
Comment by @titlescreen, copied from #175 (duplicate issue):
@terrysimpson99 we have not. We show the timeout popup after 30 minutes. When we send someone off to verify we extend this to 60 minutes which allows almost all our users to try a couple of providers and hopefully get through.
I think those upfront warnings are potentially confusing. In those examples it says "if you do not enter" and "if you don't do anything". Unless those services are doing something with mouse movement or keypress checking extending the session, there is the possibility the user will see this required "activity" as something different to that expected i.e. the actual submission of data.
@adamliptrot-oc I suggested a solution using javascript here:
https://github.com/alphagov/govuk-design-system-backlog/issues/103#issuecomment-646271560
I had a chat with a team last week about timeout warnings and what to do if users don't have javascript.
My understanding is this wouldn't be a technical WCAG failure - as WCAG doesn't require pages to work without js. But we still want to design for progressive enhancement so ideally would do something.
An idea I had was to combine an in-page banner which gives the time of the timeout (can’t use a clock as no js), combined with a meta refresh. Importantly, we then hide this banner using a CSS transition. We set the css transition time to the time we want the banner to appear. So after X minutes on the page, this banner appears.
If any team tries this we'd obviously want to investigate how it might appear to AT - we wouldn't its content exposed before the time, and ideally would like it announced to screen readers when it's revealed.
This obviously requires CSS but I think could represent a reasonable solution to doing something for non js.
Hey @edwardhorsford on Claim a payment, we had a CSS solution that would basically start an animation that did nothing for e.g. the first 29 minutes, then it would animate to show the timeout. I think some JS also called attention to the alert via an ARIA property.
It wasn't perfect but at least it worked for people without JS who also did not have sever visual issues.
@titlescreen yeah, that sounds like a similar idea. Do you have a link to it?
i had a similar thought about replacing a modal window with a notification banner some time ago when there were concerns over accessibility issues with the modal. One thing that might need to be considered - if you set off a timeout banner you might need to pull focus on the page to the banner - in other words, if the user is at the foot of the page and the notification banner appears at the top - would you need a method of 'scroll to' the banner (if it's appearing at the top of the page) so the user has focus on the banner? Im not sure if that is achievable without JS - however my thought is that a banner method might be better than the modal. Also, would the user need to explicitly dismiss the banner notification Or would they be abe to refocus on an input field, for example, which would then dismiss the banner and reset the clock?
Hey @govuk-design-system @hannalaakso. We're working on adding the timeout warning modal dialog to the HMPO online application. The demo requires a username and password. Would be able to send that to me, please?
@veerazazi It's patterns/components. Do note that it's only a prototype and from 4 years ago. There's a bit more detail here about how it tested with users at the time: https://github.com/alphagov/govuk-design-system-backlog/issues/104#issuecomment-394620328
@titlescreen @edwardhorsford would you have links to the implementations you did for the session timeout popups?
@matthewford unfortunately I have moved on to a different job since then. It was in the claim an additional payment for teaching maths and physics service for DfE Manchester. You may be able to speak to Nick Jackson from dxw as I worked with him on the service. https://github.com/jacksonj04
@titlescreen Many thanks, if anyone else is interested the repo is here: https://github.com/DFE-Digital/claim-additional-payments-for-teaching
For the record - this pain point was mentioned for users of 'Pension Schemes Online' (will become 'Managing Pension Schemes'):
"One user in particular asks a colleague to sit at their desk and wiggle the mouse while they take a break as they fear their machine would go to sleep and the pension schemes online service would crash, in turn losing all of the data that they had entered that day."
I've been investigating an issue with the modal window in the search on GOV.UK (which opens when you click 'Filter' when in mobile view). I thought I'd share because this will affect lots of other modal windows (including the one in the ARIA Authoring Practices Guide).
It turns out that neither VoiceOver on iOS nor TalkBack on Android support aria-modal. That means that when using mobile screen readers the virtual focus is not kept in the modal window and you can swipe past it through the rest of the page behind it.
This can be avoided by polyfilling aria-modal and properly hiding the rest of the page (via display: none or aria-hidden), but that's not always possible when the code for the modal is in the middle of the page (as it is on the search page).
(I've also shared this in #30.)
