« Back to home

Testing links

This page pairs with the "Highlight links" bookmarklet, which scans every link on the page and badges it based on its accessible name, its title attribute, and where its href actually points.

Example 1: unique accessible name

A link with its own accessible name, pointing to its own destination, nothing shared with any other link on the page.

Expected result: this link's accessible name is unique across the whole page, and it points to its own destination. Nothing here should trigger any warning from the bookmarklet.

<a href="https://example.com/pricing">View pricing</a>

Example 2: same accessible name, same URL

Two links, identical accessible name, identical destination.

Expected result: both links share the exact same accessible name and resolve to the exact same destination. This is a common, generally fine pattern, the same policy linked from two places doesn't confuse anyone, since both take you to the same place. The bookmarklet should badge both green.

<a href="https://example.com/shipping-policy">Shipping policy</a>
...
<a href="https://example.com/shipping-policy">Shipping policy</a>

Example 3: same accessible name, different URL

Two links, identical accessible name, different destinations.

Expected result: both links share the exact same accessible name, "see product details", but resolve to two different destinations. A screen reader user navigating by a list of links, or anyone relying on the link text alone, has no way to tell these apart before activating one. The bookmarklet should badge both red.

<a href="https://example.com/product-a">Product details</a>
...
<a href="https://example.com/product-b">Product details</a>

Example 4: accessible name + matching title

The title attribute duplicates the link's own visible, accessible text exactly.

Expected result: the accessible name already comes from the link text, "Download the annual report", the identical title adds nothing new. Some screen reader/browser combinations will still announce the title as a tooltip readout on top of the accessible name, meaning the same text may be spoken twice. Worth confirming directly whether your standard AT/browser combinations actually double up here, behaviour varies.

<a href="https://example.com/report"
  title="Download the annual report">Download the annual report</a>

Example 5: accessible name + mismatching title

The title attribute says something different from the link's own visible, accessible text.

Expected result: the accessible name still comes from the visible link text, "View account settings", per the accessible name computation, title only becomes the name when no other name source exists, so it doesn't overwrite it here. Instead it typically becomes the accessible description, and some AT will read both the name and this differing description back to back, two different, unrelated pieces of text for one link. Confirm directly what your standard combinations actually do.

<a href="https://example.com/account/settings"
  title="Opens in a new section">View account settings</a>

Example 6: no accessible name, but has a title

An icon-only link, no visible text, no aria-label, no aria-labelledby, and the icon itself is hidden from the accessibility tree. The title attribute is the only thing left to supply a name.

Expected result: with nothing else to draw from, the accessible name computation falls back to title, so screen reader users hear "Open live chat". Sighted users get no text at all, only an icon shape to interpret. This is the reverse of the usual discoverability problem, the name is presented to screen reader users, but not to sighted users.

<a title="Open live chat">
  <svg aria-hidden="true">...</svg>
</a>

Example 7: empty href

href="" is present, but empty.

Expected result: an empty href resolves to the current page's own URL, so activating it doesn't error, it just reloads the page. It still counts as broken, there's no genuine destination, and depending on the page, form state, scroll position, unsaved input, reloading may not be harmless either. The bookmarklet should badge this red even though it technically resolves.

<a href="">Continue to checkout</a>

Example 8: no href at all

No href attribute whatsoever.

Expected result: without an href, this isn't interactive content per the HTML spec, it's not part of the tab order, it has no default keyboard interaction, and browsers don't treat it as a hyperlink at all. Anyone expecting an <a> element to always behave like a link will be caught out here. The bookmarklet should badge this red.

<a>Terms and conditions</a> <!-- no href -->

« Back to home