There are places in core where we link out to external resources. One of these is in the installer, when there is an unmet requirement. Another is in the the date formatters, where there is link out to the PHP docs so people can reference how to construct custom date strings. There are other places, and contrib space adds lots more.
There are some older, related issues about this for specific cases, but no consolidated policy that we can point to. External links are also handled in an inconsistent manner with regards to links opening in a new windows, rel=external, etc.
We should formalize our approach to how external links are handled, and as a followups, apply the policy, taking into account the proper context.
Policy should take into account the current best practices for usability and accessibility, provide concrete examples for usage, but also allow for context specific exceptions when needed.
The Drupal core Accessibility → core gate states that a goal of core is to conform to WCAG 2.1. That standard has recommendations, https://www.w3.org/WAI/WCAG21/Techniques/general/G200, for this case.
Is it feasible to add a code sniff for target="_blank" in our CI testing?
Closed: outdated
11.0 🔥
base system
Makes Drupal easier to use. Preferred over UX, D7UX, etc.
It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
The Drupal core Accessibility → core gate states that a goal of core is to conform to WCAG 2.1. That standard has recommendations, https://www.w3.org/WAI/WCAG21/Techniques/general/G200, for this case.
There is an item here to add a sniff for target=_blank. But there are valid cases for using _blank so adding a sniff to to warn about it's use could be disruptive when running commit-code-check.sh.
Therefor, I think everything is done here.
Thanks everyone!