Creating accessible links

Links are arguably the most important feature of the web alongside the content itself. Content is the information we seek, but we reach that content by clicking a link, which navigates to a new page or site, so it makes perfect sense that our links should be as accessible as possible, so everybody can access content in a way that works for them.

We'll discuss several key concepts to make links more understandable, more inclusive and more useful for readers of your content, whether that be documents or websites.

It's always important to discuss the pet hate of every accessibility professional ever, the links vs buttons battle. A huge part of being an accessibility professional is saying "This link should be a button" or "this button should be a link" until you retire.

Buttons and links are inherently different, it's as simple as "a link goes somewhere, a button does something". A button can be activated with both Space and Return whereas a link can only be activated with return for keyboard users.

When screen reader or keyboard users encounter a button, they have 2 primary expectations:

• It will do something (the button's label should make it clear what that is)
• It will do that thing if they press Space or Return

Conversely, if they encounter a link, they expect it will navigate to a new page, new site or to a section on the current page, again, where it will navigate to should be obvious by the link text alone.

This is not to say links cannot look like buttons, that's another debate and there are bigger accessibility battles to be fought.

The Don'ts

1. Don't display links as the actual web address (URL), as it sounds awful on a screen reader, hearing H, T, T, P, S, Colon, Forward slash, Forward slash, W, W, W, dot, Blog, forward slash, the blog name, Forward slash (you get the idea), also, not all URLs are human readable, sometimes webpages may have a URL that is similar to this: https://www.acme.co.uk/64egeyr8rb/86364ghhs/, due to the way the page was generated by the system, they're difficult to understand for everybody
2. Don't set the visible link text to "here", "click here" or anything else that lacks context in isolation. Some users use assistive technologies which can bring up a list of links to navigate to and when those links have the readable text "here" or "click here", that makes it really difficult for them to understand where that link will go, more so if there are many of them, as this will impact voice input users, as they may instruct their voice control software "Click here", hoping to read more about an interesting blog and end up reading the cookies policy, as their software couldn't guess which "here" they meant
3. Don't have links with the same text, that go to different pages or sites, links should be unique and clearly labelled
4. Make links visually distinctive, a great way of doing that is not removing the underline, because it doesn't go with the site's aesthetic. In certain limited situations it may be OK to remove the underlines, but even then, it should be visually obvious that they are interactive elements
5. Don't open links in a new tab if you can help it, as this can disorient users
6. Focus indicators, always provide strong focus indicators for interactive elements, keyboard users depend on these to know where they are, within a page
7. Don't include the action verb in the text of the link, we often find links that have labels such as "Click here to read about..", "Tap this to..", etc, people know how to activate links and buttons, if they're on your site or reading your document, they likely had to activate a combination of buttons and links to get that far. Links should be as concise as possible
8. Don't change the accessible name of link, this is something that we find a lot, a link may have the visible text of "Menu", but then the developers trying to be helpful, use an aria-label attribute "Site navigation", this practice isn't helpful at all, especially for users of voice input software, as ARIA is powerful, it actually neuters the visible text of the control and means it's actually exposed to assitive technologies as whatever the aria-label is, in our example, a voice input user may try to instruct their software "Click menu", as that is the visible label they see, but the actual accessible name of that control doesn't contain the word "Menu" anymore, as ARIA overwrote it and we now have a mismatch of what sighted users can see and what the name actually is.

The Dos

1. Structure part of the sentence as link text, so it makes sense in isolation, as an example "Hyperlinks - Wikipedia". This approach helps everybody, a screen reader user hears the link with enough context to understand the link's purpose, a user that reads the text of the link will understand, everybody benefits, if the link points to another site, it will likely be useful to include the name of that site in the link text, if it points to something on the same site, something like "About us" is fine
2. Again, this is about using the existing text to provide context, "Read more about my links blog", is unique, descriptive and concise
3. Be specific enough that link texts are unique, don't have 2 links that both have the visible link text as "Wikipedia", when they point to different pages, be specific "Wikipedia Hyperlinks" and "Wikipedia - Buttons (Computing)", each of those helps everybody understand the page their browser will navigate to, if they click it
4. We don't have underlines on our primary site navigation, but we have multiple other ways of making them identifiable as links, the position, users would typically expect to find links in a site header, the labels are quite self-explanatory and then we use semi-bold font, in a purple colour that has a good contrast against both the background and body text. All other text links across the site make use of that underline, we even make it more prominent, by increasing its thickness in supporting browsers (this is what happens when I have artistic license)
5. Are new tabs really an issue? Some people prefer to open links in new tabs, so they don't lose the original source page. Others prefer to stick to the one tab and navigate back to the original page using the browser's back button. We all have different preferences, and we should accommodate those preferences using the best tool at our disposal: choice. If we force everybody to open a link in a new tab, we remove that choice, we're expecting every user to like what we like and if they don't like it, there's nothing they can do about it. We should only open links in a new tab when necessary (W3C). If you do have to do this, for say security reasons, inform a user ahead of time, perhaps include "opens in new tab" in the visible link text, there are multiple ways to open a link in a new tab, without forcing everybody to do that, we include several at the end of this guide
6. If you don't like the default focus ring, there's a few things you should do before removing it:
   • Never do this outline: none;, do this instead: outline: 3px dotted transparent;, this ensures users of Windows High Contrast Mode definitely get a focus outline, as it ignores transparency
   • Create a strong visual focus indicator, borders, toggle underlines or invert background and foreground colours etc, ensure that whichever indicator you create, has a minimum contrast of 3:1 against the unfocused state and is visually obvious to users, we often see weak focus indicators or no focus indicator at all, as developers, we wouldn't hide the mouse cursor, would we? So why hide the focus indicator? It's usually a design thing, a designer may think they look unsightly, speak to your designers, explain how important it is to users, it may be that they didn't know it was harmful, if you're struggling to get buy-in from designers or stakeholders, :focus-visible is a really good compromise, only keyboard users will ever see that, it won't show up on a mouse click
   • Check, check and check again, once you implement a custom focus style, make sure that every interactive element has a good focus indicator, it's easy to miss something
7. Don't state the obvious, don't think you need to provide additional context to screen reader users, as this often makes things more difficult for voice input users. A screen reader hears "Button, menu" or "Link homepage", they know what to do when they hear that information
8. If a sighted user can see a label, that's what a screen reader user must hear and a voice user should be able to instruct their software to "Click" what they can see. Sometimes it is OK to add a little extra information to the end of a visible label, in hidden text, but this should be done sparingly, as VoiceControl (the voice input software on a Mac), expects what the user says to exactly match the accessible name

Extra: tips for opening new tabs