-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Service timeout #175
Comments
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). |
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? |
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)? |
@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. |
@mikeash82 Is this issue a duplicate of #104 and #103? |
Closing this as duplicate of #104. Comments have been moved over to that 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:
![selection_014](https://cloud.githubusercontent.com/assets/660238/22776879/4cde1274-eea9-11e6-927a-85ad3d7f648e.png)
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
Online references
@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:
Thoughts:
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:
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.
This isn't an issue as they are still on the page, at the same point in the service.
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
@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
![lost-creds-timeout](https://cloud.githubusercontent.com/assets/20441114/24193038/c594a66a-0ee8-11e7-9d35-b7882e13311e.png)
2SV - this one is displayed when access code text (or call back) takes too long to arrive
![2sv-timeout](https://cloud.githubusercontent.com/assets/20441114/24193049/d0229de4-0ee8-11e7-94c7-9a6b4d44df10.png)
@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:
<title>For your security, you will be signed out in 1 minute. Stay signed in@gavinwye commented on 30 Aug 2017
Meeting notes
Attendees
Notes
Actions
@chrismoorembe commented on 31 Aug 2017
I’ve taken a look at the proposed GDS time-out modal with JAWS 17 for Windows, and the current versions of VoiceOver screen reader for Mac and iOS.
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.
The modal worked fine on Chrome, Firefox and the latest version of Safari on the Mac. Focus is moved to the action button to extend the session and there is a keyboard trap so non mouse users can’t stray outside the modal.
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. Robert’s prototype worked across all browsers and assistive technologies and this was also independently tested by the Digital Accessibility Centre.
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.
I also didn’t expect the ‘Cancel’ link to take me back to the GOV.UK home page.
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.
If less idle the modal box will close the application and the user will b taken to a page that explains to the user what happened and why, and what they can do next.
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.
The GDS wording for the time-out modal is:
Alert:Your application will time out soon
We will reset your application if you do not respond in 1 minute. We do this to keep your information secure.
Useful additional information: you have not left the current page. If you close this modal, you will be able to continue with your current application.
Continue application (button)
Save application
Cancel application
Comment:
This could be much simpler, less verbose and I don’t think real users will know what a modal is.
Suggestion:
"Alert:Your application will time out soon
We will reset your application if you do not respond in 1 minute. We do this to keep your information secure.
Continue using application (button)"
When the user is finally kicked out for inactivity, they get the following message:
<TITLE>You’ll have to start again</TITLE>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 againIf you don’t want to start again, you can Return to GOV.UK</link.
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:
“
<TITLE>You’ve been signed out</TITLE>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.
@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:
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.
Sounds like a bug for @hannalaakso to look at. We intend to support a wide range of AT.
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'd consider this placeholder / prototype. There will likely be a secondary link and it will likely go somewhere.
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.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.
Agreed - will talk with a content designer about this, and making it simpler.
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.
This is a mistake in the prototype.
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.
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.
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.
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
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.
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 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>
@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:
@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.
The text was updated successfully, but these errors were encountered: