Links vs Buttons

Links and buttons have differences in both appearance and behaviour. The purpose of this section is to help you better understand how links and buttons can be used in an accessible design.

Behaviour

A link, whether to someplace on the same page, same site, or elsewhere on the internet, acts to move a user to a different place. Users expect, based on the behaviour of a link, that they will see a new screen once the link is activated by keyboard, mouse click, or tap. Browsers provide specific additional features for links such as opening in another tab or window. Users can use links in ways that do not disrupt their use of the current context.

A button acts to change a user’s content or context. Users expect, based on the behaviour of a button, that something will happen to their current context once the button is activated by keyboard, mouse click, or tap. Typically buttons impact the current context by providing new information (e.g., search results) or removing what was previously on the screen (e.g., to submit a form).

For keyboard users, who may or may not use additional assistive technology, this distinction is also important because ENTER will activate both types of elements, but SPACEBAR will only activate buttons.

To a screen reader user, this difference in behaviour is semantically important.

Semantics

HTML5 and ARIA provide ways to denote if an interactive element is a button or a link. The role of the element is implicit if the HTML5 element is used, there is no need to include the role=”button” in a <button>.

Regardless of how it is implemented, a screen reader will announce a button as “Button” or a link as “Link”. This means that the user is being told whether this element will behave like a button or behave like a link.

Thus correctly labeling buttons and links is very important to helping users of assistive technologies understand what will happen next.

Visual Design

Visual users, including keyboard-only visual users, are often presented things that look like links but behave like buttons or things that look like buttons but behave like links.

For example, in Figure 1, note that the text refers to a link (“Just use the link below to view our blog:”), but the link is visually a button. Further, the “button” is labeled “View Our Blog”, so it is clearly going somewhere instead of doing something. Figure 2 is is more correct, the visual element is a link.

This visual distinction helps to communicate the semantic distinction. Users will know what to expect from this interactive element.

This visual distinction will also help users when talking about the design, for example:

• When using voice command, the user can tell the software to move to a specific button or link and the element's role is clear to both user and machine.

• In the tech support domain, there could be a communication issue when a screen reader user calls something a button yet the tech support user cannot see any buttons in the visual design presented on the screen.

Fake Links and Buttons

On the rare occasion that a design calls for the use of a custom link or custom button that cannot be based on native HTML5, there are some specific issues that must be addressed in the design.

1. The custom element must be fully keyboard navigable:

• It is in the TAB order and can be focused.

• It can be activated using ENTER and (for buttons) SPACEBAR.

2. Any behaviour that is associated with the mouse must have a keyboard equivalent:

• Hover effects also trigger on keyboard focus.

3. If native HTML5 is not used, appropriate ARIA roles must be assigned:

• If it is intended to be a button, it has role=”button”.

4. Use CSS styling that is visually consistent with other buttons throughout your application.

Resources:

Links, Buttons, Submits, and Divs, Oh Hell

In this section:

• "Read More"
• File Download Links
• Links that open in new window
• Skip links