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

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

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.

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.

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 share a link to this page?