"Links do not have descriptive text" audit

[fchristant]

I have a question about the audit in the title. Say you'd have a pagination component which is just a list of links with numbers.

The descriptive text for such links are obviously short. Yet they are descriptive within the context of the component, being pagination.

How would one pass the audit for such links? Visually there's no room to make it descriptive. "Go to page 4", "Go to page 5" would make for a seriously bad pagination component if that was to be used for link text.

Should this be solved using the title attribute or an aria attribute? Or should I just ignore this part of the audit altogether?

[patrickhulce]

Good question, @robdodson @rviscomi any guidance here for best practices on pagination links? :)

AFAICT, the audit shouldn't be flagging links that have distinct numbers, but more along the lines of text like "click here" and "more"

[rviscomi]

@patrickhulce that's correct. The link text that will trigger this audit are:

https://github.com/GoogleChrome/lighthouse/blob/3e34af7c722e0a4dc9d1e46c1fac908b0ebde69b/lighthouse-core/audits/seo/link-text.js#L10-L20

@fchristant if you're seeing unexpected results, could you share the URL of the page in question?

[fchristant]

Sorry, it looks like I did not look close enough to the source of the problem. It's not the page numbers triggering the failed audit, it's the middle button of the pagination component which is indeed labelled "more".

Seems like a normal label btw for a pagination component, not sure how else to label it :)

[rviscomi]

For links not meant to be followed/indexed, perhaps we should ignore links with rel="nofollow".

I also wonder if Lighthouse could have a feature similar to Chrome's "Add to Dictionary" feature for misspelled words, where it can whitelist particular audit failures so their scores are not penalized for false positives. This would be a good signal for us to revisit an audit's calibration. Or more generally speaking, a one-click way to signal that "something's not right here" and we can look at aggregate data to figure out what might be going wrong. @paulirish WDYT?

[fchristant]

@rviscomi +10 for that idea. I've come across multiple examples where I found the audit a false positive or not relevant within the context given. The above is one. Another is extensions affecting outcomes. And yet another is the new text size audit (why is that even a SEO audit btw) which lists > 90% of text illegible on pretty much any website.

Equally happy to just report individual issues. I love Lighthouse, that's why I report so much :)

[robdodson]

To offer a bit more input from the accessibility side...

Often folks relying on a screen reader will open a special menu that lists all the headings on the page, or all of the form controls. One of the options is to list all of the links. It's not uncommon to end up with a list of:

Read more
Read more
Read more
...

These are all out of context and not super useful.

Also, keep in mind that the 'more' button may have visual context, but depending on how the page is structured, a screen reader user might not be able to tell how far they have traveled away from a particular component.

Having said that, I think the pagination use case you're describing is pretty reasonable. @marcysutton do you have an opinion here? Would a better alternative be "Next" / "Previous" maybe?

[fchristant]

@robdodson Would any specific ARIA attribute help in enriching short link texts? By the way, are the current stop words for english only?

[marcysutton]

Would a better alternative be "Next" / "Previous" maybe?

For pagination this would work nicely, with the caveat that there can only be one pagination set per page with the same labels. If you had multiple pagination sets, they'd have to be uniquely labeled, otherwise a screen reader user would encounter them and wonder "next what?".

You could use aria-label for this, or a visually hidden span. The title attribute isn't consistently exposed as an accessible name (and is mostly helpful to mouse users).

[cjnaude]

I find it strange that my "Learn More" link triggered this warning, yet most links in the audit descriptions are "Learn More".

[robdodson]

@cjnaude I agree. I want to fix this in the lighthouse report.

[paulirish]

#5349 captures the topic of the lighthouse audit descriptions using "learn more"

what's left for this one? that a link of [More] gets flagged, but kinda makes sense in a navigation component?

[fchristant]

@paulirish Yes, and I can think of a few more examples based on the term list:

• Go -> very common label for a search link
• Start -> common label for a multi-step wizard-like UI
• More -> common for pagination but also for toggling more text in a truncated paragraph

In all these examples, they are visually common or even expected labels, which is why I find the audit too opinionated as it doesn't take context into account. Which is why I'd find it more fair to do the audit on the semantic, non-visual level (title, aria labels and such).

[robdodson]

Wanted to mention that in web.dev we regex for the phrase 'Learn More' to get the link for a LH audit. So this is now load-bearing text 😸. I think we'd need to come up with a way in the LH json to represent the link (or links?) so we can read that info in the web.dev audit table.

[paulirish]

replying to @fchristant...

"Go", "Start" as labels should only be used in buttons, not links. So I don't think those are "valid" as link text.

"More" ... yeah.. I'm convinced that its appropriate for pagination and truncation. It is also often used poorly, so we'd have false positives and false negatives if we included it. :(

That bikeshedding aside.. I do really like the idea of using the a11y tree instead of just plain anchor element textContent. That'd be a much better way to evaluate the page.

[rickvian]

what if i use href for icons, like social media icon

[robdodson]

@rickvian depending on how you're loading the icon you would want to either provide alt text on the image inside of the link:

<a href="https://twitter.com"><img alt="Twitter" src="twitter.png"></a>

Or if you're using an icon font you'd want to do an aria-label

<i data-icon="twitter" aria-label="Twitter">

[erunyon]

Related issue, we often use "Learn more" as the link text, but also include an aria-label such as aria-label="Learn more about commencement 2020.", but it still gets flagged as "Links do not have descriptive text" under "SEO", but no such flags under "Accessibility".

[simonkuran]

Related issue, we often use "Learn more" as the link text, but also include an aria-label such as aria-label="Learn more about commencement 2020.", but it still gets flagged as "Links do not have descriptive text" under "SEO", but no such flags under "Accessibility".

I'd really like to be able to do this and not get dinged by Google Lighthouse. Seems like a straightforward and accessible solution.

[connorjclark]

This audit, being in the SEO category, is about seo. But it is also about a11y, to an extent.

Re: using aria-label:

1. for seo, there is no indication that this attribute is utilized by search indexers. We can ask around, but this must be noted. EDIT: at least a year ago, the answer was no.
2. for a11y, having a label is good for screen readers, but what about sighted users?

Whether we want this audit to have a11y concerns or not is a valid question, given it is in the SEO category.

[LanguageXange]

Same here, get flagged for "Links do not have descriptive text" because I used the word "start" for my links.

I have a course page with a curriculum section using lots of links to the corresponding course lecture URL but I really want to keep the link text nice and short.

should I change the text to "start now" ( since this is not in the block list ) ? OR Is there a better way to get away with this ?

[robdodson]

@LanguageXange Would something like this work?

.sr-only {
  clip: rect(0 0 0 0); 
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap; 
  width: 1px;
}

<a href="...">Start <span class="sr-only">lesson 01</span></a>

The .sr-only class stands for "screen reader only". It visually hides text content, but still makes it available to a screen reader.

[LanguageXange]

@robdodson
I ended up changing the text from 'start' to 'begin' and then got 100 score 😂.

but I love this way of hiding element with clip-path. Thank you for the suggestion ! I learn something new 😍

[mjanulaitis]

I tried changing Learn More to Read More but got the same flagged results :(

[robdodson]

@mjanulaitis In both cases "Learn More" and "Read More" provide a bad experience for folks using a screen reader (they'll just hear a long list saying "Read More"). I think the best approach is to tuck some additional, hidden text into the links, like in this comment: https://github.com/GoogleChrome/lighthouse/issues/4494#issuecomment-1520343450

[mjanulaitis]

Ok thanks that makes sense.

[elucidsoft]

I found the best way to fix this is to add a span inside, and make it hidden. It still gets picked up by SEO, and you don't get flagged for it.