The Web Content Accessibility Guidelines (WCAG) are being updated again, only 3 years after 2.1 was published. Using the new requirements from version 2.2, Alastair walks through the new guidelines, and provides advice on how to use them in your organisation.
With HTML alone there is no way to disable a hyperlink (an
<a href>element), and have it be both exposed as a "link" and as "disabled". Now, setting aside whether or not disabling a link is even a good idea (opinion: it's probably not), that hasn't stopped people from
needingto do it.
[...] You might have to "disable" a link for reasons. So how should this be handled in a way that will not result in a quirky user experience (rather, the least quirky experience possible when disabling a link), or an unnecessary amount of work for you.
[...] As mentioned, HTML does not allow for a hyperlink to be disabled. However, the ARIA specification's
linkrole does allow for the role to be set to the disabled state. This is one of those instances where the allowances of HTML and ARIA are not in sync. There are often good, if not at least understandable reasons for such instances of misalignment. But more on that another day.
Back to our placeholder link:<a>Learn something!</a>
It has been correctly stripped of its hyperlink functionality, and
linkrole, by removing the
href. But, we need to make sure that:
- it is not inconsistently announced as "clickable"
- it is exposed as a "link"
- and it is exposed in the "disabled" state
We can take care of the first two bullet points by specifying
<a>element.<a role="link">Learn something!</a>
You might look at this and think "but aren't we not supposed to use a
roleon an element that already exposes that role? Won't [ automated checker ] yell at me?"
Generally, yes. It is not recommended to specify an explicit role that matches an element's implicit ARIA role. However, in this case it's fine because
<a href>has an implicit "link" role, but
hrefdoes not. If an automated checker does yell at you for
<a role=link>...</a>then that's a bug with that tool.
role=linkoverwrites placeholder link's implicit
genericrole. Which also stops the AT that were trying to manage potential author errors from producing the "clickable" announcement. Now we have a "link" that has no functionality, and cannot be keyboard focused. Time to communicate that:<a role="link" aria-disabled="true">Learn something!</a>
Where it is not recommended to use the
aria-disabledattribute on an
<a href>element, it's perfectly fine to use this attribute on a
role=link. This element will now be exposed with a "link" role, and it will announce itself as "disabled"/"dimmed". And since there is no
href, it will not be inherently interactive or even result in a context menu with link-related menu items, when right clicked.
And there you have it. A "disabled link".
Use wisely, carefully, and hopefully rarely.
Digital accessibility is the inclusive practice of ensuring that everyone has equal access to information, functionality, and experience on digital platforms.
Many accessibility guides out there are either too prescriptive (making it seem like a checklist), too aspirational (painting a utopian picture that doesn't drive action), or too charity-driven (driving the point that people with disabilities are to be pitied).
This handbook is a little different.
We at the UX Collective have partnered with our most prolific accessibility writer, Sheri Byrne-Haber, CPACC, to bring a more candid take on the topic. [...]