Using the link role

This technique demonstrates 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 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 the link or its label when it is focused, along with the fact that it is a link. ARIA links should be included in the screen reader's “List Links” function just like ordinary links, and actions in this dialogue list, such as “Activate Link” or “Move to Link”, should perform the same as they do with 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 huge amount of work just to recreate something you've get for free using the <a> element, so you should really use that if possible. But this shows that it can be done.

You should however note that there are still problems with this approach:

  • It is very 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 the domain it exists on.


<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