In our post on WCAG 2.4.4 Link Purpose (In Context), we discussed why it’s important that users be able to figure out the purpose of a link appearing on your site. Either from the text of the link itself, or additionally from the context of where it appears on your page, users should be capable of figuring out where a link would lead so that they can properly decide whether they want to access it. That’s because sighted users can often determine a link’s purpose from visual clues in a way that those relying on assistive technologies can’t replicate.
WCAG 2.4.4 described the level A standard for this principle. In this article, we’ll talk about the AAA standard. Basically, the standards here in 2.4.9 are more stringent than WCAG 2.4.4. In the following sections, we’ll focus on the key differences and similarities between WCAG 2.4.4 and 2.4.9 so you can get a sense of what’s involved.
In WCAG 2.4.4, you can use the context surrounding a link to help users identify the link’s purpose. This means that a paragraph of text will contain contextual cues that imply the purpose or destination of a link embedded within that paragraph. The main difference in WCAG 2.4.9 is that you can no longer use this context as an indication for users.
Those using assistive technologies can often get a list of all the links appearing on a given page without having to tab through all of the page’s content, since they may not have the option of visually picking out where the links are on a page, as sighted users do. For this reason, WCAG 2.4.9 asks that a link’s purpose be identifiable from just the text of the link.
As you put your site together, you may find it rather cumbersome or awkward to implement this rule. Let’s say, for instance, that a page on your site discusses the novel Moby Dick, and you wish to provide users with links to the book in various formats (HTML, PDF, MP3 audiobook). While it would be beneficial to users relying on assistive technologies to write out the text for each link as “Moby Dick in HTML” or “Moby Dick in MP3”, it might seem confusing and repetitive to other users to see the book’s title appear over and over again like this.
Accordingly, this rule stipulates that you can provide a “mechanism” allowing users to perceive the full, descriptive link text, meaning you can have a default setting that is more natural or presentable and then provide a means whereby users can access the full link text. Going back to our Moby Dick example, let’s say users landing on your page by default see the rendered text for each link as merely the format type (“HTML,” “PDF,” “MP3”). However, using scripts or CSS, you then provide users with the option of expanding each link in order to see additional text that includes sufficiently descriptive information (“Moby Dick in HTML”). You could also include an icon along with the abbreviated text as part of the same link and provide the expanded description in the icon’s alt-text.
As with WCAG 2.4.4, if a link’s purpose is intentionally ambiguous, or if it would be equally unclear to users not relying on assistive technologies, then you don’t need to worry about providing descriptive link text, since the lack of information wouldn’t put anyone in particular at a disadvantage.