Duplicate links are not a WCAG violation
Accessibility testing tools such as WebAIM’s WAVE would sometimes flag duplicate links either as errors or alerts. I have also seen my students mark them as errors in their accessibility reports. At one of the companies I was an accessibility consultant at, the testing team would mark them as an accessibility violation as well.
But duplicate links aren’t a WCAG violation. The WCAG only has an issue with duplication if you use a graphic link and you add a redundant ALT to the graphic. In Combining adjacent image and text links for the same resource, it is said that you should add a null ALT for images inside links that are just for decoration, like this:
<a href="products.html"> <img src="icon.gif" alt=""> Products page </a>
Example taken from the WCAG
It is mentioned nowhere in the WCAG that all links should be unique. In fact, WCAG’s Multiple Ways Guideline advises you to provide multiple ways for users to access content, for example, by providing a site map. The site map is usually a sub-page of the site, so you’d have instances where the user would open the site map and it will list all links on the site, including those on the same page, like the header or the footer ones.
A site map as an internal page will definitely contain duplicate links, which is okay.
I know what you are thinking, “Stefany, a lot of accessibility best practices aren’t in the WCAG”. True, but this one isn’t very important. Duplicate links might slow down the user’s navigation via the keyboard a little bit, and if they browse the web pages with a screen reader, the only inconvenience would be a cluttered element list.
One of the reasons duplicate links are flagged is because they can clutter a screen reader’s element list, which can be annoying
And I know that duplicate links provide a slightly worse user experience, but you can’t have it all. I have seen developers going to extremes just to avoid being flagged, even resorting to anti-patterns like this:
<a href="example.com" role="presentation" aria-hidden="true">Read More</a>
aria-hidden=”true” to an interactive element is discouraged by the WAI-ARIA spec (WCAG’s sister). While it might hide the element from being focused by some screen readers, the majority of them would still focus the element but omit the name. Not to mention it is still focusable by a keyboard, unless you add
tabindex=”-1” which is another anti-pattern when it comes to interactive elements. Right now, on Windows Narrator and NVDA in Scan / Browse Mode, the interactive element is still very much focusable and both screen readers either announce “blank” or “link, blank”. Now that’s terrible user experience and a violation of the WCAG. Is it worth it? Absolutely not.
In patterns such as cards, blog post excerpts and product listings, you can apply some fixes:
- Change one of the links to a non-interactive element such as a
divand attach a click handler with JS that would redirect the user once it is clicked.
- Add the same text for the same links, although it is not necessary for the text to be visually identical, for example, for a “Read More” link, you can add an
aria-labelthat is the same as the heading of the blog post.
- You can also eliminate the duplicate links altogether, but you run into the issue of users clicking the product image and the heading of the blog post and being frustrated when they are not redirected.
Don’t get me wrong, you should try to have as few duplicate links as possible. But it is not the end of the world and they won’t make your website inaccessible. If you are an auditor and you stumble upon such links, you can mark them as a “Low” severity in your accessibility report and provide recommendations for remediation. But don’t worry too much about them.