Service timeout

[mikeash82]

@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

1) What type of issue did you experience? Time out function without warning for blind users.

2) Where was the issue? Please give the URL. Identified on the ‘happy path’ section (journey 1.)

Screen shot 2 showing time out message:

3) 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.

4) 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. Start application again If you don’t want to start again, you can Return to GOV.UKlink>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 wrote: > > Meeting notes > > Attendees > > @roblav > @bethnoble > @gavinwye > Notes > > The work on the pattern to date has been done by @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 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 is doing an accessibility review of the two patterns. > We will try to combine the interface design of @edwardhorsford 's pattern with the accessibility improvements of @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 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 to help out from an interaction design perspective > @gavinwye to speak to @fred-jackson about supporting from a content design perspective > @roblav to build the pattern into the design pattern's prototype > @fred-jackson to review content for the pattern and suggest content variations that meet the needs of HMRC services > @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 , or mute the thread . > @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](https://www.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

tag. This is great for ensuring it isn’t dependant on JavaScript, but fails to correctly work on those browsers that don’t fully support the dialog tag yet. 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](https://hmrc-design-patterns.herokuapp.com/) 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. `` 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: 1. the component 2. 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. - [Timeout warning](https://github.com/alphagov/govuk-design-system-backlog/issues/104) - [Timeout page](https://github.com/alphagov/govuk-design-system-backlog/issues/103) - [Modal dialogue](https://github.com/alphagov/govuk-design-system-backlog/issues/30)

[stevenaproctor]

I think this is covered by #30, #103 and #104. Do you think we should add our comments to those issues?

[ghost]

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.

[edwardhorsford]

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).

[terrysimpson99]

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?

[terrysimpson99]

There's a 30 minute timeout on the following service:

[terrysimpson99]

There's a 1 hour timeout on

[terrysimpson99]

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)?

[titlescreen]

@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.

[hannalaakso]

@mikeash82 Is this issue a duplicate of https://github.com/alphagov/govuk-design-system-backlog/issues/104 and https://github.com/alphagov/govuk-design-system-backlog/issues/103?

[hannalaakso]

Closing this as duplicate of https://github.com/alphagov/govuk-design-system-backlog/issues/104. Comments have been moved over to that issue.