Links (and buttons)

All right, let’s talk about links and buttons and what you actually need to know right now. This information is adapted from atomica11y.com, atomic a 11 y.com, and from thebookonaccessibility.com.

Now, you’ll notice this lesson isn’t titled accessible links and buttons, because if you made a button or a link that isn’t accessible, you really just made crappy decoration, and that’s not what we’re here to do today.

So let’s begin. Listen, we can’t possibly cover every accessibility rule, every nuance, every little situation you might find yourself in with links and buttons. But what we can do is cover the practical basics and make sure that you know that there are places you can go to get information complete with code examples, design rules, and acceptance criteria at atomica11y.com.

What’s the difference between a link and a button? This is a question that I ask everyone I’ve interviewed for every job. I can tell you this, on the right, we have things that are not the right answers.

Here’s the rule. It’s very simple. If it goes somewhere, it’s a link. You might have a text link that looks like a link. You might have a link that looks like a button. But these are both still links. Even if you have a link that just takes you to a different spot within the same page, that’s a link because it took you somewhere. If it goes somewhere, it’s a link.

But if it does something, it’s a button. You might have a button that looks like a button, or you might have a button that can look like a link. Both of these do something within the page. Buttons expand content. Buttons might launch a modal. Buttons might submit a form. They all do something within the context of a single page. They perform an action on the page. If it does something, it’s a button.

To make links and buttons accessible, we have to make sure we don’t create barriers for anybody with these disabilities. Beginning with low vision, we’re talking about people who are using a desktop device, they’re using a handheld device, but they may be adjusting font size by default on their device to make it easier to read. They might be using a magnification tool, or they may just be and zooming in on their device to get a better look at something.

People who experience color blindness have difficulty perceiving the differences between different colors.

People with motor disabilities may be using a mouse, they may be tapping on their screen but are unable to do so precisely, or they may be using a keyboard or a Switch device, which is something like a game controller. They may even be using voice command to control their device.

People who are blind or very low vision will be using a desktop device. They’ll be using their handheld device, but they’ll also be using an application called a screen reader in combination with a keyboard or a series of swipes and taps on their screen that reads what’s happening on their screen to them.

We also want to accommodate people with cognitive differences. When we’re talking about people with cognitive disabilities, we could be talking about people who have difficulty remembering information, people who have difficulty completing complex tasks, or people who just need additional time to complete a task. But we could also be talking about someone who is drowsy on cold medication or distracted by someone else in their household or someone who is under a tight deadline and they’re very anxious about what they’re doing.

Beginning with low vision, we want to make sure that text can resize up to 200% with no loss of information. Now, this is different from hitting Command or Control plus on your browser and zooming in in that way. This is literally changing the default font size up to 200%. Many people who adjust the text size on their smartphone would say they don’t even have a disability. They just want their text to be easier to read.

Text must have a minimum contrast ratio of 4.5 to 1 or any solid button or link must have a 3 to 1 minimum contrast ratio against adjacent elements. Meaningful icons must have a minimum of 3 to 1 contrast, and any status indicator must be in visual proximity to the text label.

To further accommodate people with low vision or really just everybody, we want to align content to the left. Don’t place buttons in the far right corner or center of the page. People scan the page looking for the scent of what will solve their problem starting on the left side of the page. You want to put buttons and links where they’re easy to find. For someone using a magnification tool, putting a button or a link on the far right side of the page makes it very difficult for them to find it. Someone scrolling through this form now has to scroll way over to the right just to find that button. That’s not a good experience for anybody.

Oftentimes, a button that is disabled on the screen is going to become enabled. So while technically the WCAG rules state that a disabled element isn’t interactive and doesn’t have to meet contrast requirements, we should consider that button is still meaningful and that the text should meet contrast requirements. Something that is going to be interactive is still meaningful to the user and shouldn’t be hidden or grayed out.

We cannot use color or weight alone to indicate that a text or button is interactive. So this practice of simply making a link bold and changing the color is not acceptable. We cannot do that. Just put underlines under your links. Even if you have a link that is spaced out somewhere on the page, far away from other content, you need to find a way to indicate that it is interactive with more than just color or weight. Put an underline under it, or I guess it’s also acceptable to put something like a Chevron or some other indication that this is interactive, but you must commit to doing that consistently across your entire platform.

Now, why don’t these rules apply to navigation? Because you’re not relying on color and weight alone. The context and placement in the page lets you know that a navigation or menu is interactive. It should go without saying, Don’t underline text that isn’t a link. I can’t believe I’m still saying this in the 2020s.

For people with motor disabilities who have a hard time tapping on the screen with precision, the absolute minimum click or tap target area must be no smaller than 24 by 24 pixels with a four pixel margin around it. But really, let’s provide a generous click and tap target area, 44 by 44 pixels. Now, it’s important to understand that this rule does not include inline paragraph text links, and that’s okay.

When we’re talking about icon buttons and links, we want to be exceedingly careful about where we use these. Here’s a great example of a discussion that we need to have about buttons. Ask yourself and those around you, Which of these icons represents upload, send, redo, or compass? Pause the video here and give yourself a minute to think it through. Actually, every single one of these icons represents share in a different app or platform. If you’re going to use icon button or an icon for a link, be absolutely certain through UX research that all of your users are going to understand what it means.

For people using assistive technology, there is a specific set of keyboard actions and touch screen gestures we must accommodate. For links, when someone using the keyboard or a screen reader in combination with a keyboard encounters a link, when they press the tab key, focus will move to the link, and enter, activates the link. For someone using a mobile screen reader, when they swipe left or right, they can move focus to the link, and double tapping, activates the link. The screen reader will read the name and role of the link, and will note it if it’s been visited.

Buttons are a little bit different. For someone using a keyboard or a screen reader in combination with a keyboard, again, they will use the tab key to move focus to the button, but they can use the space bar or the enter key to activate the button. For someone using a mobile screen reader, swiping left or right moves focus to the button, and double tapping, activates the button, the screen reader will read its name. It will read that its role is button, and buttons can have different states like expanded or collapsed for an expander. They might be pressed for some selection, or they might read themselves as disabled, dimmed, or unavailable, depending on the screen reader.

For people using a keyboard, focus must be visible in some way to meet AA requirements, but it’s often easier to meet AAA requirements with a default blanket style like this outline around each control rather than trying to design something specific and special for each individual control type.

Let’s listen to an example of links and buttons using a screen reader.

Link, about. Link, about. Continue, button. Continue, button.

That difference between a link and a button becomes so important for people using the screen reader because it sets an expectation about what this element is going to do. If they click on a link, they expect it to take them someplace. If they click on a button, they expect it to do something.

We must name links and buttons to reflect their purpose purpose or destination. What happens when links don’t express their purpose and destination? People using a screen reader can collect all of the links together into a single unified menu like this.

Check it out. Visited. Learn more. Visited. Find out more. Visited. Get started. Visited.

None of those links are particularly descriptive about their purpose or destination, meaning that someone using a screen reader must dig in and read line by line understand the context like this.

Heading level three. Get 50% off your first bulk order. Bigger bags of beans means great deal shipped to your door. Visited. Link. Find out more.

That’s not the worst possible experience, but it’s still not great. What happens if we make both the headings meaningful links and we make the links meaningful?

Put your favorite coffee on repeat. Visited. Subscribe and save. Visited. Shop bulk deals, get big discounts. Discounts, Visited. Get volume discounts, Visited.

We do need to discuss cards. The card can be clickable with the mouse anywhere, and that’s perfectly fine. But keyboard focus should only land on the links or buttons within the card and not the entire card itself.

We must define the names for screen readers when we are creating icon buttons or links. If you’re going to use icon buttons, do not rely on the image alt text to label the links or buttons.

Favorite button. Favorite button. Favorite Button. Favorite Button.

All of these buttons have a defined name that is the same regardless of the icon that’s being used. When we don’t define a name, someone is going to define that name for us. It’s common for developers to remove the alt attribute from a button icon like this, meaning that the screen reader will read the file name of the image, or they may simply put the file name in the alt attribute. This is not the intended experience that you wanted people to have, so it’s important that we define the names for icon buttons.

Heart Button. Star Icon Button. Icon Thumbs Up SVG Button.

Don’t let this happen to your app.

Where you have an icon with text in a button, it’s important that the image be ignored.

Favorite Button. Favorite Button. Favorite Button.

In each of those cases, the image was completely ignored.

When is it Is it okay to break the rules? Are there times when we should deviate from accessible patterns? Maybe you saw Apple or Google do something that was inaccessible. But look, just because Apple or Google do something doesn’t mean everything they do was created for people with disabilities from the beginning. Maybe your manager thinks that an inaccessible pattern looks cooler this way. As a designer, as a developer, it’s your responsibility to advocate for people using your product. Let’s do the right thing. Maybe someone is telling you that we’re on a tight deadline and we just don’t have time for all this accessibility stuff. That’s nonsense. It doesn’t take any longer to create an accessible link or button than it does to create an inaccessible link or button. Or maybe the devs are telling you that it’s just not possible to make an accessible link or button. There are plenty of examples on atomica11y.com they can use to build accessible links and buttons.

And that’s the end. Go forth and come back when you need help. You can always find code, requirements, and examples on atomica11y.com. And if you’re building an enterprise accessibility program, thebookonaccessibility.com is for you.

Thank you.