Comment 1 for bug 2015592

Revision history for this message
Stephanie Leary (stephanieleary) wrote :

If we are going to open links in new tabs at all, this markup is the best way to do it.

However...

(Well, the Friday afternoon before a long weekend is as good a time as any to make myself very unpopular!)

Opening links in new tabs is such a big problem for screen reader users that we should not be using target='_blank' at all. Adrian Roselli, who does extensive usability testing with assistive technology users, has a very long article digging into the relevant WCAG guidelines and success criteria: https://adrianroselli.com/2020/02/link-targets-and-3-2-5.html

"PowerMapper maintains a page of test results and as of its most recent writing (11 January 2020), this simple link:

<a href='http://www.example.com' target='_blank'>Example</a>

…causes problems in 43 screen reader / browser combinations.

The problems were generally that screen readers did not announce a link would open a new window when encountering it, though some told the user after following the link. The only two that did not have a problem got by on a technicality — they did not warn the user, but they also allowed the Back button to go back to the page."

As of today, three years later, PowerMapper's report is up to 60.

Those of us who do not use assistive technologies can press Control (on Windows) or Command (on Macs) while clicking the link if we want it in a new tab.

The problem for screen reader users is that there is no reverse option; even if we warn them that the link is going to open in a new tab, there is no way for them to opt out of this behavior and just open the link in the current tab.

Ideally, we should eliminate target='_blank' throughout the app and add a lint warning to prevent it from being used in the future.