CODEWITHSUNDEEP
accessibilityuser-experiencewcag
Brett East
Brett East

Reputation: 4322

Is forcing a user to open a link in the current tab WCAG2.0 accessible

We have inherited the maintenance of a 10+ year old website which has a few links in it that force the link to be opened in the current tab. You can't right click on the link and open in new tab, or even copy and paste the url, because it uses javascript and a doPostBack (no idea why, old, old code).

Anyway, I know it's poor user experience, as it's essentially a list of results and you would definitely want to open them in new tabs, also it's crazy to try and stop default browser behaviour.

But I'm wondering if there is anything specific in WCAG2.0 that says that we can't be doing this? I'm trying to make a case to have it changed, but poor UX won't be enough. WCAG however will get it over the line. Is anyone able to point me to anything in the web content accessibility guidelines that explicitly says that a website shouldn't do that?

Much appreciated.

Upvotes: 4

Views: 110

Answers (2)

Steve Repsher
Steve Repsher

Reputation: 400

In my opinion, this is a failure of success criterion 3.2.5 Change on Request at level AAA. Of course, the more common case goes in the opposite direction where links force new tabs or windows without notifying the user, which is documented in common failure 22. However, I would certainly argue that by forcing a change of context in the current tab, which the user may not have requested because they middle-clicked or pressed CTRL+Enter on the link to create a new tab instead, that this is a failure of 3.2.5.

Upvotes: 0

aardrian
aardrian

Reputation: 9029

If the link itself has no href attribute, then it is not keyboard navigable (SC 2.1.1). However, the use of doPostBack makes me think this is ASP.NET 1.0, which stuffed piles of script into every href, so it may be totally accessible to keyboard users.

Otherwise, no. There is no specific Success Criterion in WCAG 2.0 that seems to address your case. There are two that could be stretched with some arguing, but somebody could just as easily argue they do not fit:

  • Success Criterion 2.4.4: Link Purpose (In Context): Level A: This relates to the text in the link, however, if you can make the case that users expect to be able to open in a new tab/window, then the link text should explain that it is prohibited for $reasons.
  • Success Criterion 3.2.4: Consistent Identification: Level AA: This says that things in web pages that behave a certain way should be identified consistently. You could argue that since all other links in the site allow links to open in new tabs/windows (if that is trye), that these links need to identify that they do not behave that way.

In each scenario, if you make your case successfully, the solution is more text. This is not what you want. Unless you can then argue that more text is ugly / difficult to implement / etc. and then use that to justify allowing the links to open in new tabs/windows.

But there are a lot of dependencies to getting to that point (namely, buy-in on the SCs applying).

Overall, I agree that the scenario you have outlined is terrible UX.

Upvotes: 2

Related Questions