Partial links are inaccessible

Tyler — Sat, 03 Oct 2020 17:32:45 +0000

Navigating through any website, you’re bound to find partial links. I consider partial links to be links which do not contain enough text content to make them discernible from other links.

A quick example of a partial link would be the following:

<p><a href="/abt">here</a></p>

In the example above, you wouldn’t be able to tell where the link would direct you to, as there’s no “proper” context describing it, nor is there enough text content. For some, there’s usually context before or after the link, so that they can make a informed decision of clicking that link or not:

<p>See more on our about page <a href="/about">here</a>!</p>
<!-- The link does not describe its purpose itself -->

While that may be okay for some, a user who uses some form of assistive technology may not be able to get to that context preceding the link in the example.

This is because some users may navigate a page through links. Maybe they’re trying to find a link that they’ve been to before, or some other scenario. When using a screen reader, you can navigate between landmarks, form elements, links, etc. When navigating through links, the example above would be listed as "here", without the context that precedes it.

Example of the "Links" view in NVDA Screen Reader Elements List.

This is also listed as "success criteria" for WCAG 2.1, that criteria being Link Purpose 2.4.9 (Link Only) and/or Link Purpose 2.4.4 (In Context).

It’s also good to note that you do not have to be super specific when creating text content for a link. It’s better to give that link a short amount of context to describe it as well as text content, so that an AT user, (or any user) can perceive that link quicker.

How to make it accessible

Here’s a few things we can do to ensure that we’re making a link accessible by its text content.

Ensure that the link text describes its purpose For example, if your link contains “here”, or “read”, or even “click me!”, then it doesn’t describe the purpose of the link; what exactly am I clicking? Ensure that the link describes where it will take the user, an example of short and efficient text content being: “About us”, “More information on our product”, “Our values”.
Ensure that the link has a proper accessible name Some links are inaccessible because they don’t contain any accessible text at all. An example being, if your link contains only an image without a descriptive alt text, or text alternative, then a user using assistive technology may not be able to figure out where that link will take them.
Make sure it isn't too verbose It's easy to give a link too much text content. Giving links short text content which describes the link fully enough so that any user can determine where it will take them is key.

In most cases, partial links are caused by only factoring the visual aspect of that link. For example, if you only give the text content "here", you’re assuming that the user is going through the navigational flow in order to receive the context for it. Though, this is disregarding the fact that users may navigate through links, missing out on that additional context.

Giving links better text content helps us all, as some users may be able to better distinguish between that link and others visually, as well as via using AT.

When role="button" is not enough

Tyler — Fri, 18 Sep 2020 00:41:30 +0000

Whenever I find a website that I particularly like, I open up my browser’s devtools to get an idea on how it was built. Needless to say, I do this quite a lot. In some cases, I solely look at the code to get an idea of how accessible a website truly is. One thing that always stands out like a sore thumb is an element with a improper role attribute.

For this post I will talk about role="button", how it may be misused and how to make it accessible.

Developers tend to use role="button" to turn an element into a "button". This is to indicate to AT users, that the element with the attribute role="button" is indeed a button. In many cases this is not enough to make that element accessible.

Before I begin, I would like to say that in all cases, utilizing a regular <button> element is preferred over role="button". You should only utilize the role in events where you cannot use a native button element.

What is not enough?

When utilizing role="button", you need to ensure that the element is tabbable, though that is only if the element isn’t already natively tabbable. For example, an anchor element <a> is natively tabbable if there is a valid href attribute attached.

Imagine the following scenario, where a user needs to utilize the search button, but it’s a div:

<!-- Toggles search input on/off -->

<div onclick="openSesame">Search</div>

<!-- This is not at all accessible! -->

In the example above, the element is not accessible.

Perhaps there’s some sort of constraint where you can’t turn an element into a native button. That’s where role="button" comes in:

<!-- role attribute takes value as a string -->

<div role="button" onclick="openSesame">Search</div>

<!-- is now a "button" in the accessibility tree -->

Though we are close, this is still not accessible. An AT user cannot tab, nor focus onto the element, as there is no tabindex. We can fix that by adding a tabindex with the value of "0":

<!-- tabindex="0" means element is in sequential focus navigation of the page -->
<div role="button" tabindex="0" onclick="openSesame">Search</div>

It might not be a surprise to hear me say that this still isn’t enough. In some cases, an AT user may now be able to focus and trigger this button, whereas some will still not be able to.

Some screen readers simulate a "click" when enter is pressed instead of a keydown event. That means that in the above example, the "onclick" event would actually trigger for some AT. Though for most, it still isn't accessible. This isn't a topic I will dwell on in this post, but this is always good to keep note of.

In a good majority of cases where I see elements which have role="button", two out of three criteria are met. One being role="button" and second having a tabindex, although they often fall short of having an actual keydown event attached.

There are also cases where the element which has role="button" is a natively tabbable element, like an anchor element <a> (if a valid href is attached). In this case, using the "enter" key does work, yet you can’t activate an anchor element with the space key, whereas with a <button> element, both "space" and "enter" would trigger it.

How to make it accessible

Making an accessible button when a native button cannot be used is pretty simple. This is how:

Step 1: Add the role

<!-- Add role="button" to the elem -->

<div role="button">Hello, I'm now a button!</div>

Adding role="button" will ensure that 'button' is announced to an AT user. Without that role, an AT user may be confused about what type of element it is. With the role added, it'll be listed as a "button" in the accessibility tree.

Step 2: Add a tabindex

<div role="button" tabindex="0">Hello, I’m a button!</div>

A tabindex ensures that the element is tabbable so that a user may focus onto it. It's generally not advisable to set a tabindex value greater than 0. Here's a good post on why you shouldn't set a positive tabindex. Do note that a negative tabindex such as -1 will remove that element from tab order, while allowing you to programmatically set focus to that element.

Step 3: Add a keydown event

document.querySelector('div[role="button"]').addEventListener('keydown', function(e) {
  const keyD = e.key !== undefined ? e.key : e.keyCode;
  // e.key && e.keycode have mixed support - keycode is deprecated but support is greater than e.key
  // I tested within IE11, Firefox, Chrome, Edge (latest) & all had good support for e.key

    if ( (keyD === 'Enter' || keyD === 13) || (['Spacebar', ' '].indexOf(keyD) >= 0 || keyD === 32)) {
    // In IE11 and lower, e.key will equal "Spacebar" instead of ' '

    // Default behavior is prevented to prevent the page to scroll when "space" is pressed
    e.preventDefault();
    this.click();
  }
});

Adding a proper keydown event should ensure that the element triggers the click event (if one is attached). There are many ways to implement a keydown event, however I'd use whatever is suitable for your situation.

Step 4: Test it

You should always manually test something, especially for a11y purposes. Perhaps something is blocking the keydown event, or maybe focus isn’t styled properly on the element. You won’t know until you test it out! For this, you can utilize your keyboard to try to "trigger" the element.

I'd also suggest trying out a screen reader. I'd highly recommend NVDA, which is a free open source screen reader. You may already have a screen reader pre-installed too!

If you're a macOS user, you should have access to VoiceOver, which is a very easy to use screen reader. VoiceOver comes pre-installed with most Mac systems.

If you're a windows user you should have Narrator installed, which is a screen reader made by Microsoft.

Common gotchas

Anchor elements and role="button" It’s easy to add a role to an element without realizing that more needs to be added to make it fully functional. I often see anchor elements <a> with role="button" attached. This is perfectly fine, but I often see a step missing with ensuring true accessibility of that element. An anchor element only triggers with the "enter" key, whereas a native button element will trigger by both "enter" and "space". To ensure an anchor element with a role of button is accessible, add a separate keydown for the "space" key. This keydown event should trigger the same event that a click, or pressing the “enter” key would.
Styles and role="button" When utilizing role="button", sometimes it’s good to style that element as an actual button would appear. This isn’t exactly a requirement, but it'll ensure that users are able to recognize it as a button.
Not having the same click and keydown event A keydown event should trigger the same event as the click event. You should also ensure that a click event is attached and that the element utilizing role="button" should function the same way for click, "enter" or "space".

ARIA attributes

There are a few ARIA attributes you can utilize to make role="button" even more accessible.

aria-pressed Attribute aria-pressed can have the values "true", "false" or "mixed". Utilizing this attribute means that you can make a "toggle" button, which indicates the state of the button. When the value is "true", it means that the button is currently pressed and when the value is "false", it means that the button is not currently pressed. The "mixed" value means that the values of more than one item controlled by the button do not all share the same value. I personally haven't seen aria-pressed="mixed" being used before, and I have not used it myself. Here's a bit more information about aria-pressed from the specification.
aria-expanded You may utilize aria-expanded to notify the user that the element, or element it controls is either expanded or collapsed. This is generally used when making accordions, where the content is initially hidden and only expanded when activating the trigger. The values supported by aria-expanded are "true" or "false". You can learn more from the specification.

DEV Community: Tyler

Partial links are inaccessible

How to make it accessible

Further Reading

When role="button" is not enough

What is not enough?

How to make it accessible

Step 1: Add the role

Step 2: Add a tabindex

Step 3: Add a keydown event

Step 4: Test it

Common gotchas

ARIA attributes

Further Reading