Drupal Update broke link options

joshua_davis commented

2022-01-31 17:22:20 +00:00

(Migrated from gitlab.com)

I noticed that the Drupal update that just happened removed the "open in a new window" option for hyperlinks. We need to have this option back.

joshua_davis commented

2022-01-31 17:22:20 +00:00

(Migrated from gitlab.com)

assigned to @mlncn

mlncn commented

2022-01-31 18:08:14 +00:00

(Migrated from gitlab.com)

Hmm

mlncn commented

2022-01-31 20:56:16 +00:00

(Migrated from gitlab.com)

I do not see anywhere where this was taken away in Drupal but i do want to note why they have not added the ability to open in a new window to core— it should be used very sparingly in content:

Use of target="_blank" is an accessibility concern, as opening a new window/tab without providing any warning to users, can be confusing and disorientating.

There are a handful of good uses for opening links in new windows (such as help links on a form), but it's typically overused by authors to enforce their view of how links should be opened, at the expense of users' choice.

The accessibility issue is part of WCAG 2.0 Change on Request. Specifically, just adding target="_blank" to a link will result in F22: Failure of Success Criterion 3.2.5 due to opening windows that are not requested by the user (see example 2 there).

If we implement this feature, we should do it in a way that helps authors to produce accessible content, e.g. rendering these links with an additional icon to indicate that a new window/tab will open. See WCAG technique H83: Using the target attribute to open a new window on user request and indicating this in link text.

Now, WCAG "Change on Request" is at level AAA, but the Drupal core accessibility gate says we aim to satifsy WCAG and ATAG level AA. So there could be an argument that we don't have to address WCAG "Change on request" here. However I certainly don't want to ship a feature that enables authors to (unwittingly) put a specific, known WCAG failure into their content.

Most people do use the back button and taking that away can make it less likely to get back to your site:

https://www.nngroup.com/articles/new-browser-windows-and-tabs/

I do not see anywhere where this was taken away in Drupal but i do want to note why they have not added the ability to open in a new window to core— it should be used very sparingly in content: > Use of `target="_blank"` is an accessibility concern, as opening a new window/tab without providing any warning to users, can be confusing and disorientating. > > There are a handful of good uses for opening links in new windows (such as help links on a form), but it's typically overused by authors to enforce their view of how links should be opened, at the expense of users' choice. > > The accessibility issue is part of WCAG 2.0 [Change on Request](https://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-no-extreme-changes-context.html). Specifically, just adding `target="_blank"` to a link will result in [F22: Failure of Success Criterion 3.2.5 due to opening windows that are not requested by the user](https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/F22) (see example 2 there). > > If we implement this feature, we should do it in a way that helps authors to produce accessible content, e.g. rendering these links with an additional icon to indicate that a new window/tab will open. See WCAG technique [H83: Using the target attribute to open a new window on user request and indicating this in link text](https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/H83). > > Now, WCAG "Change on Request" is at level AAA, but the Drupal core accessibility gate says we aim to satifsy WCAG and ATAG level AA. So there could be an argument that we don't have to address WCAG "Change on request" here. However I certainly don't want to ship a feature that enables authors to (unwittingly) put a specific, known WCAG failure into their content. Most people do use the back button and taking that away can make it *less* likely to get back to your site: https://www.nngroup.com/articles/new-browser-windows-and-tabs/

mlncn commented

2022-02-06 20:17:04 +00:00

(Migrated from gitlab.com)

mentioned in commit 912a1da6a6

mentioned in commit 912a1da6a6c414ce203b97df400d58d3490aae2f

mlncn commented

2022-02-06 20:19:12 +00:00

(Migrated from gitlab.com)

mentioned in commit 092dbb708e

mentioned in commit 092dbb708e7ce6dc9d34647104ed702cbaa6a8e8

mlncn commented

2022-02-06 20:19:52 +00:00

(Migrated from gitlab.com)

mentioned in commit 1e8a28cf3a

mentioned in commit 1e8a28cf3a711bef37954f31a5ff1a2d3cd0041a

joshua_davis commented

2022-02-07 16:37:04 +00:00

(Migrated from gitlab.com)

We've had this conversation before, and as I said the last time, the Collective wants it this way. Implementing this was literally the first thing I was asked to do when I started. And, for the record, about half the sites I regularly read send external links to a new tab. A lot of us prefer it that way. Regardless, the removal of this feature from the CMS makes it so that if someone needs to take over for me, I now have to teach them some basic html, which means our site management is now less accessible. And I don't find the WCAG reasoning very convincing: "New windows take the focus away from what the user is reading or doing." Having the article I'm reading suddenly disappear all together does the same thing. Regardless of our obviously differing opinions on this issue, not having this basic functionality makes my job harder and makes it harder to train others to do my job.

![link-edit-dialog-box](/uploads/7d65d9b115cd866b5bc3fa101337d23c/link-edit-dialog-box.png) We've had this conversation before, and as I said the last time, the Collective wants it this way. Implementing this was literally the first thing I was asked to do when I started. And, for the record, about half the sites I regularly read send external links to a new tab. A lot of us prefer it that way. Regardless, the removal of this feature from the CMS makes it so that if someone needs to take over for me, I now have to teach them some basic html, which means our site management is now less accessible. And I don't find the WCAG reasoning very convincing: "New windows take the focus away from what the user is reading or doing." Having the article I'm reading suddenly disappear all together does the same thing. Regardless of our obviously differing opinions on this issue, not having this basic functionality makes my job harder and makes it harder to train others to do my job.

mlncn commented

2022-02-08 15:42:57 +00:00

(Migrated from gitlab.com)

@joshua_davis the ability was added back (via a different module, Editor Advanced Link, that better supports changes in Drupal and LinkIt) in commit 1e8a28cf and that is now deployed.

Every author has access to the 'Full HTML' input format so they have the ability to specify opening it a new window— and a lot of other things, so it is a little buried.

For a better editor experience and better security we should revisit what HTML tags and attributes editors need, and move away from Full HTML.

@joshua_davis the ability was added back (via a different module, Editor Advanced Link, that better supports changes in Drupal and LinkIt) in commit 1e8a28cf and that is now deployed. Every author has access to the 'Full HTML' input format so they have the ability to specify opening it a new window— and a lot of other things, so it is a little buried. ![add-link-advanced-open-new-window-courtesy-advanced-link-attributes](/uploads/af9545d17d9dfb355e948ea3c473f733/add-link-advanced-open-new-window-courtesy-advanced-link-attributes.png) For a better editor experience and better security we should revisit what HTML tags and attributes editors need, and move away from Full HTML.

mlncn commented

2022-02-08 15:42:58 +00:00

(Migrated from gitlab.com)

assigned to @joshua_davis

joshua_davis commented

2022-02-11 18:35:45 +00:00

(Migrated from gitlab.com)

Thanks for taking care of this.