Suggestion: look for target=_blank specifically about content-author-accessibility-preview HOT 5 CLOSED

Thank you @abrightclearweb

This is definitely a mis-labelled test, I'll update it in the next version (I might even just patch it quickly, if I get the chance).

I'm tempted to also add the a[target] test back in with the label "forces window behaviour" as I believe that by specifying target="_self" would be forcing the browser behaviour against the visitors preference.

Mainly taken from this CSS Tricks article that goes into _blank issues

There's also a question of what to do if target="_parent" or target="_top" are used. Personally, I feel that a "forces window behaviour" test would cover this and _self but I am not an authority on accessibility so I would love your ( and @grahamarmfield ) thoughts on that.

from content-author-accessibility-preview.

So target="_self" doesn't actually open a new window, but target="_blank" does, as does target="anything_else". I think that's correct?

For me, the key accessibility point is that the user should be warned in advance that a new window should open. This plugin has no idea if the WP theme contains some kind of default way of warning users that a new window/tab will open. This could be some kind of CSS-driven icon or something else. But I think it's valid to warn content editors that they have explicitly asked that a new window will be opened. The editors may not actually be able to do anything about warning the user, but it makes them think.

So how about if the test looked for the presence of the target attribute, but only flagged those instances with an attribute value other than "_self".

Would the CSS for that be: a[target]:not([target="_self"])?

from content-author-accessibility-preview.

Yes, target="_self" opens the link in the same window/tab, so that's not a problem.

Here's a bit about what the other attributes do: https://stackoverflow.com/questions/18470097/difference-between-self-top-and-parent-in-the-anchor-tag-target-attribute

I haven't come across target="_top" and target="_parent" before. I think it's pretty unlikely anyone would use them.

Here's what happens when I try that CSS rule in the plugin @grahamarmfield:

This is my code for the links:

<a href="https://content-accessibility.local/sample-page/">No target</a>

<a href="https://content-accessibility.local/sample-page/" target="_blank" rel="noopener noreferrer">Target blank</a>

<a href="https://content-accessibility.local/sample-page/" target="_self" rel="noopener noreferrer">Target self</a>

<a href="https://content-accessibility.local/sample-page/" target="_parent" rel="noopener noreferrer">Target parent</a>

<a href="https://content-accessibility.local/sample-page/" target="_top" rel="noopener noreferrer">Target top</a>

from content-author-accessibility-preview.

After a little research, _top and _parent do not open a new window/tab if there are no parent or top frames. It's such an old technology that I'm not sure if WordPress would even work with named frames. So not too concerned with those.

Side note, if the target is a named frame that doesn't exist like target="new" or target="foo" then this will default to a new window/tab.

So for completeness, we would need the following selector:
a[target]:not([target="_self"]):not([target="_parent"]):not([target="_top"])

...but that is quite a bit to be checking for on every link and we can be fairly sure that _parent and _top are not going to occur, so we can just use @grahamarmfield 's suggestion of:
a[target]:not([target="_self"])

I should have some time today to patch this on GitHub - but might not get updated in the WP repo this week.

from content-author-accessibility-preview.

Updated on GitHub and WP. v1.1.1 should appear in you updates soon!

from content-author-accessibility-preview.