Lighthouse warns when an anchor tag is just a placeholder

[romainmenke]

FAQ

• Yes, my issue is not about variability or throttling.
• Yes, my issue is not about a specific accessibility audit (file with axe-core instead).

URL

https://www.romainmenke.com/lighthouse-bug-anchors-without-href-attribute/without.html

What happened?

I used an anchor tag without an href attribute and placed an image inside:

<a>
	<img src="https://picsum.photos/200/300" alt="" width="200" height="300" loading="lazy">
</a>

Our actual template code looks much more like :

<a
  {% if link %}
    href="{{ link }}"
  {% endif %}
>
  {# ±200 lines of template code #}
  <img src="https://picsum.photos/200/300" alt="" width="200" height="300" loading="lazy">
  {# ±200 more lines of template code #}
</a>

And then I got this error:

Links are not crawlable

There are a bunch of warnings on that page but only Links are not crawlable is relevant to this issue.

What did you expect?

The HTML specification clearly envisions a dual mode for anchor elements.

Either they have an href attribute, which makes them true anchor elements or they do not, in which case they represent a placeholder.

This concept is also used in CSS for the location pseudo classes : https://drafts.csswg.org/selectors/#the-any-link-pseudo

These only match anchors that do have an href attribute.

---

When templating (server-side) it really helps to be able to wrap a bunch of html with an anchor tag and optionally give it an href attribute only when it needs to be a link.

This makes the variable part in the template much smaller (only 1 attribute).

---

I expect Lighthouse to embrace the relevant specifications and to not give any warnings here.

I also expect Lighthouse to have consistent behavior between anchor tags without href when they contain text vs. when they contain images.

What have you tried?

N/A

How were you running Lighthouse?

Chrome DevTools

Lighthouse Version

latest

Chrome Version

latest

Node Version

N/A

OS

N/A

Relevant log output

N/A

[adamraine]

I expect Lighthouse to embrace the relevant specifications and to not give any warnings here.

Yeah I think we can discuss changing this. Although the link is not crawlable this doesn't appear to be a bad practice that search documentation warns against.

I also expect Lighthouse to have consistent behavior between anchor tags without href when they contain text vs. when they contain images.

Not sure what you are referring to here, what differences did you noticed between anchor tags containing images vs text?

[romainmenke]

I also expect Lighthouse to have consistent behavior between anchor tags without href when they contain text vs. when they contain images.

Not sure what you are referring to here, what differences did you noticed between anchor tags containing images vs text?

This triggers a warning:

<a>
	<img src="https://picsum.photos/200/300" alt="" width="200" height="300" loading="lazy">
</a>

This does not:

<a>
	Hello
</a>

[adamraine]

<a>
	Hello
</a>

The audit fails for me here as well. Not noticing any difference between images/text.

[romainmenke]

You are right!

I was testing with an anchor element that also had an id attribute.
My assumption that it had to do with image/text content was incorrect.

[romainmenke]

Thank you for updating the title.
I've also crossed out the incorrect statement in the initial report and updated the html content of the example page

This better reflects the issue.

[connorjclark]

relevant spec

If the a element has an href attribute, then it represents a hyperlink (a hypertext anchor) labeled by its contents.

If the a element has no href attribute, then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant, consisting of just the element's contents.

The target, download, ping, rel, hreflang, type, and referrerpolicy attributes must be omitted if the href attribute is not present.

If the itemprop attribute is specified on an a element, then the href attribute must also be specified.

Agreed we should not flag <a> as an uncrawlable link based on the spec.

We should still call it out if it has any of these must-not-be-present attributes when href is missing.

Thanks for bringing this to us!