Skip to main content
beeps Blog

Why GOV.UK’s Exit this Page component doesn’t use the Escape key

A very specific question, answered very longwindedly.

Content warning: This blog post references domestic abuse and violence but doesn’t go into specific detail.

I’m not an expert in that topic at all, so I may not use the preferred terminology in all instances. Sorry.

Last year (oh how time flies), we launched the GOV.UK Design System’s Exit this Page component, or EtP for short.

A large red button with 'Exit this page' written on it in plain white text.

On the surface, it’s a simple component. It’s a big red button that sticks to the top of the screen. If you click it, you’re taken away to BBC Weather.

But it does so much more.

If you press the ⇧ Shift key on your keyboard three times, you get a visual indicator that you are activating the button. Upon the third press, the page you’re on is blanked out and you’re redirected away to… well, BBC Weather again.

It’s intended to be a safety tool. A way for people in unstable, potentially violent, domestic situations to quickly leave the page.

But one question that comes up a lot is…

Why don’t you use Escape?

It’s a decent question. Many other implementations of buttons like this exist, and of the ones that provide a keyboard shortcut, they almost universally use the Escape key: Esc.

And it’s literally called Escape. Why wouldn’t you use it for an escape function?

Basically, it doesn’t quite work like that. There was a veritable rabbit hole of barriers that ultimately led us towards using a different key.

An amphimorpho looking to the side in puzzlement, with a paw on its chin in thought.

Do rabbit holes normally have barriers, actually?

1. Escape stops the browser from loading pages

In virtually all browsers, pressing Escape while a webpage is loading stops the loading process.

This is literally the last thing we want to happen for a feature whose sole job is to load a different page from the one you’re on.

If we had used Escape, it would be too easy for a user to accidentally cancel the redirection process and end up stuck on the current page, and that’d be a bit naff.

2. Escape performs other functions in the operating system

In addition to cancelling loading, we found that the Escape key was used by too many other functions to reliably work for exiting the page.

For example, Escape is also used to exit fullscreen media (and on macOS, fullscreen apps), close modal dialogs and popovers (including those generated by native input controls), cancel a dragging interaction, clear a text input, and dismiss notifications.

Assistive technologies may also use the Escape key for functionality, and it is also used as part of keyboard shortcuts.

All of these take priority over the page’s JavaScript, which often meant needing to press the Escape key more than the requisite three times, creating confusion as to whether the function actually worked as advertised.

In the case of macOS and fullscreen apps, it even involved having to wait for the re-windowing animation to finish before the page could begin to intercept Escape key presses again. Very not ideal.

3. Pressing Escape isn’t considered a user interaction

Do you remember popup ads? When you’d open up a website and immediately a new window would open purely to shove advertising in your face?

How about autoplaying audio and videos? Or when pages begged you to stay when you tried to close them? Or those immediate “do you want notifications from us?” dialogs?

These are all the result of people exploiting JavaScript’s mostly-unrestricted ability to do stuff, usually to try and make money.

As a result of advertising people being bastards, more and more of what the web platform can do is now being locked behind the requirement of transient activation—that is, the browser will refuse to run pieces of JavaScript unless it is certain that some manner of user interaction took place with the intention of running it.

Browsers use a few different heuristics to determine user interaction, including touches, mouse movements, and key presses. If it detects one of these that seems human enough, it will allow transiently activated code to run for a short period afterwards.

An amphimorpho looking alarmed and grimacing.

This can have some unfortunate ramifications on accessibility.

As we’ve recently learned on the GOV.UK Design System team, webpage interactions made by some assistive software (in this case, Dragon NaturallySpeaking) are not considered user interactions for the purposes of transient activation, so some JavaScript code will either not work or will work inconsistently for users of that software.

Redirecting the user away to another page via JavaScript is one such function that requires user interaction before it will run.

And Esc is the only keyboard key that doesn’t count as user interaction for the purposes of transient activation.

This meant that if a user tried to use the EtP shortcut immediately after a page loaded, or after a short period having not interacted with the page (for example, if they were busy reading it), the redirection just wouldn’t work. Totally doubleplus ungood.

Alternative keys

With adequate evidence that Escape wouldn’t work for us, we started looking at other non-typing keys we could use.

Testing with the Control key (⌃ Ctrl) worked much better, avoiding virtually all of the pitfalls of Escape, but there were still a few cons to it.

Control conflicted with VoiceOver’s default configuration—where pressing Control mutes VoiceOver.

Control was also the only key of those we were considering that wasn’t in a physically consistent location on different UK keyboards: While on standalone keyboards the key tends to appear in the far bottom-left, on laptops it is commonly offset inwards to make room for an additional function key.

This innocuous difference had the potential to slow down a user’s ability to quickly activate the shortcut, especially if they were using unfamiliar hardware.

The Alt or Option keys (⎇ Alt or ⌥ Option), by comparison, were more problematic.

Most obviously: It’s named differently on different systems. Guidance and help documentation would get rather more verbose if we had to constantly call it Alt, Option, Opt, the key with on it, and so on in every instance.

The key’s use for typing letters with diacritics and other ‘alt codes’ meant that the keypresses reported to the browser weren’t always aligned with what physical keys the user had actually pressed, meaning we couldn’t be reliably sure if the user was intending to exit the page or not.

Alt/Option, like Escape, also had the issue of being utilised by some browser- and system-level functions, such as a shortcut to access application menus.

In Chromium browsers on Windows, for example, pressing Alt would move keyboard focus out of the webpage and to the browser UI—completely removing the user from the webpage context. This prevented subsequent key presses from being detected, and obviously made EtP functionality not work at all.

Shift was better, but it’s still not perfect

So we landed on ⇧ Shift. Shift works more consistently than Escape did, but still has a bunch of caveats:

  • Its use during normal typing meant needing to be careful about which presses actually counted towards activation.
  • Pressing Shift three times requires many more presses if the Sticky Keys accessibility features is active. I found that it took between 6 and 9 presses with Windows Sticky Keys, depending on speed, and 9 presses with macOS Sticky Keys.
  • macOS’s Slow Keys feature still takes three presses, but they have to be spread across a period of a few seconds to avoid activating the ‘latching’ functionality.
  • The JAWS screen reader in Chromium would register the first Shift keypress twice, though this has potentially been fixed since.
  • Using Shift means that the shortcut is available on touch device’s virtual keyboards. However, these keyboards tend to behave unpredictably compared to their hardware equivalents. I wrote up a massive bug report just about how the Shift key behaves on iOS, part of which subsequently became a bug report.

Despite these shortfalls, Shift was ultimately the least flawed of the choices presented to us, with most of its issues being fairly minor and none of them being showstopping.

Conclusion

So that’s where we are now.

In some ways, this is an unfortunate case of technology and web standards working against what would be the ideal user experience. Esc would be the ideal key to use, but it has too many caveats to work consistently.

We looked into opening the redirection page in a new tab and automatically closing the previous tab, as some similar tools do, but user research found that this often caused confusion (‘Why doesn’t the back button work?’, ‘Where did my work go?’) and doing that is also subject to transient activation requirements.

We would’ve also liked to have had the button overwrite or erase the user’s recent browser history, but we can’t do that either. (And for good reason!)

Ultimately, we had to land on the philosophy of doing better, but not aiming for perfection. We could never write a piece of JavaScript that could prevent domestic violence, prying surveillance, or controlling relationships—we can only do what we can do.

No one has complained about us using Shift instead of Escape, nor have we received any bug reports about it not working, but it certainly raises an eyebrow when folks hear about it for the first time…

As for the other major question we get…

Bonus: Why does it redirect the user to BBC Weather?

As civil servants, we didn’t want to link to a news service as that could lead to claims of political bias.

I also argued (a lot) against linking to the Google homepage—despite this being ridiculously common—because… who actually uses the Google homepage? Google search is right there in your URL bar.

Even if you do go to Google’s homepage, the first action you normally take once there is to leave Google’s homepage.

If you walked in on someone and they were nervously staring at Google’s homepage, you’d be suspicious as hell.

BBC Weather’s homepage is a content-rich page. Users have a reason to be looking at it and to be looking for an extended period of time. It may even default to the user’s location, displaying significantly more personalised content in the process, which is surely less suspicious than a blank, generic search form.

Thought this was neat? Why not ?


193 favourites

159 shares


Comments

Thoughts? Questions? You can favourite, share or comment on this post by replying to it on Mastodon.

  1. electrocutie@plush.city

    @batbeeps hmm, I went to the test page and found that it didn't work with the 3 shift presses on firefox unless they had a lot of space time between them

    I didn't see this mentioned as a known bug or intentional so I wanted to ping you

    I type fast so something like a tap ... tap ... tap would be really weird and I suspect that is similar for a lot of digital natives

  2. batbeeps@chitter.xyz

    @electrocutie on desktop Firefox? We would’ve tested that when building it so it’d be annoying if it didn’t work now.

    Touchscreen/virtual keyboards can be a lot less consistent due to operating systems assigning multiple functions to them (e.g. quickly pressing Shift twice on iOS activates Caps Lock instead)

  3. electrocutie@plush.city

    @batbeeps desktop firefox
    To be sure it wasn't a plugin I did test in a private browsing window and I got the same behavior

    I also checked real quick to see if it was delivering the events and on another page where I have control of the JS I tested and at least there it does fire all the events no matter how fast I tap shift

    Another friend is on desktop firefox ESR 115.15 and the 3 shifts also didn't work for them

  4. batbeeps@chitter.xyz

    @electrocutie Well, that's concerning! Gonna have to look into that...

  5. electrocutie@plush.city

    @batbeeps if there is any other information that might help don't hesitate to ask

  6. batbeeps@chitter.xyz

    @electrocutie Hmm, unable to reproduce the issue on Windows 11 (Firefox 126, 127 & 131) or macOS 15.1 (Firefox 130) in my quick tests just now.

    I wonder if being on Ubuntu has something to do with it? We have automated tests that run in Chromium on Ubuntu, which have always passed, so it might be very specific to Firefox/Ubuntu if so.

  7. electrocutie@plush.city

    @batbeeps friendo is on debian, though since they share DNA that could just be common to them

    but all 3 events are delivered in my test, hmm

    I will look at this in my own time and see if I can find something. This is open source, yeah? Web so I figure it is but so many things distribute compressed blobs that it bears asking

  8. batbeeps@chitter.xyz

    @electrocutie Yep! Feel free to open an issue about this on https://github.com/alphagov/govuk-frontend with whatever environment and reproduction details you can provide.

  9. electrocutie@plush.city

    @batbeeps wilco! once I've got some bandwidth that is. Thanks for helping make it, that's really cool

  10. rexfuzzle@hub13.xyz

    @batbeeps what is the mobile experience like for this, ie how to to exit the page on mobile? I assume shift doesn't work?

  11. batbeeps@chitter.xyz

    @rexfuzzle The button is located at the top of the main content area and sticks to the top of the viewport as the user scrolls down.

    We experimented with having it at the bottom, as it would be easier to reach and harder to see, but found that the browser UI/virtual keyboard would cover it up in some situations while there.

    We didn't want to stick it to the side of the viewport due to it more readily obscuring content whilst placed there.

  12. rexfuzzle@hub13.xyz

    @batbeeps ah, yeah, having things stick to the bottom is "fun". This is such a great feature! Well done!

  13. batbeeps@chitter.xyz

    @rexfuzzle Thanks! Though with many things, it was very much a team effort!

  14. karen@treehouse.systems

    @batbeeps as someone who has been terminally online since middle school: i truly did not know hitting escape while a page was loading would cancel it. You learn something new every day.

  15. richlv@mastodon.social

    @batbeeps @electrocutie
    For the record, works well on a desktop FF/Mac, double shift does not activate capslock.

  16. JonasDoesThings@chaos.social

    @batbeeps I have never seen this feature on a page, so really interesting to learn how thoughtful it was designed & implemented, thx for sharing!

    But can we please also mention how freaking cute the animated furry thingy at the bottom of the blogpost is?? 😭😭😭🥺

  17. lunahd@labyrinth.zone

    @batbeeps my favourite thing to redirect to is google search for cats on the images tab

  18. MontgomeryGator@fouroclockfarms.club

    @batbeeps while the weather is politically neutral, doesn't it kinda seem like a... Like if you saw the previous page was full of text and then suddenly saw BBC weather it's obvious the person changed the content to obscure what they were reading. Moreover, nobody would be intensely reading the weather page right?

    Intentionally hijacking the back button so you can't simply press back would be a good idea.

    But like, Wikipedia articles and old.reddit threads. They are both text-dense and aren't as suspicious loading in a new page. While it might be difficult to keep the same level of neutrality, it's easier to rotate out pages and threads over time as well so abusers don't catch on that help websites always exit to BBC Weather.

    There's also the possibility that someone outside the UK may find the page, and look for applicable advice anyway. BBC Weather would be suspicious...

  19. gjm@mathstodon.xyz

    @batbeeps @electrocutie For what it's worth, it seems to work OK for me on Firefox 131.0.2 / Ubuntu 22.0.4.1 / x64.

  20. batbeeps@chitter.xyz

    @MontgomeryGator The hope is that the shortcut is used before an abuser even gets to see the GOV.UK page. We blank the page immediately upon activation so that, even under slow network conditions, the GOV.UK page isn't visible until the BBC Weather one is loaded—in which case the potential discrepancy in appearance isn't an issue.

    Retaining normal history and back button functionality was a direct result of user research. Users would proactively exit the page if they felt they might be intruded upon, but would then want to resume what they were doing once they felt that danger had passed (e.g. if someone was approaching the room they're in but ends up walking past instead).

  21. winload_exe@wetdry.world

    @batbeeps @electrocutie reproduced on Firefox 131.0.2 on Windows NT build 10.0.26100.1912 (ge_release_svc_betaflt_prod1.240918-1925), amd64fre. iframe in example page isn't focused by default, you have to click on it in order to actually get the sample code to function

    Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:131.0) Gecko/20100101 Firefox/131.0

  22. electrocutie@plush.city

    @winload_exe @batbeeps that is not the same as my error, it is not that it is not functional at all its that the shift detection is unreliable

  23. batbeeps@chitter.xyz

    @winload_exe @electrocutie the iframe is just for the documentation pages also. In production use it won’t be inside of a frame.

  24. winload_exe@wetdry.world

    @electrocutie @batbeeps sorry, I got confused by the similar behavior

  25. dpom@fosstodon.org

    @batbeeps @zachleat I just assumed it was because most visitors enable gov.uk's vim bindings.

  26. zachleat@zachleat.com

    @dpom @batbeeps I regret to inform you that I enjoyed this joke very much