Using the link role

This article explains how to use the link role and describes the effect it has on browsers and assistive technology.

The link role is used to identify an element that creates a hyperlink to a resource that is in the application or external. When this role is added to an element, tab can be used to change focus to the link, and enter used to execute the link.

Note: Where possible, it is recommended that you use a native <a> element rather than the link role, as native elements are more widely supported by older user agents and assistive technology. Native <a> elements also support keyboard and focus requirements by default, without need for additional customization.

The tabindex attribute may optionally be used with this role to directly specify the position of the element in the tab order.

Possible effects on user agents and assistive technology 

When the link role is added to an element, or when such an element becomes visible, the user agent should do the following:

  • Expose the element as having a link role in the operating system's accessibility API.
  • Fire an accessible link event using the operating system's accessibility API if it supports it.

Assistive technology products should listen for such an event and notify the user accordingly:

  • Screen readers should announce the text of a link — or the link's label — when the link is focused. A screen reader should also identify the link as a link. ARIA links should be included in the screen reader's List Links function with ordinary links. Actions in the screen reader's dialog list (such as Activate Link or Move to Link) should perform the same as ordinary links.
  • Screen magnifiers may enlarge links.

Note: Opinions may differ on how assistive technology should handle this technique. The information provided above is one of those opinions and therefore not normative.


This example shows how to implement a fake link using a <span> element. This includes JavaScript to grab the location and handle navigating to the new location using via clicking, and using keyboard, CSS to give the desired visuals of a link, the tabindex="0" attribute to make it keyboard-focussable, and role="link" to make it recognized as a link by assistive technology.

This is a lot of work just to recreate something you get for free using the <a> element, so use that if possible. But this shows that it can be done.

However, there are still problems with this approach:

  • It is difficult to detect whether the target of the fake link has been visited before, and therefore use :visited styles (e.g. the default purple color for visited links).
  • Opening a page using the open() method counts as being a popup, and certain browsers may issue a warning when you try to activate it, or make you explicitly agree to allowing popups form for the domain.


<h1>role="link" example</h1>

<span data-href="" tabindex="0" id="link1" role="link" class="link">
  Fake accessible link created using a span

<p><a href="" target="_blank">Actual real link</a></p>


span[role="link"] {
  color: blue;
  text-decoration: underline;
  cursor: pointer;

span[role="link"]:focus {
  outline: 1px dotted black;


const spanElem = document.querySelector('span');

//handles clicks and keydowns on the link
function navigateLink(e) {
    if (e.type === 'click' || e.key === 'Enter') {
        let ref = != null ? : e.srcElement;
        if (ref) {
'data-href'), '_blank');

spanElem.addEventListener('click', navigateLink);
spanElem.addEventListener('keydown', navigateLink);



If pressing the link triggers an action but does not change browser focus or navigate to a new page, you might wish to consider using the button role instead of the link role.

ARIA attributes used

Additional resources