> To download W3C's editor/browser Amaya, _click here_.
Is extraordinarily clear. I'll click the link and it will either download directly, or it will be a download page.
In contrast:
> Get _Amaya_!
That suggests a link to the Amaya website, not a download page. That's not effective for a download.
Similarly:
> Tell me more about _Amaya_: W3C's free editor/browser that lets you create _HTML_, _SVG_, and _MathML_ documents.
This is terrible. It's not about downloading, and "tell me more" is the command, but not linked! For all I know, the "Amaya" link goes to a corporate landing page, not the "tell me more" information I actually need.
The conventional uses on the web are totally fine:
> To download W3C's editor/browser Amaya, _click here_.
> _Download Amaya_, the W3C's editor/browser.
The idea that links shouldn't be verbs seems very silly to me. Links should absolutely be verbs, when they involve an action like downloading or finding out more. Obviously that's different from "reference" links like in Wikipedia, where you're finding more about a topic.
And "click here" makes it exceptionally clear that a link isn't merely a reference link, but an action link. When I see:
> Get _Amaya_!
That... doesn't tell me how to get Amaya. That tells me "Amaya" is a reference link, not a download link.
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.
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.
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.
"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.
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...)
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.
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?
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.
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
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, and purposefully want to confuse them if they do, then phrase it like:
Click this hypertext link: <a href="more-info.html">More Info</a>
Put the device specific call to action outside of the link, and make the link say what it links to, not what physical action to take to follow the link.
Anyway, mobile phone touch screens don't click. Saying "click here" is like using a floppy disk as a save icon.
Obviously for the same reason you also should not say "touch here" either. Touching your desktop computer's screen doesn't work unless you have a touch screen, which is rare.
That's the point, why saying "click here" or "touch here" is always wrong.
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.
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?
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.
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 [–]
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 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.
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.
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.
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?
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
> 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.
"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.
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.
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.
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]!"
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).
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.
> To download W3C's editor/browser Amaya, _click here_.
Is extraordinarily clear. I'll click the link and it will either download directly, or it will be a download page.
In contrast:
> Get _Amaya_!
That suggests a link to the Amaya website, not a download page. That's not effective for a download.
Similarly:
> Tell me more about _Amaya_: W3C's free editor/browser that lets you create _HTML_, _SVG_, and _MathML_ documents.
This is terrible. It's not about downloading, and "tell me more" is the command, but not linked! For all I know, the "Amaya" link goes to a corporate landing page, not the "tell me more" information I actually need.
The conventional uses on the web are totally fine:
> To download W3C's editor/browser Amaya, _click here_.
> _Download Amaya_, the W3C's editor/browser.
The idea that links shouldn't be verbs seems very silly to me. Links should absolutely be verbs, when they involve an action like downloading or finding out more. Obviously that's different from "reference" links like in Wikipedia, where you're finding more about a topic.
And "click here" makes it exceptionally clear that a link isn't merely a reference link, but an action link. When I see:
> Get _Amaya_!
That... doesn't tell me how to get Amaya. That tells me "Amaya" is a reference link, not a download link.