Links

COMPONENT GUIDE

Explore behaviors before defining the interface.

Quick guide for designers

Always consider the context of the application, even when the guidance follows a standard pattern. Interaction design documents intent. Behavior must be verified in the implementation.

When to use

Use to navigate to a page, resource, or content section.

What to draw

Show text that explains the destination and interaction states with visible focus.

How it behaves

Click or Enter opens the destination. Content changes need to be perceptible.

What to document in Figma

Record the destination and indicate whether it opens on the same page or in another tab or window.

How to review

Check whether the purpose and states are clear on small and large screens and with zoom. Verify documented behavior in the implementation, including keyboard and screen reader use where applicable.

Full guidance

Interaction Design

Questions to ask when designing interactive components of type Link.

Important:
Depending on the context in which you build your components, there may be further questions, and some listed here may not be necessary. Assess each case individually.

Designing for "no interaction"

Before interacting, can you visually tell that the component is actionable?
Before interacting, can you anticipate the destination after activation, whether internal or external?

Designing for mouse use (any pointing device)

Is there visual feedback when hovering over the component?
Is there visual feedback when clicking the component?
Does clicking the component trigger its corresponding action?

Designing for gesture use

Is there visual feedback when activating the component?
Does activating the component trigger its corresponding action?

Designing for keyboard use (any non-pointing device)

Is there visual feedback when focusing the component?
Can you interact with the link using the "enter"?
When activated by keyboard, does the link take the person to its corresponding content?

Designing for screen reader use

When focusing a link, can you hear that it really is a link rather than a button?
When focusing a link, can you clearly hear its purpose?
When focusing a link, can you hear whether the destination is internal, on the same screen, or external?
When a page displays multiple links, can you clearly identify each link's purpose without ambiguity?

Interaction methods

Possible interaction methods for components of type Link.

Important:
Only the main methods are listed here. Custom components require further study.

Mouse interaction (any pointing device)

On hover, the component should provide visual feedback confirming that interaction is possible.
On a mouse click, the component should provide visual feedback confirming the click.
On a mouse click, the content should load.

Keyboard interaction (any non-pointing device)

When focused with the keyboard, the component should provide visual feedback with a visible focus indicator.
It should be possible to activate links with the ENTER.

Keyboard (or gesture) interaction + screen reader

When focusing a link, you can hear that it is a link.
When focusing a link, you should be able to clearly identify its purpose.
On screens with multiple links, you should be able to clearly identify each one's purpose.
After pressing the "enter" key, you can identify that other content has loaded on the screen.

Gherkin

BDD (Behavior-Driven Development) methodology focusing on three pillars: User Stories, Acceptance Criteria, and Gherkin Syntax (Given, When, Then).

Scenario: Given that I am on a page containing links

Keyboard navigation

WHEN I use the Tab key to move focus to a link
The focus I SEE is strongly indicated visually
THEN, when I use the Enter to activate the link
I SEE the browser load the destination associated with the link

Desktop screen reader

When I use a screen reader on a computer (NVDA, JAWS, VoiceOver) and use the Tab key to move focus to a link
- I HEAR that the component is identified as a link.
- I HEAR an accessible name clearly describing the link's destination or purpose.
- I HEAR additional information when the link opens in a new window or leads to an external destination.
THEN, when I use the Enter to activate the link
I HEAR or perceive that the browser is navigating elsewhere or loading other content.

Mobile screen reader

WHEN I use a screen reader on a phone (TalkBack, VoiceOver) and swipe to focus a link, the following happens:
- I HEAR that the component is identified as a link.
- I HEAR an accessible name clearly describing the link's destination or purpose.
- I HEAR additional information when the link opens in a new window or leads to an external destination.
THEN, when I double-tap to activate the link
I HEAR or perceive that the browser is navigating elsewhere or loading other content.

Considerations

Considerations for components of type Link

Links should behave as links rather than buttons.
Links may look like buttons, but if they take a person elsewhere to more content, that is link behavior and they should be implemented as links.
Links can be used in different contexts. Choosing the right context greatly improves the chances of people understanding the component.

References

Additional references for components of type Link.

Important:
Most references are on the course platform alongside the lessons cited in this material.

Disclaimer:
The links listed here are a curated collection of references where you can find implemented components, rather than recommendations. There is no unified implementation format and no guarantee that these links follow every design pattern. Direct questions to the teams responsible for the linked materials. Before copying a model, remember that all materials are constantly updated and that patterns, particularly proprietary ones, may change.