Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Links do not have descriptive text" audit #4494

Open
fchristant opened this issue Feb 9, 2018 · 26 comments
Open

"Links do not have descriptive text" audit #4494

fchristant opened this issue Feb 9, 2018 · 26 comments

Comments

@fchristant
Copy link

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
Copy link
Collaborator

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
Copy link
Member

rviscomi commented Feb 9, 2018

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

const BLOCKLIST = new Set([
'click here',
'click this',
'go',
'here',
'this',
'start',
'right here',
'more',
'learn more',
]);

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

@fchristant
Copy link
Author

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
Copy link
Member

rviscomi commented Feb 9, 2018

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
Copy link
Author

@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
Copy link
Contributor

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
Copy link
Author

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

@marcysutton
Copy link

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
Copy link

cjnaude commented May 10, 2018

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

@robdodson
Copy link
Contributor

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

@paulirish
Copy link
Member

#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
Copy link
Author

@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
Copy link
Contributor

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
Copy link
Member

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
Copy link

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

@robdodson
Copy link
Contributor

@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
Copy link

erunyon commented May 26, 2022

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
Copy link

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
Copy link
Collaborator

connorjclark commented Jun 9, 2022

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.

@robdodson robdodson removed their assignment Jun 13, 2022
@LanguageXange
Copy link

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
Copy link
Contributor

robdodson commented Apr 24, 2023

@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
Copy link

LanguageXange commented Apr 25, 2023

@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
Copy link

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

@robdodson
Copy link
Contributor

@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: #4494 (comment)

@mjanulaitis
Copy link

Ok thanks that makes sense.

@elucidsoft
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

16 participants