Opening Links in New Tabs  ## Metadata - Author: [[The Admin Bar]] - Full Title: Opening Links in New Tabs - Category: #articles - Document Note: --- tags: - #accessibility - #wordpress - #ux Author: The Admin Bar Source: The Admin Bar (Website) Reference: https://theadminbar.com/accessibility-weekly/opening-links-in-new-tabs-or-not/ date created: 2025-08-21 00:00 --- # Title: Opening Links in New Tabs (or Not) ## Table of Contents: - [🔗 Are links opening new tabs bad for accessibility?](#-are-links-opening-new-tabs-bad-for-accessibility) - [🧭 When opening in a new tab is needed](#-when-opening-in-a-new-tab-is-needed) - [📏 Links opening new tabs and WCAG](#-links-opening-new-tabs-and-wcag) - [⚠️ How to warn about new-tab links](#%EF%B8%8F-how-to-warn-about-new-tab-links) - [🤖 Automating warnings](#-automating-warnings) - [👤 About the contributor](#-about-the-contributor) - [📚 References](#-references) ### References: Include a list of sources consulted and cited in the article. - Web Content Accessibility Guidelines (WCAG) 2.x — 3.2 Predictable; 3.2.5 Change on Request (AAA) - Equalize Digital Accessibility New Window Warnings plugin ## 📝 Summary: The article argues that forcing links to open in new tabs (target="_blank") often harms accessibility and user experience because it creates unexpected context changes, especially for users with low/no vision or cognitive disabilities. Best practice: don’t force new tabs; let users decide. Exception: mid-process scenarios (e.g., within forms) where navigating away would lose progress. If new tabs are necessary, provide clear visual and screen-reader warnings. The piece references WCAG requirements and offers code examples and a plugin-based automation approach for adding warnings. ## 📖 Main Content: The common heuristic “external link → open in new tab” prioritizes site retention over user control. For many users, unexpected new tabs break the back-button flow and cause disorientation. WCAG treats unexpected context changes as a predictability problem; thus, links should not change context without user initiation or an opt-out mechanism. The key justified exception is in multi-step processes or forms (e.g., terms and conditions) where losing state is costly. When opening a new tab is required, implement both visible indicators (icon) and nonvisual cues (screen reader text) and consider automated solutions when scale makes manual fixes impractical. This approach balances UX, accessibility, and compliance while educating clients and content authors to avoid defaulting to target="_blank". ### 🗒️ Notes - The problem with target="_blank": - Unexpected context change; back button no longer returns to previous page. - Disorienting for screen reader users and those with cognitive disabilities. - Violates predictability principles and can degrade task flow. - Best practice stance: - Default: Do not force new tabs. - Empower user choice via browser controls (right-click, keyboard shortcuts). - Legitimate exception: - Mid-process/form contexts where navigation away would lose progress. - Example: “I agree to the terms and conditions” links in forms should open in new tabs to protect state. - WCAG alignment: - 3.2 Predictable: pages must operate in predictable ways. - 3.2.5 Change on Request (AAA): context changes only on user request or with a way to disable. - For compliance, new-tab links should include visible/auditory warnings. - Warning pattern (implementation): - Visible icon for sighted users (e.g., Font Awesome external-link icon). - aria-hidden="true" on the icon to prevent redundant announcements. - Screen-reader-only text appended (e.g., “ opens a new window”). - Mind the preceding space before the SR text to avoid concatenation issues. - Scaling the pattern: - Manual additions feasible for a few links; automate for many. - Options: JavaScript selecting target="_blank" links, or a WordPress plugin to inject warnings. - Tooling: - Accessibility New Window Warnings plugin can auto-insert warnings and clear checker notices. - Client/content governance: - Encourage rethinking the “external link = new tab” habit. - Provide guidance and guardrails in CMS to limit new-tab toggles. ## 📖 References: - WCAG 2.x — 3.2 Predictable; 3.2.5 Change on Request (AAA) - Equalize Digital: Accessibility New Window Warnings plugin - Font Awesome external link icon documentation - WordPress editor link settings ## 🗣️ Paraphrase: - Original idea: “If a link opens a new tab, it can be disorienting... back button no longer works… Best practice to almost never open links in new tabs; let users choose.” - Paraphrase: Opening links in separate tabs often disrupts navigation, particularly for blind or low-vision users and people with cognitive disabilities, because it breaks the back-button workflow. The recommended default is to avoid forcing new tabs and instead allow people to decide using their own browser actions. - Original idea: “One major instance… in the middle of a form or multi-step process… e.g., ‘terms and conditions’ in a form.” - Paraphrase: A clear exception arises when users are in the midst of completing a form or multi-step task. In such cases, auxiliary links (like terms and conditions) should open separately so the in-progress data isn’t lost. ## 📰 Newsletter: Learning the web the right way means building for everyone. This week, we’re revisiting a familiar toggle: “Open link in new tab.” It’s tempting, but forcing new tabs can disorient users by breaking the back button flow—especially for folks using screen readers or with cognitive disabilities. The rule of thumb: let users choose, except during multi-step processes or forms where you risk losing state (think “terms and conditions” links mid-form). If you must open a new tab, add a visible icon and screen-reader text so expectations are clear. For WordPress, the Accessibility New Window Warnings plugin can automate those cues across your site. Also on our radar: incremental enhancements to the Block Editor, lively community discussions at the WordPress Accessibility Meetup, and a handful of new plugins improving performance and a11y. Keep shipping inclusive experiences—small choices add up to big wins. - Read more: Opening Links in New Tabs (or Not) - Tool spotlight: Accessibility New Window Warnings (WordPress) - Community: WordPress Accessibility Meetup ## ✅ Action Items: Prompt for mapping article to your Developer Advocate/OSPO trajectory: - Identify how the guidance on target="_blank" supports open-source accessibility norms (WCAG) and WordPress contributor education. - Outline contributor onboarding materials that teach when not to force new tabs, the valid exceptions (forms), and how to implement warnings with semantic HTML, ARIA, and icons. - Design a workshop module: “Predictable navigation and context change” with code labs for adding SR-only text and automating patterns (plugin or JS). - Propose community health metrics: reduction in new-tab violations across key repos/themes; PRs that add warnings. - Connect to OSPO goals: codify accessibility review checklists, include link-behavior policies in contribution guidelines, and champion funding for accessibility tooling (e.g., maintaining the warning plugin). - Advocate transparency: publish decision logs for UX trade-offs (retention vs. user control), and create inclusive documentation for non-technical contributors. - Stage and off-stage alignment: conference talk + repo wiki + onboarding videos demonstrating the practice; mentorship for first-time contributors implementing these fixes. ## 🧪 Hypotheses: - H1: Adding visible and SR-only warnings to new-tab links reduces task abandonment for screen reader users. - H2: Defaulting external links to same-tab increases perceived control and decreases disorientation across all user groups. - H3: Automating new-tab warnings at scale (plugin/JS) improves WCAG conformance rates without measurably increasing page load. - H4: In form contexts, forcing auxiliary links to open in a new tab decreases user error and re-entry rates. ### 📊 Methodology: - Data sources: analytics on back-navigation behavior, form completion funnels, screen reader user testing sessions, Lighthouse/axe scans, support tickets. - Designs: - A/B tests: same-tab vs. f - Summary: Target=”_blank”: it’s so easy to add this to HTML code or to toggle the checkbox in the WordPress editor to set links to open in new tabs, and we frequently do it wit... - URL: https://theadminbar.com/accessibility-weekly/opening-links-in-new-tabs-or-not/  Target=”\_blank”: it’s so easy to add this to HTML code or to toggle the checkbox in the WordPress editor to set links to open in new tabs, and we frequently do it without a second thought. Many people operate by this logic, “If a link goes to a different website, then it should open a new tab so that users don’t lose my website.” #### **Are links opening new tabs bad for accessibility?** If a link opens a new window or tab, it can be disorienting for some users, particularly those with low or no vision or who have cognitive disabilities. When a link opens a new tab, the back button in the browser no longer works, and instead, users have to close the tab to return to the content they were previously on. This can disrupt their browsing experience, particularly if they do not know that a new tab opened. For this reason, it is generally considered a best practice to almost never open links in new tabs or windows and to allow users the choice to open links in new tabs or not (which they can do by right-clicking the link and choosing to open a new tab or via a keyboard shortcut). #### **When Links Opening New Tabs is Needed** There is one major instance in which you need to have links open new windows or tabs: when the link is in the middle of a form or multi-step process, and clicking the link would cause the user to lose progress in the form or process if it opened in the same tab. For example, any time you’re creating a form, and you add a checkbox that says, “I agree to the terms and conditions” with “terms and conditions” linked to that policy, you want that link to open a new tab. Nothing is more frustrating than clicking a link in a form and losing the page, then having to start over from the beginning. #### **Links Opening New Tabs and WCAG** Generally, when doing an accessibility audit, we’ll fail a link that is set to open a new window or tab under Web Content Accessibility Guidelines (WCAG) under * [3.2 Predictable](https://www.w3.org/TR/WCAG21/#predictable), a top-level category that says you need to make Web pages appear and operate in predictable ways, or… * The AAA success criterion, [3.2.5 Change on Request](https://www.w3.org/TR/WCAG21/#change-on-request) . This success criterion requires that context changes are initiated only by a user request or a mechanism is available to turn off such changes. New browser tabs or windows are considered context changes. For WCAG compliance, links with target=”\_blank” will be failed if they don’t have a visual and auditory warning on them telling the user they will open a new tab. This is a little fuzzy as a WCAG *requirement* at the AA level (vs. a best practice) but is more clearly a requirement at the AAA level. #### **Warning About Links That Open New Tabs** We try, as much as possible, to get clients and content creators not to open links in new windows or tabs. Rethink the urge to click that new window toggle just because you’re linking to something off-site. But, in a situation where a new window link is needed – or when you have given up battling your client – the way to improve the accessibility of these links is to warn the user that the link will open in a new tab or window before they click the link. Generally, you do this with a visible icon and hidden [screen reader text](https://theadminbar.com/accessibility-weekly/adding-theme-support-for-screen-reader-text-and-ideas-for-using-it/). ##### **How to Warn About Links Opening in New Tabs** Here’s an example of this on the Equalize Digital website:  The code for this link is: ``` <a href="<https://www.facebook.com/groups/wordpress.accessibility>" class="primary-button" target="_blank" rel="noopener">Join the Community <i class="fas fa-external-link-alt" aria-hidden="true"></i><span class="screen-reader-text"> opens a new window</span></a> ``` You can see that inside the link, we have done two things to warn users: 1. **Added a Font Awesome icon** so that sighted people know the link opens in a new tab. That’s this code:<i class=”fas fa-external-link-alt” aria-hidden=”true”></i>Note that we added [aria-hidden](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-hidden) on it so that screen readers will ignore it and won’t say “image” when reading the link. 2. **Added screen reader text so that people who are blind or have low vision and use a screen reader will hear that the link will open in a new window. That’s this code: <span class=”screen-reader-text”> opens a new window</span>Helpful note here: This span starts with a space so that the screen reader doesn’t attempt to read “community” and “open” as one word. Adding a span tag doesn’t add a space, so you need the space either before or in your span tag.** If you have one or two links that open in new tabs, you could easily add this manually to each link. But if you have many links that open new tabs, you don’t want to add these warnings one by one. ##### **Automatically Warning About New Window Links** If there are many links on the website that open in a new tab, you want to add warnings to them all automatically. You can code this with JavaScript using target=”\_blank” as a selector (I can’t find a good tutorial for that, unfortunately). If you don’t want to code it yourself, my company has a [free plugin, Accessibility New Window Warnings](https://wordpress.org/plugins/accessibility-new-window-warnings/) , that will automatically create all of these warnings for you. It also has the bonus of automatically removing all the “Link Opens New Window or Tab” warnings in Accessibility Checker across your entire site when activated if you’re using Accessibility Checker. You can use our plugin or download it and check out the code if you want to package similar functionality into a custom theme. #### **Additional Resources**  Amber Hinds is the CEO of Equalize Digital, Inc., a Certified B Corp specializing in WordPress accessibility, maker of the Accessibility Checker plugin, and lead organizer of the WordPress Accessibility Meetup and WP Accessibility Day conference. Through her work at Equalize Digital, Amber is striving to create a world where all people have equal access to information and tools on the internet, regardless of ability. Since 2010, she has led teams building websites and web applications for nonprofits, K-12 and higher education institutions, government agencies, and businesses of all sizes. Through this journey, she learned about the importance of making websites accessible to everyone, and it has been her passion to bring awareness to accessibility and make website accessibility easier, ever since., Opening Links in New Tabs, The Admin Bar, 01gyyn81zsaw8d93763wxxbzhm.