Links that open a new tab without warning

What an unannounced new tab does to a customer

A shopper is three fields into your checkout. They want to confirm the returns window before committing, so they click the returns link in the footer of the form. It opens a new tab. They read, they are satisfied, and they press Back to return to their half-finished order — and Back does nothing, because this tab has no history. The checkout still exists, one tab to the left, but nothing on screen says so. Some of them find it. Some of them re-open the site, discover the basket intact, and grind through. Some are simply gone.

Now run the same moment through assistive technology. A screen-reader user activates a link and their browsing context is replaced without ceremony; unless they catch the announcement of a new window — easily missed mid-task — the model in their head no longer matches the machine. The back command they rely on as an escape hatch returns nothing. A screen-magnifier user working at four-times magnification sees one corner of the viewport; the tab strip, and the fact that it has grown, is off-screen entirely. Someone with a memory or attention impairment loses the thread that the previous page still exists behind this one. The common injury is the same for all of them: the site changed the rules of navigation and told nobody.

Here is the part we will state plainly, because trust is built on it: no WCAG 2.1 or 2.2 success criterion at Level A or AA prohibits target="_blank" or requires a warning. The W3C technique that describes warning users, G201, is advisory — recommended, not mandated. The criterion that points the same direction, 3.2.5 Change on Request, sits at Level AAA, the tier almost no commercial site claims. So this finding will never appear in your report dressed up as a conformance failure. It appears because the cost to real customers is well documented, the repair is nearly free, and W3C wrote the technique down for a reason.

The fix is one of two honest sentences. Either tell people — “Opens in a new tab”, spoken by the screen reader as part of the link — or stop doing it, and let the link open where links open. Both are correct. Which one is right for each link is a judgement about your store, which is exactly why this family never fixes itself.

How it is detected here

No engine in the scan carries a rule for this, and that is correct behaviour on their part — axe-core, IBM Equal Access and HTML_CodeSniffer test conformance criteria, and as established above, no A or AA criterion covers it. A scanner that reported target="_blank" as a WCAG failure would be inventing the standard it claims to check.

So the detection is Klarvo’s own, and it is deterministic rather than clever: a pass over the exact bytes your server sends collects every anchor whose target attribute is _blank — trimmed, case-insensitive, so _BLANK and padded variants do not slip through. Two refinements keep the count honest:

• A link already carrying the Klarvo annotation is recognised by its marker and skipped, so a fixed link is never re-reported as a fresh finding on the next scan.
• Each finding is attributed to the exact page whose served HTML contained it, with a count per page — not a vague site-wide tally.

Because the pass reads served source rather than a rendered approximation, what it reports is what every visitor’s browser is actually given. There is no probability in it: either the attribute is in the HTML or it is not.

What Klarvo does about it

This family is review tier, merchant choice — never applied silently. For every flagged link, the engine prepares both legitimate fixes in advance and sends the pair to your review queue:

Option one: announce it. A visually hidden span is appended inside the anchor, server-side, in the HTML your store serves:

<a href="/track/AB123456789GB" target="_blank" rel="noopener">
  Track your parcel
  <span class="klarvo-access-visually-hidden" data-klarvo-profile="new_tab_warning">Opens in a new tab</span>
</a>

The text is exactly “Opens in a new tab” — a fixed, audited phrase, not generated prose — and it becomes part of the link’s accessible name, so a screen reader announces “Track your parcel, Opens in a new tab, link”. The hiding class uses the standard clip pattern, injected once alongside the annotation, so nothing changes visually. The data-klarvo-profile marker is what lets the detector recognise its own work later, and the operation is idempotent — a link already annotated never receives a second span.

Option two: same tab. The target attribute is removed, and the link behaves like a link: same tab, working history, working Back. Nothing is added to announce, because there is nothing left to warn about. For most internal links this is the cleaner ending, and it is the direction W3C’s G200 leans — new windows only when necessary.

You choose per link, from the queue, with the before and after in front of you. Once you decide, the chosen fix is applied server-side — never painted on by a script in the visitor’s browser — and then checked rather than assumed: the page is fetched fresh, and the served HTML must show the annotation present inside that exact anchor, or the target attribute gone from it, before the fix is recorded as applied. An automated finding is evidence, not a certificate, and the same discipline applies to the fix.

How to fix it yourself

Decide the policy before touching markup. The durable rule most stores land on: internal links never open a new tab; external links may, when there is a task-based reason — a courier’s tracking portal, a help article read mid-checkout, a PDF the visitor will want alongside the product. “I want them to stay on my site” is not a task-based reason; it overrides the visitor’s own control, and every browser already lets people choose a new tab when they want one.

Find the toggles that created them. In the block editor, every link carries an “Open in new tab” switch, and it is worth an editorial note to your team about when it is justified. Menu items have the same switch hidden by default: on Appearance → Menus, open Screen Options at the top of the page and tick “Link Target”, and each menu item gains an “Open link in a new tab” checkbox you can audit and untick. Page builders keep their own per-link toggles; the pattern is the same.

Sweep the content you forgot about. Years of posts accumulate hand-set targets. Search your content for the attribute — wp db search 'target="_blank"' from WP-CLI will list the posts — and correct them in the editor rather than with a blind database replace, which has no way to distinguish the justified cases you are keeping.

Where you keep the new tab, say so. The W3C’s H83 pattern is to indicate it in the link text itself. Visible text is the strongest form, because it warns sighted visitors too:

<a href="/downloads/size-guide.pdf" target="_blank" rel="noopener">
  Size guide (PDF, opens in a new tab)
</a>

Where the design cannot carry the longer text, a hidden span does the assistive-technology half:

<a href="/track/AB123456789GB" target="_blank" rel="noopener">
  Track your parcel<span class="screen-reader-text"> — opens in a new tab</span>
</a>

Most themes ship the screen-reader-text class; if yours does not, any correct clip-pattern implementation serves. Two cautions. If you use an icon as the visible cue, it needs its own text alternative — an unlabelled decoration warns nobody using a screen reader. And if you reach for aria-label instead of a span, the label must contain the visible words — “Track your parcel, opens in a new tab”, never a replacement phrase — or voice-control users end up saying a name that no longer matches the control.

Keep rel="noopener" on anything that still opens a new tab. WordPress’s editors add it automatically when the toggle is used; hand-written markup should include it too. It severs the new page’s scripting handle on your page — a security courtesy that costs nothing.

WooCommerce spots worth a specific look: the terms-and-conditions link at checkout, tracking links added by shipment plugins, social icons in the footer (routinely _blank and routinely unlabelled), and PDF size guides or care instructions on product pages — a PDF link is a double context change, new tab and new format, and deserves the visible treatment.

How you know it worked

1. For every link you set to same-tab: click it, then press Back. You should land where you started, with your state intact. That round trip is the entire point.
2. For every link you kept with a warning: walk it with a screen reader. VoiceOver (Cmd+F5) or NVDA should announce the link name followed by “Opens in a new tab” before you activate it — a warning delivered after the jump is not a warning.
3. View the served source. The annotation span, complete with its data-klarvo-profile marker, should sit inside the anchor in the HTML your server sends — or the target attribute should be gone from it. That served-source presence is exactly what re-validation asserts before the fix is recorded.
4. Re-scan. Annotated links are recognised and not re-reported; de-targeted links no longer match the detection at all. The family’s count falls as decisions are made, and only as decisions are made — a queue this family never empties on its own is a queue working as designed.
5. Check you have not doubled up. If your theme already prints a visible “(opens in new tab)” on external links, choose the same-tab fix or decline the change for those links in review — one clear cue beats two competing ones.