You might read the blog's title and think, "How much is there to know about links and buttons?" A hyperlink, or link, is for moving from one page to another, and a button triggers an action, like the submit button on a web form.
Surprisingly, these two interactive elements are often used interchangeably, but they actually serve very distinct purposes. In this blog, we’ll clearly define a link and a button, discuss the accessibility considerations for each, and explain when to use them.
A link is an interactive element that, when clicked, moves users between web pages either within the same website or to an external website or digital document such as a PDF. A button is an interactive element that, when clicked, triggers an action like submitting a web form or playing a video.
An interesting thing happened during my research for this post. It occurred to me that an "email link" functions as a button. An email link launches an email client. 🤔
I contacted a friend of mine, a former colleague from my days in higher ed, and asked his opinion. He’s a screen reader user, so I thought if anyone could help shed some light on this quandary, it would be him.
Here’s our conversation:
This conversation is also a great reminder as to why it is so important to test your website and digital documents with people with disabilities.Me: I’m writing a blog about the diff between a link and button. Link is for navigation, button triggers and action.
But, an email "link" triggers an action of launching the email client.
What does NVDA call out when you encounter an email link? How do you know it is an "action" link and not a "navigational" link?
Him: It calls out the label and the roll "link." I don't hear any distinguishing announcement to identify that it is an action link.
I personally know the difference because the label is usually an email address.
I have been surprised by a few non-standard ones where the label is some version of "contact us" or "email us."
Me: So really, to do it correctly and make it truly accessible, the label should be <link> and the role=email. Would that make a difference?
Him: I would use aria-describedby and have the announcement that points to mention that it opens an email client.
Keeping Them Accessible
The accessibility considerations for links and buttons are almost identical, except for the native markup used to identify each element, the use of color, and the target size, which applies to buttons.
When using links and buttons, make sure screen readers can correctly interpret their function by using appropriate HTML tags. <a> for links, <button> for buttons.
"An anchor <a> gives the following advantages:
- Navigates to new pages
- Allows browser refresh
- Supports opening in new tab/window
- Provides with default tab focus with (href) attribute
- Supports in-page skips with internal href attributes
- Provides an implicit role (link role) to screen readers
- Shows active, visited, hover and focus
Buttons <button> provide the following advantages:
- Can be disabled
- Have default keyboard focus
- Are activatable by space key
- Provide an implicit role (button) to screen readers
- Submit and reset forms, open modals, and expand/collapse panels.
At any point, native markups have much more to offer developers and users than custom controls." ~ Courtesy of "Links VS Buttons: A Perennial Problem"
When it comes to buttons, users with dexterity or fine motor limitations can struggle to select small buttons accurately, especially when they are clustered closely together. To eliminate this issue for those users, ensure your buttons meet the minimum size or have sufficient spacing around them according to the requirements in SC 2.5.8: Target Size (Minimum) (Level AA).
The requirement is for targets to be at least 24 by 24 CSS pixels in size.
One exception is spacing around the target. Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a circle with a diameter of 24 CSS pixels is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target.
Not only does the button size affect a user’s ability to interact with it, but understanding what action the button will invoke is just as important. For this reason, buttons or any other interactive graphical element should not be designed with color as the only indicator of function or information. Not only does that confuse sighted users, but buttons must have a clear, accessible name to allow assistive technologies like screen readers to identify and describe the button's function, such as 'Submit.'
Both links and buttons share the following four accessibility considerations:
- Focus Visible
Visible focus indicators help users, especially those who use a keyboard to navigate, know where they are within a digital document or webpage. Ensuring that elements receive focus and that focus is visible is what makes navigating with a keyboard easier, just like a cursor does for mouse users. Clear focus indicators benefit people with ADHD and dyslexia and individuals with limited fine motor control in their hands who can not use a mouse.
To comply with SC 2.4.7: Focus Visible (Level AA), do not remove the default browser focus indicator unless you provide an alternative keyboard focus indicator. In addition, since focus indicators are considered "visual information," they must comply with SC 1.4.11: Non-text Contrast and SC 2.4.13: Focus Appearance. Get more information and clarification on the relationship by reading SC 2.4.13: Focus Appearance (Level AAA) - Relationship with Non-Text Contrast. - Color contrast
Proper color contrast applies to links and buttons, but each has different WCAG success criteria. Since traditional links are text links, they must follow the requirements in SC 1.4.3: Contrast (Minimum) (Level AA). This criterion states, "The visual presentation of text and images of text has a contrast ratio of at least 4.5:1..." against their background. Exceptions are large text (at least 18 point or 14 point bold), incidental text, and logotypes.
Since buttons are considered non-text, they must comply with SC 1.4.11: Non-text Contrast (Level AA). This criterion states, "The visual presentation of the following has a contrast ratio of at least 3:1 against adjacent color(s): User Interface Components and Graphical Objects" like buttons. - Discernable text
Discernible text can be seen, perceived, and understood by website users while conveying the link's purpose —its destination, function, or action. Screen readers cannot identify the purpose of elements labeled as links or buttons without accessible names. Link text must be distinct, focusable, and distinguishable by screen readers. Buttons must also have clear, descriptive text to inform screen reader users of their intended action or destination.
Do not create links or button text that reads "Click Here" or "Read More" or anything along those lines. Users can configure their screen reader to listen to a list of links instead of reading the entire page. This is very helpful when searching for a particular link, like a sighted person may do when scanning a page looking for something specific. When using this configuration, a screen reader reads only the link text, not the text surrounding the link. Therefore, the link itself must make sense out of context. For example, close your eyes and repeat this phrase 5 times out loud: "Link. Click here." Are those links helping you find what you’re looking for? Are you just a little annoyed having to hear the same thing repeatedly? That is precisely what a screen reader user would hear from a page full of "Click Here" and "Read More" links. - Keyboard accessible
People who use a keyboard to navigate the web are typically those with visual impairments, like blindness or low vision, who rely on screen readers. However, individuals with motor disabilities that limit their ability to use a mouse also use a keyboard. And there is a large community of people, myself included, who prefer keyboard navigation for efficiency reasons.
Ensure your links and buttons are accessible by keyboard only. And just as important, they must be in the proper tab order for web content and reading order for digital documents like PDFs.
When to Use a Link and When to Use a Button
Use a link when you want your user to navigate to a different page or section on the same website. This action doesn't change the state of the website.
Use a button to trigger a specific action that alters the current page or performs a function, such as submitting a registration form or playing a video. This action does change the state of the website.
Why Does All of This Matter?
It matters to assistive technologies and the people who use them.
Resources
- Links
- Links and buttons on websites
- Links must have discernible text
- Buttons must have discernible text
- Links vs buttons vs other clicky things
- Links VS Buttons: A Perennial Problem
- Button States Explained – How to Design them
- Making your links "readable" for screen readers
- One Button to Rule Them All: Making Accessible Buttons