Angela P Ricci

One idea I used to introduce during my accessibility training was the way we should think about content seen versus content heard. This was a way to make developers think about not only what they were seeing, but also what they would hear if using a screen reader — yes, I used to introduce how to use a screen reader during the training, but they were very reticent and scared to use it, so most of the time I should provide the results myself.

It is very easy to focus on the visual starting point and to forget screen reader users, specially when we're not used to test what we code with a screen reader. One simple but interesting case to confront this view is with external links.

An external link will open on a new window or tab when you click on it. This behaviour is different from the natural, original link behaviour, and it may surprise the users who suddenly find themselves in a different context. It is then a good idea to warn them that we are “leaving” the current web site.

An usual way to indicate external links to the users is by adding an icon after the link:

I'm an example of an external link

What you're probably thinking is “but this is only a visible clue”; what about screen reader users? Right! That means that the icon we're adding convey an information, and so it should appear in our code, with a proper alternative text:

HTML:

<a href="#" target="_blank">
    I'm an example of an external link 
    <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="currentColor">
    <title>Opens in a new window or tab</title>
    <path d=". . ."></path></svg>
</a>

Oh, that was easy! Everybody gets the message: I see the icon, screen reader users “listen” to it. But wait! Of course, we'd want this icon to appear every time we have an external link, and it would be great if it could be done automatically, so we won't have to add the icon manually every time we need it.

As we've seen, to tell the browser that we want a link to open on a new window or tab we have to add the target attribute, usually with the value _blank (while we may chose a value to indicate a specific window or tab, _blank will always open a new one):

And here we have the simple beauty of the web: different tiny little cogs working together to build small wonders. Using attribute selectors we can target exactly what we want in our HTML markup, as many times we want to, and style this markup the way we want to.

CSS:

a[target] {...}

Here we use the target attribute to get all links that present it; great, but what to do with it? That means that we get rid of the icon in the markup? And if we do, how we convey the information of an external link?

It turns out that, as you may know, we can define content through the CSS using pseudo elements, one of the amazing features of CSS.

We clean our HTML — no more useless icons repeated everywhere — and we get the most of CSS, adding the icon as a background image via a pseudo element that will also warn the user about the external link.

HTML:

<a href="#" target="_blank">A sample link</a>

CSS:

a[target]::after {
	content: 'Open in a new window or tab';
	display: inline-block;
	overflow: hidden;
	text-indent: 50px;
	white-space: nowrap;
	width: 16px;
	height: 16px;
	background: url('../img/external-link.svg') no-repeat bottom right;
	padding-left: 0.5rem;
}

Of course we'll have to hide the text from display — hence the overflow: hidden, but it will still be there for screen reader users.

Isn't that amazingly simple and clever?

We may argue that the best option would be to have the text just right there:

I'm an example of an external link [Opens in a new window or tab]

It is indeed a very straightforward and sure way to inform the users, but this message would become repetitive and redondant after sometime. Think about it: by displaying only the icon with our little trick, a screen reader user will always be warned about external links, while other users will figure it out what the icon means the first time they click on it, and they won't be surprised the next time it happens.

Remember that some clients are not aware of how important it is to inform users of context changes, or how screen reader users consult web sites. Usually they don't like much that icon appearing in their links. What to say of a warning text? With this little trick, I believe we may make everybody happy.

Don't miss the next post, when I'll talk about how much I hate Figma.