Accessibility of window.opener navigation

Published:

Background

It’s possible to create links that open in new windows (or tabs) by default.

<a href="popup.html" target="_blank" rel="opener">
  Open pop-up (in a new window)
</a>

Pages opened this way have access, via window.opener, to the window of the page that opened them. This could be used, for example, to allow a help pop-up in a web-app to direct the user to a different part of the app.

Problems

  1. If you can see the screen, you would notice the opening page (or its browser tab) change when the navigation is instigated from the pop-up—but what if you can’t?

    Screen readers either don’t get informed when navigation occurs in a non-current tab/page, or they don’t tell their users. Generally that’s fine, as most of the time such announcements would be too verbose, plus there would be privacy concerns from the browser’s perspective. However, in this case, that information is important.

  2. Interestingly, whilst testing, I found that window.opener isn’t made available when the user actively chooses to open target="_blank" rel="opener" links in new tabs or windows.

    Creating a separate sandbox for links that the user elects to open in a new tab/window is relatively long-standing and by design. However, I’m not sure if the implications for target="_blank" rel="opener" links were, or should be, taken into consideration.

Test procedure

  1. Visit the start page for the test.

  2. Open the link in the start page to bring up the pop-up.

    • Try opening the link normally. (Current browsers open links with target="_blank" in a new tab instead of a new window.)

    • Try actively choosing to open the link in a new tab or window.

  3. Activate the button in the pop-up, to navigate away from the start page in its window.

  4. With a screen reader running, note whether the navigation is announced.

Test results

Is there an announcement when the button is used to navigate the opening page?

Browser NVDA 2019.3.1 JAWS 2019.1912.1 VoiceOver (Mac)
IE 11 No announcement No announcement -
Firefox 75 No announcement No announcement -
Chrome 81 No announcement No announcement -
Safari 13.1 - - No announcement

Tests were run on Windows 10 version 1909 and macOS Catalina 10.15.4.

The pop-up page could not control the location of its opener.

Suggestions

From personal experience, it seems this technique is rarely used, but it does create accessibility barriers for some people. There are two ways we could address this…

  1. The simplest solution would be to make the labelling of the control in the pop-up clear, so users know that it will navigate the opening page. In order to encourage web authors to do this, we could amend the opener example in the spec to reflect this and/or add a note about it.

  2. It may be helpful for screen readers to notify their users when navigation occurs in the current window’s opener. We could investigate whether this specific use case can be accommodated by, or added to, the relevant APIs.

Regarding the behaviour of links explicitly opened in new tabs/windows: as above, the current browser behaviour is relatively long-standing and by design. However, I’m not sure if target="_blank" rel="opener" links were discussed and deemed an acceptable, or desirable, loss of functionality—it would be good to find out.

Reference

List of all tests