The Short Answer

A quick exit button protects against one thing: someone seeing the screen. It swaps the page for an unremarkable one in a single action. It does not erase browsing history, it does not remove a search engine's record of what was searched and it cannot stop someone who is monitoring the device. It also has to work without a mouse, or it protects only some of the people it is for.

The button is the easy part. The honest page beside it, and the phone numbers above it, are where the work is.

The NGO website section checklist lists both as best practice for services whose users may be at risk. Neither is a legal duty. Both can fail the person they are for.

What the Button Does

The most thorough public reference is the GOV.UK Design System's Exit this page component. It is meant for pages whose content could "put someone at risk of abuse or retaliation" or "reveal someone's plans to avoid or escape from harm", such as a service helping someone leave a domestic abuser. It has four parts:

  • A button that sends the tab to another website, BBC Weather by default. The guidance says to avoid sites that show personalised content, such as recently visited or suggested links, because that content could itself put the user at risk.
  • A secondary link, hidden until it receives focus and placed under the skip link at the very top of the page, so people using assistive technology can reach the exit first.
  • A loading overlay that blanks the screen at once, so a slow connection does not leave the page visible while the next site loads.
  • A keyboard shortcut: three presses of Shift within five seconds.

The component's source code uses an ordinary navigation, so the page the person left is still one press of Back away. Some sites use location.replace() instead, which means the current page "will not be saved in session History" and Back skips it. That removes one page from one tab. Every earlier page of the visit is still behind it.

Women's Aid shows a second approach. On 30 September 2026 its homepage carried an "Exit Site" tab fixed to the right-hand edge of the screen and a "Cover your tracks" link in the header navigation. Its button opens Wikipedia in a new tab and replaces the current page with a Google image search. The methods differ. The limit is the same.

What It Does Not Protect

GOV.UK's Exit a page quickly pattern is plain about it: the pattern "is not a complete solution to eliminating all possible risk to the user", and perpetrators can monitor people "through other methods, such as malicious software". It tells services to explain, before the person first meets the button, that their browsing history will not be erased.

Women's Aid's Cover your tracks online page says the same in its own voice: the button will hide the page, but the history still needs deleting. It adds that a search engine may keep its own record of searches after the browser's history is cleared. And it warns that some protective steps can be noticed, such as a changed password, and could lead an abuser to escalate.

So the list of what a quick exit leaves behind is short and serious:

  • The browsing history, and any earlier pages in the tab.
  • The search engine's record of what was searched to find the site.
  • Monitoring software on the device, which sees everything regardless.
  • Anything typed into a form, unless the site clears it. GOV.UK tells services to decide what happens to session data and suggests routing the exit through a page that clears it before redirecting.

That is why the button needs a companion page. GOV.UK's pattern asks services for two: an interruption page explaining the button, and a safety content page on staying safe online. For a charity website the second is the one that matters, linked from the header beside the button.

That page is specialist safety advice, not web copy. Women's Aid's warning about noticed steps shows why: advice that is technically correct can be unsafe in a particular relationship. The owner should be whoever owns safeguarding content, not whoever maintains the CMS.

GOV.UK is also candid about the button's costs. Seeing it "might discourage certain users": someone who does not see themselves as at risk may decide the service is not for them. And the team has tested it mainly with people at risk of domestic abuse, and says it is particularly interested in how well it works on static information pages. Its guidance allows the button on every page of a service or only on the sensitive parts. For a domestic abuse charity that is likely the whole site; for a general charity it may be one service section. Where it goes is your safeguarding lead's decision, not the web team's. They know which pages a person at risk is likely to be reading.

The Accessibility Problem Inside It

A safety control that a keyboard user cannot reach quickly, or a screen reader user cannot identify, protects only mouse users. WCAG 2.2, at level AA, is the benchmark, and six of its success criteria bear directly on this one button.

It must be a real control. Criterion 4.1.2 (Name, Role, Value) requires the name and role of every interface component to be available to assistive technology. A native button or link does that; a styled box with a click handler does not. GOV.UK's default link text is "Emergency Exit this page", with "Emergency" visually hidden, so a screen reader user hears why the control is there.

The keyboard route cannot depend on timing. Criterion 2.1.1 (Keyboard) requires everything to be operable by keyboard "without requiring specific timings for individual keystrokes". Three Shift presses in five seconds is a timed sequence, so it can only ever be a shortcut on top of the button and the secondary link, which are the real keyboard route. GOV.UK says it considered a single key such as Esc and rejected it, because it could not be confident the key would not interfere with other actions. A single-letter shortcut has a further problem: criterion 2.1.4 (Character Key Shortcuts) requires a way to turn it off or remap it, or for it to work only when its control has focus, because a letter fires whenever someone types one.

Position in the tab order is a safety question. When I tabbed through Women's Aid's homepage at desktop width, the Exit Site button came 25 presses after the skip link, behind the header's links. That is not a WCAG failure. It is a long way for someone in a hurry, and it is the gap GOV.UK's secondary link closes by sitting directly under the skip link.

Changes must be announced. Criterion 4.1.3 (Status Messages) requires status messages to reach assistive technology without moving focus. GOV.UK's component announces each Shift press ("Shift, press 2 more times to exit") and "Loading." when it fires. It also hides the page behind the overlay, so a screen reader cannot wander through the content while the next site loads.

A floating button must not hide anything. A button that stays on screen as the page scrolls is useful, and it is also in the way. Criterion 2.4.11 (Focus Not Obscured, Minimum), new in WCAG 2.2, requires that a focused component is not entirely hidden by the site's own content. Test the fixed button against every link and field it can sit over, on a phone as well as a desktop. Criterion 2.5.8 (Target Size, Minimum) sets 24 by 24 CSS pixels as the floor for pointer targets, and that covers the urgent-help call buttons too. A control used in panic should clear that floor comfortably.

The wider picture is in website accessibility for nonprofits.

Urgent Help Numbers Need an Owner

The checklist pairs the quick exit with an urgent-help block: an "if you are in danger" line, the emergency number for each country you work in and the helplines people actually need. No law requires it. A service that deals with risk and hides the emergency route behind its menu has still made a choice.

A wrong emergency number is worse than none. Picture a hypothetical international NGO whose urgent-help page lists a number for each programme country, copied from a secondary list when the page was built. Nobody has checked it since, because nobody was asked to. The page looks complete, and it fails at the only moment it matters.

Treat each number the way you would treat a legal figure:

  • An owner. A named role, usually the service or country lead, not the web team.
  • A source. The official source in that country, or the helpline's own published page, recorded beside the number in the CMS. Never a third-party list.
  • A review date. On the regular review cycle, and at once when a helpline changes its hours or a service closes. Opening hours belong in the same record, because a correct number that is closed at night needs to say so.
  • The number written out. As well as the tap-to-call button, so it can be read aloud or dialled from another phone.

The content governance post covers how to set owners and review dates across a site; these numbers belong at the top of that list.

The Page Around the Button

A quick exit is a good pattern with a narrow job. It clears the screen in a second, and it does nothing about the history, the search engine or the software someone has installed. The website's part is to make the button reachable by everyone, to say plainly what it cannot do and to keep every number above it true.

The button buys seconds. The page decides what they are worth.

Further Reading

What This Post Does Not Cover

This is about the website: what the button does, what the page must say and who keeps the numbers current. It is not safety advice for people at risk, which belongs with specialist services, and it is not legal advice. I have not tested either implementation with a screen reader or on a phone; the observations about Women's Aid are from its homepage and source code as loaded on 30 September 2026.