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.
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.