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

On the surface, its a simple component. Its a big red button that sticks to the top of the screen. If you click it, youre 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 youre on is blanked out and youre redirected away to& well, BBC Weather again.

Its 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&

Its 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 its literally called Escape. Why wouldnt you use it for an escape function?

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

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 youre 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 thatd be a bit naff.

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 pages 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.

Do you remember popup ads? When youd 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 JavaScripts 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 activationthat 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.

This can have some unfortunate ramifications on accessibility.

As weve 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 doesnt 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 wouldnt work. Totally doubleplus ungood.

With adequate evidence that Escape wouldnt 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 VoiceOvers default configurationwhere pressing Control mutes VoiceOver.

Control was also the only key of those we were considering that wasnt 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 users 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: Its 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 keys use for typing letters with diacritics and other alt codes meant that the keypresses reported to the browser werent always aligned with what physical keys the user had actually pressed, meaning we couldnt 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 UIcompletely removing the user from the webpage context. This prevented subsequent key presses from being detected, and obviously made EtP functionality not work at all.

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.
• macOSs 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 devices 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.

So thats 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 doesnt the back button work?, Where did my work go?) and doing that is also subject to transient activation requirements.

We wouldve also liked to have had the button overwrite or erase the users recent browser history, but we cant 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 relationshipswe 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&

As civil servants, we didnt 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 homepagedespite this being ridiculously commonbecause& who actually uses the Google homepage? Google search is right there in your URL bar.

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

If you walked in on someone and they were nervously staring at Googles homepage, youd be suspicious as hell.

BBC Weathers 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 users 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?