Accessibility of window.opener navigation

[matatk]

A pop-up window can use window.opener to navigate the page that opened it. This could be used, for example, by a help pop-up in a web app to redirect the user to a different part of the app.

Problem

Screen readers do not announce when navigation has occurred in the original window, meaning that if the user can't see the screen, they won't know it happened.

As an aside: when I was testing (the procedure and results can be found below), I found that the pop-up could not control the original page if the user explicitly chose to open it in a new tab/window. This was surprising to me, but appears to be relatively long-standing and by design.

Suggestion

I think the main problem is awareness, hence I suggest tweaking the part of the spec that covers this technique...

We could amend the opener example in the spec to show web authors/developers how (and why) to make it clear to users where the navigation will happen. This would help by managing the expectations of people who can't see the screen. We could tweak the example and/or add an explanatory note.

If you think it is appropriate to add such clarifications, I'd be happy to make a PR.

Blue sky thought (beyond the scope of the spec): we could look in to the feasibility of relaying opener navigation events to assistive technologies, though my expectation is that this would not be practicable.

Background info

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

When following the pop-up link normally

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.

When explicitly opening the pop-up link in a new tab/window

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

Related bits

• My initial comment on this (outdated)

[domenic]

Hmm, it's a bit unclear why this would be a spec bug. If screen readers are not announcing a navigation, then that's probably a screen reader bug, right?

[matatk]

Hi @domenic. I agree this is something that browsers don't appear to expose to screen readers and/or screen readers don't appear to act upon. However, my personal experience is that this sort of "help pop-up" technique is not widely used, and I'm not sure of any other reason why browsers would want to expose information on activity in non-current tabs to assistive technologies (so that code path may not exist). Thus I'm not sure a technical solution to the problem is feasible.

The spec is not the cause of the issue, for sure, but given that it already contains an example of how opener links could be used, I thought it might be an appropriate place to raise awareness of the accessibility implications of the technique.

I realise that lines have to be drawn at some point as to what should go in, though. Would it make a difference if we were able to determine that browsers are definitely not exposing the navigation information? (If so, I can look into it further.)

[domenic]

I'd welcome second opinions, but I think in general we don't add advice to the spec about how to work around browser bugs. Instead we file browser bugs and work on getting them fixed.

(It sounds like you are claiming this is a browser bug, not a screen reader bug, i.e. the browser should be exposing these events to screen readers but is not.)

[domenic]

Also, does the expectation that browsers notify screen readers on navigations appear in any spec? It seems like that would be a prerequisite for such a note; we can't have the specification talk about implementation-defined behaviors, much less advise people to act in a certain way because of them.

[zcorpan]

I agree that the HTML standard shouldn't give specific advice for this.

Also, does the expectation that browsers notify screen readers on navigations appear in any spec?

Not as far as I know. There's UAAG 2.0, but this isn't worked on currently. It doesn't address navigation as far as I can tell, let alone navigation of a browsing context in the background.

There's https://github.com/w3c/aria-at for manually testing browser/AT combinations and try to get more alignment on their feature support and behavior, but early days still and the initial focus is testing ARIA patterns. In the future, maybe HTML patterns and concepts like navigation and popups could be tested as well.

cc @whatwg/a11y