Use a screen reader. Tab through the links. All you hear is, "click here." That's not helpful.

Build a search engine. What information does "click here" offer your index?

I agree with you that verbs don't seem all that problematic. Except when the verb is click and the object is here. I can stomach a link whose text is "Click Here to download Amaya," but if the link is literally just the two words, "click here," it is indistinguishable from others in many different contexts.

There are techniques to solve that, however:

https://www.w3.org/WAI/WCAG22/Techniques/html/H33

https://www.w3.org/WAI/WCAG22/Techniques/css/C7

I never understood why the visually hidden has not been incorporated into the CSS standard proper (something like display: visually-none). Instead the standard is effectively recommending authors use a hack to do what is a very common pattern.

It's a hack either way. Screen readers really should support the title attribute like they do for image links; or maybe HTML should have had an alt attribute for <a href> as well.

When using a mouse pointer, you also want that information as a tooltip.

The problem here is that the screen reader will just read the link text and not the contract around it. In this case, the correct examples proposed by W3C will read just as "Amaya”, which are almost as unhelpful.

Even the WCAG level A success criteria clearly states:

The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.

https://www.w3.org/WAI/WCAG21/Understanding/link-purpose-in-...

Having a single word announced by the screen reader to me would fail this criteria.

together with its programmatically determined link context really is the operative phrase in this quote. I would encourage you to actually read the examples on the page you link to - several of them announce just one or two words.

OP's comment addressed that:

The problem here is that the screen reader will just read the link text and not the contract around it.

I would encourage you to read OP's comment first?

I'm not sure what you mean now. Did you intend your quote from the WCAG to support OP's point, or to indicate that the screen reader has a bug?

At one point does accessibility decrease accessibility? I'm all for making improvements in the name of accessibility, but not so much about making things worse to support the least common denominator of screen readers. If people are going to need to change their behavior, wouldn't it be better to suggest some aria annotation instead?

Links are for clicking. Click here is superfluous noise.

I have this fight with some developers all the time. Users are dumb, impaired, fearful animals and if you don't spell it out to them they have no idea what to do. "Click here" might be superfluous noise but that doesn't mean it's not necessary (sometimes).

Put something better. "Visit our site", "View Results", "Download File", "Next Page". Almost anything is better than "Click here". "Click here" is the result of laziness - think about what the button does for a couple minutes and you should be able to come up with better text

Note that all of these would fail the criteria in TFA - either as verb phrases, or not clearly describing the link target.

> I have this fight with some developers all the time.

Please consider reading the rest of this thread before you keep fighting developers to do it your way.

After that if you still want "click here" that's your call but at least be open to better alternatives rather this dismissing this discussion.

I'm not explicitly talking about just "click here". I'd say it has it's place sometimes but it's rare. But a lot of developers have issues with redundancy or explicitly spelling things out for users for things that are "obvious".

With enough experience you learn that what is obvious is less obvious than it appears.

If your users have really never used a web browser before, then phrase it like:

Click this hypertext link: <a href="more-info.html">More Info</a>

Put the call to action outside of the link, and make the link say what it is, not how to follow it.

Anyway, mobile phone touch screens don't click. Saying "click here" is like using a floppy disk as a save icon.

I dare you to use a different icon than the floppy disk for save. People still use "click" terminology for tapping things on their phone and I doubt that will ever go away.

> If your users have really never used a web browser before, and you are absolutely sure they are using a mouse on a desktop computer, and you can't imagine them ever using a mobile phone

...have you ever used a mobile phone? Clicking is the only action you can take on one.

> Anyway, mobile phone touch screens don't click.

Let's check the dictionary!

https://en.wiktionary.org/wiki/click

- (verb) 2. [intransitive] To emit a click.

Phones don't do that, but that can't be relevant to the text "click here" because that text is directed at the user, not at the phone.

- (verb) 5. [transitive, graphical user interface] To select a software item using usually, but not always, the pressing of a mouse button.

Hmm....

Clicking with your finger is called "snapping" and you can't snap at traditional mobile phone interfaces and expect that to work. Touching with your finger on a screen makes no sound, not a click, not a thump, not a knock. It's silent, short of haptic or audio feedback, and that's not your finger clicking, it's the phone. That is my point. That's why they call them "touch screens" not "click screens". Do you disagree, or do you touch your phone so violently with your finger that it emits a click? Maybe that is the glass breaking!

Or is your entire point that you think it's actually a good idea to put the words "click here" in links? Then explain why?

Sometimes you need a placeholder. Think of it like a physical button where nothing is written on it and the description is next to it.

It's not superfluous noise at all. As a user of the World Wide Web I personally find "click here" to be easy to quickly identify and understand. When I see the underlined "click here" I quickly know exactly what I need to do.

And you don't find links with the underlined name of where they lead to be "easy to quickly identify and understand"?

Are you saying that you need links to say "click here" in order to understand what to do?

Then how did you manage to navigate to this discussion and press the reply link, which did not say "click here"?

Do you not think this looks like superfluous noise at all?

click here for mat_b click here for 1 hour ago | click here for undown | click here for root | click here for parent | click here for prev | click here for next click here to collapse [–]

bla bla bla

click here for reply

And how do you know it is a link?

It is an interesting point, because in 2001, what is a link was usually clear and standardized: blue, underlined, often both, like on the article page. Now, just look at Hacker News, only the links in comments are underlined, and they have no special color, you have to mouse over if you want to know. And Hacker News is not in any way special in that regard.

So I would argue that "click here" is more relevant now than it once was. Same idea for buttons by the way. They used to look like, well, buttons, often with a 3D look. Now, there is often no real difference between a button and regular framed text. It means we need more context to guess which is which.

Aria tags are something you think might have more developer compliance than better anchor text?

Most of us never wrote an aria attribute in our life.

But I haven't used "click here" as anchor text in 20 years because it sucks for these reasons.

I think the links just need to be longer vs a couple of words.

We are used to small areas, but the problem is that you end up with 'click here', like in the example. But if you linked the whole text, it's basically the same thing as adding aria.

IMO, most cases that I see using aria seem like a fix after the fact vs doing it the right way.

There are use cases for it, but in the case of the example, making the whole sentence a link would be good.

Regarding screen readers, you can have it read all links, which is why the 'click here' is an issue. So you want a balance. Change "for x, <a href=...>click here</a>" "<a href=...>for x, click here</a>"... ta-da?

You need to optimize for people using accessibility tools, but also for the people looking at the site...

> Regarding screen readers, you can have it read all links, which is why the 'click here' is an issue. So you want a balance. Change "for x, <a href=...>click here</a>" "<a href=...>for x, click here</a>"... ta-da?

No, you want the verb to be whatever "x" does or is for, not the action taken to get there. The action taken to get there is the same for all links regardless of what they're for. So this is a bad example simply because we don't know what "x" is so we don't know what a better verb would be.

It depends on x, right? For example, it could end up being, 'for learning more about Hacker news click here'.

I think that signals to visitor using screen readers and without, what that is and how to interact with it.

If someone with a screen reader is jumping through links, they'll get context for the link. A visitor not using it will see get the context since it's all highlighted together. Someone using a keyboard, the outline will highlight all of it.

I am just a keyboard user. I have no idea if this is the best way. But I think it gives the same info to everyone.

> accessibility decrease accessibility

accessibility is usability. build products that are usable by people. that's all.

Everything in user interface design is a trade-off. There are many usability and accessibility and readability and design factors that every interface designer must balance and trade off against each other.

So of course usability can decrease usability, readability can decrease readability, accessibility can decrease accessibility, beauty can decrease beauty, and all those desirable traits can decrease each other, because there is no one single "technique" you just apply mindlessly to achieve any of those goals.

There are many many ways of achieving (and ruining) each of those goals, and you constantly have to balance and trade them all off against each other.

If somebody is so lazy and careless and poorly educated that they always use links saying "click here" as a solution to their problem of not being creative enough to come up with a better more descriptive link, I can guarantee you 100% of the time they are not going to give a flying fuck about aria or even have a clue what it is.

I'm sorry, should we design websites around SEO, or should search engines just use context properly?

Search engines and websites are going to be subsumed by LLMs, so it's not like this argument matters anymore.

The general consensus is that the dislike of AI is so strong, that a large chunk of the population will disregard something if they even think it is generated by AI. Also, the LLMs need a continuous feed of new, original material to ingest or they'll be all thumbs.

While the long-running trend of SEO stuffing from low-value content farms has polluted search results for years now, Google didn't really care about fixing that problem because there's a perverse incentive to generate more ad revenue by making the first page results usesless. Who cares about doing the right thing? Daddy's got to get his quarterly numbers up. I should also note that those content farms were also early adopters of genAI as we know it today.

Infinite growth isn't a thing. Every cancer eventually kills its host.

Are you sure that’s the general consensus about AI? HN has a very intense relationship with this stuff, because we have hardcore boosters and hardcore skeptics. Among people I meet offline the feelings seem a lot weaker in either direction.

As best I can tell, your typical person here doesn't tend to hang out with normies, which definitely skews things.

> The general consensus is that the dislike of AI is so strong

This is such an echo chamber. Most people love AI. It's one of the fastest growing types of content across all social media.

The news media is telling us we hate it (eg. John Oliver, 404 Media), but this is not the mainstream consensus. Views and likes don't lie.

"Normies" think this technology is magical. Some organs of the traditional news media are trying to skew their opinions.

I see constant comments on social media complaining something is AI sometimes even when it’s not. Those commenters are all viewing it but they aren’t choosing it. And “likes” absolutely lie because there isn’t a “dislike” option.

> Views and likes don't lie.

If you're saying you have relevant stats, then please, share the stats.

That's a programmed behavior of the screen reader and a limitation of the contextual awareness of the search engine. Apparently this has been an issue in the wild since at least 2001 so I don't know what to tell you.

That's a screen reader problem and search engine problem.

It would be an extraordinarily easy for screen readers to have a heuristic that whenever a link is just "click here" or common variations like "tap here", "click", etc., to read the entire sentence containing the link. It's not exactly rocket science. Yes, you need an internationalized list of strings to detect. Also, if aria-label is present, just use that.

Likewise, search engines are great at inferring meaning from the page as a whole. I'm not going to change my link text for the benefit of search engines.

> It would be an extraordinarily easy for screen readers to have a heuristic

> Yes, you need an internationalized list of strings to detect.

Who would maintain this list and be the authority for every language on Earth?

We've managed to get this far without needing such a central dependency.

The screen reader developer.

It's not a "central dependency" that needs an "authority". It's just part of building internationalized software.

Shouldn't screen readers have intelligent heuristics to most appropriately convey context when required? Seeing as most of the web doesn't have accessibility annotations?

In contrast, using descriptive link text does seem extraordinarily easy.

Except that it's not? As demonstrated by the entire internet. It forces you to write sentences awkwardly.

Do you use `aria-label`, then?

Screen reader heuristics are the wrong approach. If you want to use "click here", "download", "pdf", or something generic then use aria-label, aria-labelledby, or some other mechanism to give the additional context to screen readers and other assistive technologies. There's no need for any heuristics other than those in the specifications that the screen readers, web browsers, and web sites agree/conform to.

There may not be a surrounding sentence (e.g. in a "PDF"/"Download" link). The surrounding sentence may not add any/enough additional context, e.g. "You can click here for help." or "To view the article [one of many] you can click here.".

You then run into issues where 1) the screen reader/AT is overriding the ARIA/a11y markup on the page against WAI-ARIA and WCAG standards; and 2) you can end up with different behaviour on each screen reader, in addition to the places they already differ.

It's bad enough when web browsers introduced heuristics on form labels such that "name" + "label" fields were detected as a login form and other situations where bad heuristics were used and the web browsers overrode what websites were specifying.

IMO that's the problem of the screen reader/search engine. It's a fine line between "accessibility" and actively making things worse (i.e. less accessible) for the majority just to cater to a small group of screen reader users.

That's similar to replacing all major doors in a building with automatic ones that can't be operated manually and take forever to open, despite the typical occupancy by wheelchair users being 0. Accessibility is great, but accessibility for few should not come at the cost of accessibility for most.

That's not a fair comparison.

Using accessible link text doesn't cost the same as adding an automatic opener to every door in a building.

"Download Amaya" as the link text makes the most sense in your scenario. A link that just says "Amaya" isn't any better than one that just says "click here" -- neither is sufficiently conveying that clicking the link will download the software.

I tend to agree with this as well. The "Click here" portion of "Click here to download Amaya" is implied by the simple fact that it's a link.

Making the entire thing a link is IMO the clearest option if you just want someone to download your app, but doesn’t work as well when you want a list of software and links for details.

A list where: “Click here” to download “V 16.23.4” has two links one of which gives info on the download and their other starts a download is fine, especially if the info page also has a download link.

As a user, I wouldn’t intuitively understand that “click here” is going to download a file and “V 16.23.4” is going to give me information. I’d assume they were both download links and be confused why there are 2 and which one I should click.

If the download link is on the information page, a simple solution is just to send people to the information page where they can download. I tend to prefer that anyway. I find premature direct download links to be jarring where I’m not expecting it.

Isn't this also better from a Fitts' Law perspective (for sighted mouse users) - simply because more text makes the "target" larger? (Not that I've seen a desktop browser doing anything sensible with artificially boosting hitbox sizes since the late 1990s...)

if i only read HN threads i'd assume 95% of users exclusively use some screen readers to read the web

it's become a trope to the point i know i can ctrl-f "screen reader" if literally anything ui related is being discussed

Screen readers are deterministic website or web application navigation applications. Building for screen readers isn't just for the disabled, it's for you, too. That will become infrastructure for testing and automation.

If you are doing front-end web development then you really need to have some knowledge about accessibility, screen readers, etc. so you don't make simple/common mistakes. More so if you are involved in addressing accessibility issues for customers/your company.

Although he has a point - it seems overdiscussed compared to other types of accessibility or design topics.

I dunno, color blindness is brought up just as often here IMO.

On the whole I'd say it's a good thing because it means that the various awareness campaigns are working. Better that this kind of stuff is "overdiscussed" than not discussing it at all.

And besides, this focus has some useful side effects. For example, pages designed with screen readers in mind are also that much easier to interact with from scripts and other automation.

I strongly dislike "click here" links because when I'm looking for a link, I want to read only the link-formatted words on a page to find the link I'm interested in. "Download Amaya" would be a great link. Just "Amaya" (unless leading to a page with information about Amaya, I suppose) or "click here" are not.

I often want a second source to first check if that is trustworthy: copy paste amaya while having to not accidentally click it is annoying, since often linebreaks and multiword names or company+product splits occur. Selecting and reading text should be easy. Navigating HTML should be wanted, not accidental.

Therefore, the ``click here'' works best for me.

PS

- "_Get Amaya_" should start a file transfer.

- "Get _amaya_ over there!"

  sounds like "okay next site will be info dump before actual download", which is acceptable to gather trust like brand or imprint recognition over there instead of googling now.

Ideally browsers would have a shortcut to enter a text selection mode - this would also fix the annoyance of sites disabling text selection on certain elements.

The Newpipe app on Android has such a mode for Youtube descriptions.

> Ideally browsers would have a shortcut to enter a text selection mode

They do - Firefox has the option "Search for text when you start typing". I have it enabled for decades.

Scannability is one of the reasons my formula is to link a complete descriptive phrase, like “Read more about hrefs,” or “take a survey on meeting times.” Links can be long, and probably doesn’t hurt SEO.

> > Get _Amaya_!

> That suggests a link to the Amaya website, not a download page. That's not effective for a download.

In all their examples, the link is to the homepage of the Amaya website, not some download page (never mind the actual download).

It seems their message is watered down quite a bit by conflating the issue around "click here", which as other comments have said is an accessibility issue, with whether the text accurately reflects the target.

The early web was full of these links. Over time more actions became buttons with direct labels. This replaced clearly bad link patterns like:

- To cancel this purchase [click here].

- To complete this purchase [click here].

I mostly agree. One terminological difficulty is that, depending on the website, most users don’t “click” anymore, but “tap”, so something like “see here” could be more universal.

Am I the only one who is amused by seeing UIs fuss about using “tap” vs “click”? Is there anyone who has ever gotten confused and started looking for a mouse to plug into their phone because something said “click the X button” instead of “tap” it?

This sort of pedantic need for correctness at the cost of clarity seems to also crop up as businesses become increasingly corporate and expand their offerings.

“The best tires” becomes “the best vehicular solutions”

No, but for young people who only ever used a smartphone or tablet, it might be relatively unfamiliar terminology, and even when they do know what it means, may seem misplaced for how they use technology.

As an analogy, consider how you would feel if the instruction manual of your microwave oven (or other physical appliance) would instruct you to "click" its buttons. It's not that you wouldn't understand what to do or that you'd be looking for a mouse port, it's that the word wouldn't be the right one for the circumstance.

Incidentally, as a keyboard user I sometimes feel that way when there are instructions to "click" some UI button, but I will press the appropriate keyboard shortcut instead.

I’m still looking for a keyboard with an “Any” key. “Press Any Key” is very difficult without.

I sit near to one of these teams at work. They are very earnest and lovely, but torture themselves at great length over this stuff.

I find it funny but I will say that passion often produces amazing results.

Yea, the examples are wrong, and I'd interpret them the same way.

The principle is something I agree with and try to abide by, though.

I like "_To download W3C's editor/browser Amaya, click here_."

"click here" makes sense in that context, but links can be viewed in the screen reader rotor, where they just show up as a list of links out of context. aria-describedby can help out, but if you just make the text inside the link better then you can avoid having to do that.

I do agree with you about verbs.

Agreed.

I'd suggest:

_Download Amaya here_, W3C's editor/browser

or

W3C's editor/browser: _Download Amaya here_

It’s not really about clarity, or even about accessibility (although both of those are great!): it’s about what a Web page is. A Web page is a document which can link to other documents.

> Links should absolutely be verbs

No, links imply a verb: ‘get.’ Buttons imply another verb: ‘post.’ It’d be awesome if there were ways in HTML to indicate other verbs, such as put and delete.

> > Get _Amaya_!

> That... doesn't tell me how to get Amaya.

No, it doesn’t: it is a document calling its reader to action. That’s something a document does: it tells a reader how to do something, or calls the reader to do something. Clicking is just an artifact of a particular technology at a particular point in time (heck, I imagine most people nowadays don’t click, because they are using smartphones — they tap instead).

Yes and we all know that websites are not built to be consumed by humans, so this argument makes perfect sense.

You don't get hyperlinks in a document-centric approach...

You think of them as action, they're not.

Actions are for applications. You are reading a document.

They are metadata.

Think of them like "footnootes" of a paragraph, or references.

Remember, you're reading a document, not using an application.

Documents don't contain calls to action like "Download X" or "Tell me more about Y", so your argument falls down in relation to the examples presented by W3C.

'Member the 80s?

I don't read documents online. I use applications.

Besides screen readers, using a single descriptive noun as the link text might help for maintainability in some situations. First, it reduces the chances of a given link accidentally getting copied to another section by an unscrupulous maintainer. Second, in case of a dead link with a non-obvious URL (like maybe some ancient sourceforge link to a now renamed project), the link text is an extra bit of information to remind you if and how the dead link should be updated (assuming no comment exists). I admit that's a pretty minor benefit.

A rule of thumb I've been following lately (when communicating in e.g. GH issues or Slack messages), is to use the title of the page where possible. Hopefully, the page title should reflect the page's content, and thus automatically works as a link title a lot of the time.

In your example, I would expect the download page of Amaya to be titled "Download Amaya", so my link can simply be "If you are interested, [Download Amaya]!"

I think that the goal was to help ppl move away from an overly verbose, printed document like style