Comparison of Escape Options

1. Use a Button

var button = document.getElementById('escapebutton')
button.addEventListener("click", replacebutton)
  function replacebutton () {
    window.location.replace('https://apple.com')
  }

What are the problems specific to the BUTTON approach?

A button shouldn't act as a link. This goes against the intended use of a button element. The HTML spec as well as accessibility advocates would argue that actual "buttons" should perform an action, like submitting data or opening a modal or dialogue.
Buttons have specific meaning to users of assistive technology and different methods of use (enter, spacebar). When a screenreader announces to a user that they are on a button they may expect different behaviors than we are providing here.
This relies on javascript to do anything at all. Without js enabled this button does nothing.

2. Use an Anchor (link)

This is a quick escape ANCHOR element

 var link = document.getElementById('escapeanchor')
link.addEventListener("click", replacelink)
  function replacelink (e) {
    e.preventDefault();
    window.location.replace('https://apple.com')
  }

What are the problems specific to the ANCHOR approach?

We're breaking the native function of a link. In order to use the window.location.replace method, we have to intercept the native function of the link. This is already a concern and anti-pattern. We're stopping the browser from interpreting the native semantics of a link by using stopPropagation and then re-assigning it a location. Technically, this might not be a concern as long as the two locations are the same, but we're literally re-inventing the wheel here.
As long as we still provide an href then this isn't technically invalid html and wouldn't require javascript to still "work" as a link. Although the history modification wouldn't be functional.

A problem with BOTH options

You can't reliably modify browser history beyond a single level.

Both of these options use the window.location.replace method which does replace the current browser location with the url that you've specified. Meaning that if you hit the back button it will have nowhere to go back to.

So what's the problem?

This is only useful if you've gone to a single page on a website and no others. If a user has searched google for OPDV, navigated to the homepage, and clicked on a page of content on the OPDV website, then clicks the escape link, this method can only remove the final action from that list. A bad actor hits the back button and the browser will go back to the OPDV homepage in this user journey.

We can't reliably know how many pages a user has clicked on within the website and be able to remove, rename, or re-assign those pages to other locations, except for the current page. Browsers have some powerful history modification API tools available - think history.pushState() or history.replaceState() - however they aren't really useful without knowing where, when, and how much of the history to modify based on user action. We can't easily know that.

OGS Digital Services Recommendation

Given the accessibility and functionality drawbacks of both approaches, it might be just as effective to keep the current solution in place. Of the two options above, we'd recommend using the ANCHOR link method despite the iffy technical implications of doing so as it has a native fallback without javascript. Removing a single layer of history could benefit some users, so the drawbacks may be worthwhile.