Open govuk-design-system opened 6 years ago
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
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:
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.
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.
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.
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.
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.
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:
These are:
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.
that's amazing @hannalaakso thanks for this!
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."
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."
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?
Does anybody have any comments on Jennifer's question?
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:
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.
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.
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.
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?
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:
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.)
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
Related patterns
103 Timeout page