govuk-design-system-backlog
govuk-design-system-backlog copied to clipboard
alphagov
Exit this page component
This conversation has moved
On 6 July 2023, we released the Exit this Page component.
See the release notes for GOV.UK Frontend v4.7.0 to find out more.
We've created a GitHub discussion space for service teams to share feedback, use cases and research findings and have migrated this discussion there.
Formerly known as 'Hide this page component'
What
What are we proposing
We are looking to implement a component, using the existing button component, that allows vulnerable users of a Government service to quickly and safely hide the page and reduce the risk of Domestic Abuse incidents.
The functionality behind the component would allow a user to quickly hide the current page and open a new, ambiguous webpage, such as BBC Weather or another such website. This would lower the risk of drawing attention to browsing habits from a perpetrator.
Why
Why are we proposing this design pattern?
Domestic abuse is physical, sexual, psychological or financial abuse that takes place within an intimate or family-type relationship and that forms a pattern of forceful and controlling behaviour. This can include forced marriage and so-called ‘honour-based crimes.” Domestic abuse may include a range of abusive behaviours, not all of which are in themselves inherently ‘violent’
The biggest risk to a victim of Domestic Abuse is homicide and serious physical assaults - this is at its greatest risk when a victim is planning to flee or escape from the perpetrator. Often, one of the first things a victim will do is to speak to someone to make a disclosure about abuse. The second thing they will do is research and find help online, often using Government services.
We need to ensure that the risk is minimised for users when using online services. Although victims and survivors can be aware of the risks, it is the Government's responsibility to protect individuals using a service. Therefore, it is crucial that there is a consistency of approach in design and functionality across Government with this component.
What evidence do you have that it's needed by multiple services across government?
From conversations between the Department for Work and Pensions, Ministry of Justice, the Cabinet Office and Scottish Government, it is already clear that other services need to ensure that this design is available.
Services are already responding to the rise in Domestic Abuse during COVID-19 by building their own minimum viable solutions to allow users to quickly hide their webpages.
There are areas of the Government site, such as “Domestic Abuse: How to get help”, that a high risk user would access for support that does not include a way to hide their browsing. This is putting those users of this service at risk.
What evidence do you have that it meets the needs of the users of those services?
Speaking with subject matter experts (SME), it is critical that we offer this feature on the GOV.UK website. It is a feature that is provided by other organisations, such as:
Each website has varied design implementations, but ultimately addresses the same user need of being able to hide browsing habits quickly.
The Ministry of Justice have carried out some initial research with an SME to establish whether the proposed solution meets the user needs.
Have you checked that it doesn't already exist in the GOV.UK Design System?
There are no outstanding issues or tickets in the Design System backlog that refer to this type of component.
Anything else
What else has been done
The MoJ have iterated twice on the design component on our live service - looking at language, design and functionality.
There are several designs that are considered minimum viable products which have been released by the DWP (Child Maintenance Service) - Cabinet Office (Coronavirus Support) and the MoJ (Legal Aid Agency). The expediency of these releases has been due to the fact that by not having something, we are putting our users at risk.
The MoJ have carried out some early rounds of testing with an SME that have looked at design, functionality and various use cases from a range of user scenarios. This has all been documented and shared with DWP and CO to share research and findings.
Designs
We looked to extend the GOV.UK Button component to act as the interactive element that a user would press to exit the website.
The Design System suggests using red for any destructive actions undertaken on a GOV.UK website - as the intention for the 'Hide this page' button was essentially closing the webpage down, it would be deemed destructive. This has been adopted by DWP and the Scottish Government.
We decided to utilise the additional space available in the 1/3 column, which is usually reserved for additional information as it allowed us to present the button within immediate view for the user.
The button would then be "sticky" in position at the top of the page on smaller devices. This prevents any conflict with the GOV.UK 'Contents' link that is positioned at the bottom of the screen. It also removes potential accidental presses by a user who doesn't need to use it.
Feedback from SME on the design
Victims of Domestic Abuse are used to using their reptilian brain and are in fight or flight mode so the red would be a trigger for them to draw their to attention to it - Comment from SME
Content
The language used in the button has recently been changed in order to create a more unified style as we continue to work with DWP, Cabinet Office and the Scottish Government. The use of 'Hide this page' presented more of a sense of immediacy, as well as being more descriptive of what the button actually does when the user interacts with it, so we have moved away from the original 'Quick Exit'.
We also use a keyboard function for the user to be able to interact with the button which is controlled by pressing the 'Esc' key.
Behaviour and Functionality
We have explored several types of behaviour for the button, however in order to provide the greatest amount of safety for users we decided to implement functionality similar to other charities and organisations.
When a user interacts with the button, they are sent to a new browser tab that opens BBC Weather. The original tab that they were on doesn't close, but redirects to Google.
This component does not prescribe which websites are to be linked to. That is best done by the individual services and their user research combined with the knowledge of their user base. Google and BBC Weather are good neutral examples pending further research.
Accessibility
The Legal Aid Agency have had an Accessibility Audit on their service and this highlighted some improvements to the component. These were:
- Ensuring the button text accurately describes it's purpose
- Ensure the instruction "(Or press 'Esc' key)" is presented to all users when presented as a sticky element
- Include visually hidden text at the top of the page to help users of assistive technology be aware of the leave page functionality
- Differentiate betwixt mobile displays and PC displays zoomed in, so the information about using the escape key is not hidden for non-mobile narrow displays
These changes have been implemented in the latest version of the component, however we will be looking to further test the accessibility of the component as we continue to iterate on it.
MoJ Data Analytics
The 'Hide this page' button has been running as an MVP on the Check Legal Aid service since 14 April 2020. It has been used with a fair amount of frequency, however at present we are are yet to analyse the data in more detail.
The gaps in data recording were due to changes on the back-end of our service that caused GA to drop out.
Graph data since 14 April 2020
The below graph data also shows variations in spikes and lower use through the pandemic
Examples
| MoJ | DWP |
|---|---|
 |
 |
| SCOT.GOV | Cabinet Office |
|---|---|
| Image to follow |  |
How should the escape button work? @htmlandbacon documented how various examples are working online.
Women’s Aid “Exit site” https://www.womensaid.org.uk/
Position: desktop and mobile - upper right fixed position during scroll
Action: Goes to Google search in same window Back in browser goes back to previously viewed Women’s Aid page
Just a couple of things:
- I've not reviewed these so may be slightly wrong
- I've not done any sort of a11y review ( ahem @abbott567)
- I've not checked session behaviour
Assumption is that if a user clicked this while in our journey we'd probably scrub the whole session before we send them off @JennyG303
Accessibility would be an interesting one here, particularly if using a screen reader or voice command given that 'hide this page now' would be audible.
Below is an output of the end of a couple of conversations:
- Colour choice of button
- Placement on desktop (i.e below/above right hand content)
- Sticky behaviour of button on desktop and mobile and location
- Link to the BBC weather page vs some sort of session clearance
Desktop
Mobile
What will be interesting to investigate is:
- if this is not consistently used across gov.uk (i.e. it's not on every page), how do we teach people to know about it and use it? I've found in previous testing that if people aren't expecting to see something on the right hand side they just ignore it, even when they're looking for it. While the red does make it jump out, It could be that this button needs to get introduced as an interrupt pages before certain services if needed, just to make people know that it's there to be used (even in a "find the where the button is before you continue". This could also allow for people zooming into the screen to not miss it.
- Craig's question about screen readers is interesting, I assume there may also be work to again make sure that people know it's there, and that it's easy to 'jump' to the exit button if needed? Some of this will also come down to where in the page DOM it is.
This is really great Colin!
I think the placement of the mobile design is really interesting as we afix ours to the bottom of the screen, however there is the risk of it being accidentally pressed.
@vickytnz - that's interesting about educating users - I'd love to get some more research on whether having something like an interrupt would hinder or help users, especially if they are on a limited time (i.e the perpetrators out of the room and they need to gather info or perform an action quickly).
From some of the testing and research we found, users of this are more likely to have been on other sites that provide this feature such as non-agency, police or charity site and will therefore be relatively familar with being guided off the site. Certainly most of the other organisations that use this have it positioned on the right hand area of a large device/screen.
@vickytnz We are currently working to create some Gov.uk content in relation to staying safe online, but this is just limited to a specific DWP service at present. An interrupt page within the service is potentially one of our next steps.
People who are at risk from an abuser need support and signposting in the right time, place and language to learn how they can stay safe using government services if they need to keep their activity secret or have limited time to do so. Reassurance and awareness may give them confidence to use services in those situations. There is some collaboration and work in progress with other departments looking in to this. It's much bigger than one service.
We went with a top of screen button placement to avoid accidental clicks. We have a reasonably long application journey at present, and each page has a next / continue button at the bottom and in the hit areas were often overlapping if the exit button was placed at the bottom of the page.
I'm not sure if we can do some remote group design sessions to talk through and document some of these issues?
Yeah definitely - i'm putting a catchup call for this week (or next) so maybe we can chat what that might look like?
This is really great Colin!
I think the placement of the mobile design is really interesting as we afix ours to the bottom of the screen, however there is the risk of it being accidentally pressed.
Be interesting to see how many people auto assume it is some sort of cookie alert and ignore it.
Also having checked out a few code pen demos of position: sticky - it can create some quirks!
Also having checked out a few code pen demos of position: sticky - it can create some quirks!
Relevant blog post from @andysellick: https://technology.blog.gov.uk/2018/05/21/sticky-elements-functionality-and-accessibility-testing/
The Ministry of Justice have carried out some initial research with an SME to establish whether the proposed solution meets the user needs.
We updated the escape-link component in http://find-coronavirus-support.service.gov.uk/ to be aligned in behaviour with the MoJ approach (which I assume was originally based on the css-tricks article) as we don't have specific research on this.
My personal thought on this behaviour is that it works better when used on a single page that you want to mask; in a multi-page service it helps, but still leaves traces.
Happy to see this crystallised in a component that looks and behaves the same across government.
A preview of the draft component is available here: https://deploy-preview-1381--govuk-design-system-preview.netlify.app/components/hide-this-page/
I imagine a “Hide this page” component could be very useful for a digital health service.
I recently saw this website from the Royal National Institute of Blind People (RNIB) about a device to allow blind and partially sighted people to allow women to be the first to know their pregnancy test result: https://www.designforeveryone.org/
Imagine if someone doesn’t have a computer at home, but wants to check their symptoms for a health condition they find embarrassing, so they use a library computer and they suddenly see a close friend or family member and quickly want to finish checking their symptoms. This type of component could be very useful for people using public devices to access and use digital health services.
Representatives from the GOV.UK Design System working group reviewed this contribution in November 2020.
Based on a majority vote, the group decided that the contribution meets our contribution criteria.
They also made the following recommendations, which we have group into pre and post publication actions:
Pre-publication:
- [ ] Review the button text, to see if it can more accurately reflect the action it performs
- [ ] Make sure that if the control is styled as a button is behaves like a button in assistive technology
- [x] Us JavaScript to hide the page immediately, to avoid delays on slow connections
- [x] Confirm that core functionality is still available when JavaScript is not available
- [x] Confirm that that the sticky behaviour of the component doesn’t stop people zoomed in from using the page
Post-publication:
- [ ] Explore whether the escape key functionality should be present on devices without keyboards
- [ ] Include guidance on how to implement the component so it doesn’t interfere with other parts of the page
- [ ] Consider providing additional guidance, or another pattern, to cover the wider content of safe browsing
- [ ] Consider providing a Welsh translation of the component content
Hi everyone,
I was talking to Cam Nicholl at the Digital Accessibility Centre this morning, and she mentioned a couple of things about this pattern which I thought it would be good to sight people on.
Cam was looking at the component when her daughter walked in the room, so as a bit of a guerrilla test, she hit the button, but her daughter was actually drawn to the red of the button and got suspicious, leading her to ask questions about what Cam was doing.
So, I guess the question is whether red is the right colour for the button? It's very noticeable to the user, which is presumably why red was used, but also perhaps it is a bit too noticeable for prying eyes also.
The second comment was whether the guidance is clear enough about the kind of website you should redirect to. Google being almost universal, and BBC Weather being quite pictorial are definitely good examples, but if you choose a website such as BBC News, it could very quickly appear suspicious. Especially if the user does not have a good grasp of the English language. Reading BBC News in English when it is not your first language and it's something you struggle with, could definitely raise suspicions with an abusive partner. So it could be worth adding a caveat like this into the guidance so people don't unwittingly redirect people to the wrong kind of website.
Even if the consideration of these 2 things saves 1 person from abuse they're worth considering.
Thanks, C
Google search makes much more sense for those reasons you've stated, but could potentially invite a closer look from an abuser querying their search terms, leading to an internet history search.
Hi everyone,
I was talking to Cam Nicholl at the Digital Accessibility Centre this morning, and she mentioned a couple of things about this pattern which I thought it would be good to sight people on.
Cam was looking at the component when her daughter walked in the room, so as a bit of a guerrilla test, she hit the button, but her daughter was actually drawn to the red of the button and got suspicious, leading her to ask questions about what Cam was doing.
So, I guess the question is whether red is the right colour for the button? It's very noticeable to the user, which is presumably why red was used, but also perhaps it is a bit too noticeable for prying eyes also.
The second comment was whether the guidance is clear enough about the kind of website you should redirect to. Google being almost universal, and BBC Weather being quite pictorial are definitely good examples, but if you choose a website such as BBC News, it could very quickly appear suspicious. Especially if the user does not have a good grasp of the English language. Reading BBC News in English when it is not your first language and it's something you struggle with, could definitely raise suspicions with an abusive partner. So it could be worth adding a caveat like this into the guidance so people don't unwittingly redirect people to the wrong kind of website.
Even if the consideration of these 2 things saves 1 person from abuse they're worth considering.
Thanks, C
This is really interesting Craig! (@abbott567) One of the things that I raised with our SME was the button colour. We hadn't factored in whether a perpetrator would be drawn to the button if they entered a space where the victim was on a Gov site.
I think the first priority here is the victim/survivor and having something that is as distinguishable as possible would be weighted higher in terms of their own safety compared to something that might draw the attention of a perpetrator.
Without further testing on this with victims, I don't think we would have a middle ground as black would be lost against the GOV.UK palette and green is mainly used for starting, continuing, saving etc. That doesn't mean to say we shouldn't test other variations of the palette of course.
Definitely need clearer guidance on where to redirect people. There would need to be a good enough justification for sending someone to another site that isn't either Google Search or BBC Weather.
Interestingly in terms of usage of the button - we have seen more spikes in use on 20th October, when it was announced that pubs and bars were due to be shut at the Daily Briefing and on 31st December for NYE.
I'm a content designer working on the button in this service - https://www.gov.uk/find-coronavirus-support
We had an accessibility audit done on the service which raised that we need to make it clear what the button is for if you cannot see it in visual context, for example if you're using a screen reader. People need to understand it is an emergency tool which might not be clear if you cannot see it is a big red sticky button.
We also need to make it clear the user is being sent somewhere else and to a new tab.
We decided to change the button text and include hidden screen reader text: Hide this page [quick exit button, it opens BBC Weather in a new tab]
There was some other advice about button position which has been discussed a bit here already, but will update when we look in to this more.
Another example
A colleague shared this example of a leave this page button that might also be useful to this discussion.
It is taken from the Ministry of Justice, victim and witness information website.
Thanks for sharing this Charlotte! We've spoken to the developer on the team that implemented this but there wasn't any evidence to support the design and when we ran it past our SME it was agreed that it wasn't clear enough to the user that the button existed.
On Tue, 23 Mar 2021, 12:46 Charlotte Downs, @.***> wrote:
Another example
A colleague shared this example of a leave this page button that might also be useful to this discussion.
It is taken from the Ministry of Justice, victim and witness information website https://www.victimandwitnessinformation.org.uk/.
[image: Leave this page button example screenshot] https://user-images.githubusercontent.com/56260216/112148266-94762e00-8bd5-11eb-9246-18e298204a3a.png
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/alphagov/govuk-design-system-backlog/issues/213#issuecomment-804873676, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANVTPCCKRJJUFPCWGNLVKNDTFCER3ANCNFSM4MR5G4NQ .
As @abbott567 queried, how could a voice input only user discretely activate the button if say their abuser arrived home? As well as "Click Hide" could an innocuous secondary command such as "Click logo" that does the same thing.
How to advise them of that secondary command is the challenge. Perhaps a job for an instruction page as @vickytnz suggested, either in the flow or as a 'more info' link next to the button. Such a page could also:
- invite them to test the feature (advising that they'll have to find their way back to the site again)
- watch a gif/video of it in action
- clarify what happens to the data they've entered so far. ie if it would be submitted or should they re-enter it on another visit
Another example of this component is NCCADV in the USA (who borrowed our Do/Don't accessibility poster design to make one about trauma)
As noted, the GOV.UK stream is looking to improve the Hide this page component based on an accessibility report as noted by @hannahjump.
- Why we moved the button from the right to the left-side of the page
- When viewing the page with zoom enabled we found that the right aligned control was not visible; hence not accessible.
- By moving the button to the top left, users are then capable to access the button, regardless whether the operating system’s built-in zoom capabilities are enabled.
- We're not going to implement the escape key.
- Not all users are using a keyboard navigation system, mobile devices often don't have the escape key. So it could be confusing for users without it or need additional device detection to determine applicability.
- It doesn't exist in our current implementation and implementing opens up a variety of potential problems: it conflicts with existing UI patterns such as modals and may conflict with accessibility software
- Much like MOJ and MyGov.Scot’s approach, the component is to remain sticky at the top of the browser's viewport
- We've not placed the component at the top of the page for mobile
- It creates a confusing tab order.
- It breaks component isolation principles.
- We’ve also added the Details component, details about the component.
- As per the Design System, the Details component “Make a page easier to scan by letting users reveal more detailed information only if they need it.”
- If users are curious to learn about this button they can learn about it.
- As per the Design System, the Details component “Make a page easier to scan by letting users reveal more detailed information only if they need it.”
- The Hide this page button also includes hidden text in order for users of screen readers to comprehend the button’s functionality.
It’s important to note that this design iteration has not been tested with users.
Feedback from cross government Get feedback session of this iteration
- Have there been a design on desktop with the button being full-width
- Language for the details component
- Could it be explained more simply
- If there is no details the assumption is that the button will close the page
- Brings up the question regarding whether the term “Hide this page” is correct
- Be interesting to test, via heatmap, if users notice the button, particularly on desktop
- As per when the page is zoomed via the browser at 400%, the sticky button and details component take up the entire real estate of the page.
- Suggestion for future iteration is to remove the details component when scrolling the page
Hi all – just wanted to open up a key implementation decision we need to make, for discussion here.
I'm a bit worried about including the escape key functionality. Mostly because we can't be sure that it will work consistently across different contexts. For example:
- It could conflict with the behaviour of other UI components within the service that use the escape key to close them, such as modals or select boxes
- It looks likely to conflict with things outside the service, like accessibility software or browser extensions. For example, NVDA uses the escape key to ‘exit focus mode’. Both JAWS and NVDA stop reading when you hit Esc, so some users use it for that.
- There's no escape key on mobile / touch screen devices – can we reliably remove the functionality for devices without keyboards?
I can absolutely see the value of being able to hit a key to escape the page quickly, especially for keyboard-only users. On the other hand, someone trying to escape the page using the esc key and it not working could cause real harm. I'm finding it hard to reconcile that. It might be that the issues above aren't as big as I think they are – please let me know!
Hi Chris,
I think you have a point.
As you said, the logic behind the Esc key functionality was to try and enable a speedy exit for keyboard-only users. Just as the button stays visible on the page at all times so mouse users can click on it without having to scroll up, keyboard users can press escape without having to tab through the page.
When we implemented this on CLA, we noticed that the actual instances of the escape key triggering a quick exit was miniscule when compared with mouse click instances. (I tried to find the analytics results, but I only found some very early ones where it was 10:1. I recall it being more like 1000:1. I think the very early results aren't reliable given that the users would be tempted to try out the new big red button on the page.) Perhaps, though, that just reflects the ratio of keyboard-only users to mouse users.
Of your three concerns, I am not worried about the 3rd, as devices without keyboards wouldn't be able to press escape, so whilst it'd be redundant in the background, it shouldn't interfere with anything.
The second I think is concerning - especially as screen reader users would fall into the demographic of people who might use the escape key to quick exit.
I do recall discussions about the first point, but I can't remember why we thought it wasn't an issue at the time.
I suppose you could change the hide page to trigger if the escape key was pressed 3 times in quick succession - that would be better than requiring the user to tab through the page. Would that be suitable do you think?
Yours aye,
Malcolm Butler https://peoplefinder.service.gov.uk/people/malcolm-butler Rules & Front-end Developer | Legal Aid Agency https://www.gov.uk/government/organisations/legal-aid-agency | Ministry of Justice | 102 Petty France @.,-0.1367752,17z/data=!3m1!4b1!4m5!3m4!1s0x487604d95887a287:0x7be29eaac0c66517!8m2!3d51.4999822!4d-0.1345865> | SW1H 9AJ @.,-0.1367752,17z/data=!3m1!4b1!4m5!3m4!1s0x487604d95887a287:0x7be29eaac0c66517!8m2!3d51.4999822!4d-0.1345865> | 07500 578927 | x-Gov Slack https://app.slack.com/client/T04V6EBTR/D95DNDVFF/user_profile/U94LDRD88
On Fri, 18 Jun 2021 at 14:17, Chris Thomas @.***> wrote:
Hi all – just wanted to open up a key implementation decision we need to make, for discussion here.
I'm a bit worried about including the escape key functionality. Mostly because we can't be sure that it will work consistently across different contexts. For example:
- It could conflict with the behaviour of other UI components within the service that use the escape key to close them, such as modals or select boxes
- It looks likely to conflict with things outside the service, like accessibility software or browser extensions. For example, NVDA uses the escape key to ‘exit focus mode’. Both JAWS and NVDA stop reading when you hit Esc, so some users use it for that.
- There's no escape key on mobile / touch screen devices – can we reliably remove the functionality for devices without keyboards?
I can absolutely see the value of being able to hit a key to escape the page quickly, especially for keyboard-only users. On the other hand, someone trying to escape the page using the esc key and it not working could cause real harm. I'm finding it hard to reconcile that. It might be that the issues above aren't as big as I think they are – please let me know!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alphagov/govuk-design-system-backlog/issues/213#issuecomment-864032416, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH22WA5U4CS4KUP74X5XYTLTTNBPHANCNFSM4MR5G4NQ .
Thanks for picking this up @christopherthomasdesign!
Out of about 3,000 uses of the button since it was added to the Legal Aid service, the 'esc' key has only been used 150 times (5%) and I'd argue that most of these interactions would have been through people experimenting with it as we were unable to isolate the IPs of the working group (apart from LAA members).
I'd agree with @MalcolmVonMoJ that the second point is pretty obstructive, and given the conflict with assistive tech, it should be removed. However, we would want to ensure that there is an option to bind it to something in the future that wouldn't conflict with users using screen readers and have it announced in the section before the skip to main content link.
Addressing this would then mean that it then solves the first point as you wouldn't have a clash with modals etc.
This would need to be put in front of an SME or real user though as most of the stuff we work on doesn't always have the same degree of knock-on effects as this component will have for victims and survivors of DA.
Thanks both of you - those usage statistics are very helpful!
I think the main issue with the 3rd point is that if we advertise the functionality on a device that doesn't have it, it could cause users to waste time hunting for it.
How about we disable the feature by default, and don't include content that refers to it, but allow for keybinding in case we subsequently discover a 'safe' way to do it? @36degrees - what do you think about the feasibility of this approach?
How about we disable the feature by default, and don't include content that refers to it, but allow for keybinding in case we subsequently discover a 'safe' way to do it? @36degrees - what do you think about the feasibility of this approach?
As a general rule, ideally we'd avoid adding undocumented features to things, so I'd prefer to leave it out entirely. We can always add it in as part of a future iteration.
I also think we need to be careful with this specific component. If it looks consistent then it also needs to work consistently across GOV.UK. Allowing individual features to be enabled or disabled on different services could put users at harm.
For example:
- a user interacts with this component on one service, where they've learned that they can use the escape key
- they then encounter a visually identical version on another service that doesn't work with the escape key
- they try to exit the service using the escape key, but nothing happens
Yeah, those are really good points. So perhaps what we want is to just build in a way that doesn't block us from implementing the feature in the future
Consistency > Customisable features dependent on service. Olis point about the risk of putting users at risk of harm is bang on!