Skip to content

Accessibility: WCAG 2.2's new guidelines, disabling a link, etc.

  • 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 needing wanting to 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 link role 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 link role, 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 role=link on the <a> element.

    <a role="link">Learn something!</a>

    You might look at this and think "but aren't we not supposed to use a role on 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 <a> without href does not. If an automated checker does yell at you for <a role=link>...</a> then that's a bug with that tool.

    Specifying the role=link overwrites placeholder link's implicit generic role. 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-disabled attribute 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. [...]