Link opens in a new tab without warning text

What is this issue?

An <a> element has target="_blank" set, so activating it opens its destination in a new browser tab instead of navigating the current one, and neither the link’s visible text nor its aria-label mentions that a new tab is about to open. The link itself works exactly as intended; the gap is the absence of any warning before the context change happens.

This is a behavior-warning problem, not a destination-description problem: a link can be perfectly descriptive about where it goes (“Read our privacy policy”) while still failing this check by giving no indication that clicking it changes how the page behaves, specifically that the current tab stays put and a new one appears.

Why does this matter?

Opening a new tab is a legitimate, common pattern, but it’s also a context change a user didn’t explicitly request; they clicked a link, not “open a new tab.” When nothing warns them in advance, the first sign something unusual happened is often confusion: the page they were on didn’t change, so it can look like nothing happened at all, or a new tab appeared that they didn’t consciously choose to open.

The most common downstream failure is a broken mental model of the Back button. A user who doesn’t register that a new tab opened will click Back in the new tab, land back on the same page they just clicked from, and conclude the link “did nothing” or that Back is malfunctioning, when in reality their original tab, with their previous scroll position and task state, is sitting untouched one tab over.

Who is affected?

• Screen reader users: screen reader and browser combinations inconsistently announce that a link opens in a new window, so many users get no signal at all before the context change happens, and have to actively check their tab list to confirm what occurred.
• Cognitive disabilities: an unannounced new tab is a disorienting, unrequested change of context that can break a user’s sense of where they are in a task, especially for anyone who relies on a single, linear browsing flow to stay oriented.
• Low vision: a new tab opening off to the side of the screen, outside a magnified viewport that’s zoomed into one area of the page, can go completely unnoticed by someone using screen magnification, who then continues interacting with what they believe is the original tab.

What users experience

Grace has a traumatic brain injury that affects her short-term working memory and uses a fairly zoomed-in browser view to read comfortably. She clicks a “Terms of Service” link on a signup form, which opens in a new tab outside her zoomed viewport with no warning in the link text. She keeps interacting with what she assumes is the same page, filling in the next form field, confused when her earlier progress and error messages seem to have vanished, because she’s now looking at a fresh tab layered underneath the one she was actually using, with no indication a switch had occurred.

How do I fix it?

Add a short, consistent warning to the link’s accessible name whenever target="_blank" is used, either directly in the visible text or through aria-label if the visible text needs to stay unchanged. This works because it gives every user the same advance notice at the exact moment they’re deciding to click, regardless of whether their specific screen reader and browser combination happens to announce the new-tab behavior on its own, which, since that support is inconsistent, you can’t rely on.

If a link opens a file in addition to opening a new tab (a PDF, for instance), combine both warnings in the same accessible name, since each one addresses a different unexpected behavior a user deserves notice of before clicking. When this pattern is generated by a shared component across a site, fix the warning once in the component so every rendered instance inherits it automatically, rather than patching individual links by hand.

Code Examples

<a href="/pricing" target="_blank" rel="noopener">Pricing</a>

<!-- Method 1: warning in the visible text (preferred) -->
<a href="/pricing" target="_blank" rel="noopener">
  Pricing (opens in new tab)
</a>

<!-- Method 2: aria-label when the visible text must stay short -->
<a href="/pricing" target="_blank" rel="noopener" aria-label="Pricing, opens in new tab">
  Pricing
</a>

rel="noopener" in the original example is a security attribute, not a warning: it stops the new tab from getting a script reference back to the tab that opened it, and does nothing to inform the user a new tab is coming. Both fixed versions add that missing information directly to the accessible name; Method 1 makes it visible to everyone, while Method 2 keeps the shorter “Pricing” label intact while still exposing the warning to assistive technology.

Common Mistakes

Mistake: “rel="noopener" already handles the new-tab concern.” rel="noopener" and rel="noreferrer" are security measures that prevent the new tab from manipulating the tab that opened it; they have no effect on what a user is told before clicking, and a link can carry both attributes correctly while still giving zero warning that a new tab is about to appear.

Mistake: “Screen readers announce new-tab links automatically, so no extra text is needed.” Support for announcing target="_blank" behavior varies across screen reader and browser combinations, and several common pairings announce nothing distinctive at all. Relying on inconsistent, unverifiable behavior isn’t a fix: the link’s own accessible name needs to state the warning explicitly so every user gets it regardless of their specific setup.

Mistake: “Users expect external links to open in a new tab, so no warning is really necessary.” Even a common pattern still counts as an unrequested context change the first time, and for cognitive-disability and low-vision users specifically, “common” doesn’t reduce the disorientation of an unannounced tab switch. Familiarity with the general pattern doesn’t substitute for an explicit signal on the specific link being clicked.

How RedFlag Detects This

Guidance only: RedFlag documents this issue but does not currently flag it; verify manually. This check has no automated detector wired into RedFlag’s rule catalogue, coverage matrix, or manual-check workflow today; it exists purely as documentation for a real, checkable accessibility problem RedFlag doesn’t yet track in any automated or semi-automated form.

The reason this is hard to automate cleanly is that detecting target="_blank" on a link is trivial, but judging whether the accompanying text adequately warns the user requires evaluating the meaning of that text, not just its presence: a link reading “Pricing details, opens in a separate browser tab” and one reading “Pricing (external)” both technically contain some signal, but only a human reader can judge whether either one clearly communicates the specific behavior a new tab produces. Manual step: use the Manual Testing steps below on every target="_blank" link on the page; there is no automated substitute today.

Manual Testing

1. View the page source or use browser DevTools to find every <a target="_blank"> element.
2. For each one, read its accessible name: the visible text plus any aria-label.
3. Confirm the name clearly indicates a new tab or window will open, using recognizable phrasing like “opens in new tab” or “opens in a new window.”
4. With NVDA or VoiceOver running, Tab to each link and listen to what’s announced, confirming the warning is actually part of what the screen reader reads aloud, not just present visually.
5. Flag any target="_blank" link whose accessible name gives no indication of the tab-opening behavior.

Related WCAG Success Criteria

3.2.2 On Input: Changing the setting of a user interface component must not automatically cause a change of context, unless the user has been advised of the behavior beforehand. Opening a new tab is a change of context, and this rule’s failure is precisely the “advised beforehand” clause going unmet: the link’s own text is where that advance notice belongs.

Related Issues

Link is not distinguishable from surrounding text without color covers a different link-related visual clarity concern worth checking alongside this rule on the same page.

Button or link has no accessible name is a more foundational failure in the same family: a link needs a working accessible name at all before a new-tab warning can even be added to it.

Link text is generic and gives no context shares this rule’s “predict what happens before you click” principle, applied to vague destination wording rather than missing behavior warnings.

Link opens a file with no format or size warning is the closest sibling to this rule: the same missing-advance-notice pattern, applied to file downloads instead of new tabs, and a link can fail both at once.

References

• W3C Understanding 3.2.2: On Input
• W3C Technique G200: Opening new windows and tabs from a link only when necessary
• MDN: The anchor element, target attribute