“Click here” is just the start. Bold, red, and blinking. People barely read, let alone process what they’re reading. “Click here” is at least simple.
I'm not sure I've seen this behavior. More commonly, it is the <title> of the page.
But, thankfully, web developers and web technology improved since then.
I just checked, and desktop Firefox still offers it. At least, version 138 on macOS does.
W3c says:
Get *Amaya*
Read more about *Amaya*
*Get Amaya*
*Read more about Amaya*
Personally, I think both are confounding two different use cases. Links are often used inline in text. The use case that W3c and the Home Office are addressing are use cases that would be better address by out-of-line buttons:
[Download]
[Documentation]
To use a concrete example, how should one rewrite the following?
PiPedal is a guitar effects pedal that runs
on Raspberry Pi. To download PiPedal, *click here*.
To read the documentation, *click here*.
PiPedal is a guitar effects pedal that runs
on Raspberry Pi. Get Pipedal. Read the documentation.
Pipedal is a guitar effects pedal that runs on
Raspberry Pi. To download PiPedal, visit the *Download
Page*. To learn more about Pipedal, view the
*Documentation*.
Ubuntu Server installs don't suffer from this problem;
but before choosing an Ubuntu Server install, you
should read the *Ubuntu Server* section of the
"Installing on Ubuntu" page.
And in the very first example given, the text is from a lede in a web page where concision matters.
To download PiPedal, click *here*.
[ Download ] [ Documentation ]
To download PiPedal, visit the *Download Page*. PiPedal is a guitar effects pedal that runs on Raspberry Pi. *To download PiPedal, click here*.
*To read the documentation, click here*.Yes, those buttons may not be "in context" when the page is not being viewed in a visual medium.
> To download PiPedal, click here.
Another appropriate link in this case could be simply:
*Download PiPedal* now!
To *download PiPedal*, visit the Download Page. PiPedal is a guitar effects pedal that runs
on Raspberry Pi.
You can *download PiPedal*, and learn more
in the *PiPedal documentation*.Good design is accessible by nature. Otherwise it’s just sparkling wank.
Not everything done in the name of accesility makes it accessible to all, nor does accessibility have a necessary correlation with 'good design'.
That's not to say we should't strive for both and require accesible solutions, but let's not pretend putting lightswitches 40" from the floor or those bumpy concrete pads in grocery store parking lots are better for everyone.
But yes, in general you're absolutely right, that a good designer will take into account all factors, including accessibility. But the way that "design" has evolved in practice in means that the thing we all think of as "web design[er]" is not optimizing for it.
I feel like a link should be used for more information retrieval; therefore, the link should be descriptive of its forthcoming content. Instead of using a link as a call to action, shouldn't it be a button? This feels more "pure" in the semantic web context.
Of course, a download on the internet is usually a link to a file, which the browser decides how to handle - open or download. From an internet purist point of view, a link to download a file also makes sense.
> "Click here" assumes everyone has a computer and mouse. And it's not even needed: most users of the Web understand how to follow links.
1. https://lists.w3.org/Archives/Public/www-qa/2001Sep/0007.htm...
not "<a>click here</a> to read more about dogs" but "read more in our <a>article about dogs</a>"
imagine not being able to see and tabbing through a series of "click here"s
You can use something like macOS VoiceOver right now to see how it behaves.
Yes, or it can summarize the text and explain what the link is to.
1. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
2. https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
3. https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
4. https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
The larger issue is that developing software for multiple platforms and multiple browsers and multiple different types of human interface devices (from eye tracking to sip-and-puff joysticks) from dozens of vendors is an extremely complex affair.
Users may even employ multiple different screen readers in different contexts to work around incompatibilities.
Sure, sure, we need to accommodate people with disabilities. First step to get there is to make sure the accessibility software isn't trash.
The Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act. The ADA, specifically Title III, applies to public accommodations (including websites), requiring them to be accessible. Section 508 mandates that federal agencies ensure their electronic and information technology, including websites, is accessible to people with disabilities.
The EU Web Accessibility Directive and the European Accessibility Act (EAA) are key pieces of legislation aimed at improving digital accessibility for people with disabilities within the European Union. The Directive focuses on public sector websites and mobile applications, while the EAA expands accessibility requirements to a wider range of products and services, including those in e-commerce, banking, and travel.
Is this how you want these discussions to go?
I guess at some point this button gets a bit worn out and I start wondering what pushing the "do something about it" button will do.
And, I benefit greatly from accommodations around accessibility. Both in the physical world and online.
Yes, exactly, if ARIA tags haven't been provided. It's not exactly rocket science to have some heuristics that check if a link is solely "click", "click here", etc., and it reads the entire sentence if that's the case. Seems like it would work 99+% of the time with exceedingly little effort.
There's no expectation, and should be no expectation, that the function of a link should be derivable directly from the text it encloses.
Besides, AMP is the almighty master of this practice, and they’re not trying to help disabled people, they’re trying to control the internet.
Yes.
If I had "Amaya!" as the link text to download something, I'd be not much better off and would reach for context too.
What's the problem with reading the surrounding text or the URL?
They don't try to be helpful, they only do exactly what they are told.
Frankly I think there's rear space for interruption here, particularly with AI.
Why is it embarrassing to need to code against standardised accessibility interfaces so that other tools using those interfaces can function? Is it embarrassing to have to code against a database or filesystem interface to persist data, or a graphics interface to show pictures?
[1] https://www.powermapper.com/tests/screen-readers/aria/
[2] https://www.powermapper.com/tests/screen-readers/labelling/i...
I'd reckon 90% of 'accessiblity' software was written by a sighted or hearing dev that thought they had an idea that would be 'helpful'.
This is how software should work. Attempting to be "helpful" usually makes things worse. Doing exactly what it's told makes it predictable and usable.
Just look at how much of the HTML 5 spec is a nightmare of parsing rules for handling malformed SGML. Look at how it got there - all the invocations of Postel's law justifying attempting to handle malformed input in "helpful" ways, until things were eventually such a compatibility nightmare that a new spec was created to give precise rules for parsing every single input the same way. "Helpful" was specified away, because it was so broken.
Now if only screen readers provided consistency in following rules, too. They're not in a great state, but your attempted solution is worse.
Simply either read the surrounding text (possibly by additional instruction) or the URL. I can't fathom how that's a difficult task.
Crucially: screen reader navigation is NOT the same as keyboard navigation.
https://www.w3.org/WAI/WCAG22/Techniques/html/H33
https://www.w3.org/WAI/WCAG22/Techniques/css/C7
However, I don’t know how well the first one is supported by screen readers.
(Edit: Updated the links from WCAG 2.0 to 2.2.)
https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-...
I did sweat localization with this approach. We use a workflow to ensure some peer review but it's an added challenge. Seemingly all good.
Also poor form is to have your download button on github.io pulling an executable from malware sites like sourceforge. I'm looking at you wxMaxima.
A website is a website. To download is to download. The mechanics won't be 'abstracted away' just because you don't call them with the proper terms.
These days I don't think you'd find many people following this style guide, but I think I understand what they're going for. They seem to be making the prose neutral to the technical details; after all, if you're keyboard navigating, maybe you're not "clicking" per-se. Maybe the pages are printed onto paper, etc.
Now I really wish the page elaborated a bit more. I do wonder if there's any logic to avoiding "website" or if it's just the different choices they made in the examples.
I would suggest that "click here" is more concise, meaningful, and well understood than "follow this link" or alternatives.
In cases where you want to do something involving a call to action, like "Click here to download", I think "Download" or "Download now!" are better. And hell, often times CTAs are better as buttons (at least visually) than links anyways.
That said, it's not like I follow this religiously. But anyway, I think it's highly likely people are taking away the wrong message here.
I guess to put it another way, it's not that the terminology we use is dated or wrong per-se; I mean sure, people tap on hyperlinks more than they click on them these days probably, but the point isn't that the terminology is dated or isn't understood. It's that well-structured hypertext can avoid it altogether.
Firstly because of the acceptance of "click is to web as dial is to phone", that the term "click" as a verb meaning to follow a navigation link or interact with a button, or generally interact at all with something on a website or app. I think this is useful and should be encouraged [0].
Secondly because it was used in the first place because it was very clear instruction. "Download" by itself assumes that the user knows how to download, and if the UI element isn't clear that it's a link or a button (or interactive) then that's not obvious how that should happen. "Click here to download" is much more clear, obvious, and helpful. I think it was old-school SourceForge that had "Download" buttons that didn't look like buttons, and ran adverts that had very prominent "Click here to download" buttons, and that ended up being very confusing and getting a lot of people to click on shitty ads.
Thirdly, and purely as a matter of personal taste, I don't subscribe to the design philosophy that less is better. I prefer clear instructions to ambiguous ones, even if that means more words. The impulse to surround everything in whitespace, remove scroll bars, and make it look pretty at the cost of usability should be discouraged imho. A button should look like a button. It should be clearly labelled with what it does, or what you need to do to make it do the thing. I realise I'm in a minority here, but that's not unusual.
[0] though maybe the new verbal usage of "I'm double-clicking on this concept" to mean supporting it is probably a bit much.
To see our latest news, click here, or click here if you want to request a catalog. The latest board minutes can be found by clicking here. Click here for product documentation. If you have any comments about our web site, click here to email us, or click here to call. If you were confused by this click here, or click here to let us know it met your expectations. Click here to see how many people have visited our internet web site.
On the plus side, there was actual useful content on the web, rather than the content-free designs that popped up in the Web 2.0 era.
> See our latest news, request a catalog. The latest board minutes. Product documentation. If you have any comments about our web site, email us, or call. If you were confused by this, let us know it met your expectations. See how many people have visited our internet web site.
Which imho is not any better, and arguably worse.
If you need to disambiguate or further clarify links, well, you should also set the title attributes too. That ought to help.
I'm pretty sure the W3C is not recommending you do that. If you link to the Amaya website, link on the text "Amaya". If you're linking to something else Amaya-related, modify the link text appropriately.
I would still include more of the action, i.e., ”Get Amaya“ instead of ”Amaya“ as in the article.
- Toggle/hide aria-hidden items from the page so you can ensure only the important components are there
- Show the ordered list of links, headings, landmarks you'd see in screen readers like when you use the VO+U rotor in macOS VoiceOver
- Toggle on a mode where a little "?" appears next to anything with an aria-description that can be hovered as a tooltip
Prob would be a decent start.
Though I recommend the more curious HNer to fire up macOS VoiceOver, do its tutorial (Settings -> Accessibility -> VoiceOver -> "Open VoiceOver Tutorial..."), and then navigate your own website. Use Safari for this since it has the best VoiceOver behavior.
It's very eye opening (heh) and helps you understand what things like aria-hidden actually are for.
If that's not enough, it also prepares you for bad luck in the future, and it's also just cool being able to use your computer with your eyes closed.
I had some classes in uni where we weren't allowed to use our laptop screens, and I bet I could have gotten away with having my hands inside a half closed laptop with an airpod in my ear scrolling HN/Reddit while the professor droned on for an hour.
Anyway, "click here" is more accessible for anyone else, since links should look like links, and random half-bold words in a wall of text are not cutting it.
Click here for screen reader accessible version
It’s like… ‘click here. No, here. Left a bit. Almost. Come on, you can get it. What are you, blind or something?’
Get *Amaya*.
Tell me more about *Amaya*.I guess technically, "To learn more about Amaya, view the datasheet." is also an imperative sentence. But to my mind, it scans better as inline text. Not quite sure how to nounify that one either. And interestingly, inability to find the "learn more about" link on landing pages for products I'm interested in is a source of constant frustration for me. There should be a word for "something halfway between the the breathless lede on a landing page, and "here's a thousand pages of documentation". For hardware products, the "datasheet" is exactly what I'm looking for; there doesn't seem to be an equivalent for software products.
> contributed Sep 2001 by Aaron Swartz
Thoughts
-- this advice is 24 years old (and I think largely ignored)
-- Aaron Swartz (!)
"Click here" assumes everyone has a computer and mouse. And it's not even needed: most users of the Web understand how to follow links.
Often very hard to tell what's a link when it's not underlined and non-blue colors (or no color) is used.
when hn could use a more distinct style for it
For example, most Windows programs have "File" as the first menu item. How do I exit? Go to File, the bottom option is usually "Exit". Does that make sense? No, why is "Exit" a File-related option? Why is it like that? Because it's always been like that.
Want to learn about the program? Go to Help > About.
Some more geniuses even got involved and thought "If the user wants to edit preferences, well, they can go to the menu option Edit, and find Preferences. Never mind that Edit is otherwise filled with document related functions like Cut, Copy, and Paste!"
Just because you're used to the jank doesn't mean it's the best design.
As sibling comment says, on the Mac the first menu item is about the app. App -> Preferences, App -> Exit, wouldn't such a convention make more sense?
Edit -> preferences makes sense because you're editing your preferences. File -> Settings makes no sense. Help -> Options makes even less sense. Help -> KEYBOARD SHORTCUTS is just insane to me.
Fixing those was a large part of my life whilst working for a web design agency during the school holidays circa 1996-97 (providing plenty of incentive to learn find/grep/sed/perl!)
I guess this 2001 W3C 'Tips for Webmasters' page was merely stating the commonly-accepted best practice at the time.
Preferably with a download icon to indicate that it's going to be the actual file and not just a link to another page with the real download button hidden among 4 ads that are just download buttons.
> To download W3C's editor/browser Amaya, [click here].
This gives you an option, where multiple options may be available.
> To download Amaya, go to the [Amaya Website] and get the necessary software.
This is even better, as 'click here' assumes the input device.
> Get [Amaya]!
Whilst being simpler, it does not make clear that the action is optional.
Whether I click something may require some additional information around the link, for example:
> To download W3C's free editor/browser Amaya, go to the [Amaya Website] and select the latest version on the home page.
Now I know that it's free, and I have instructions to carry out to find what I'm looking for.
See also https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-..., also keeping in mind that since June, the underlying WCAG guideline is a EU-wide legal requirement for company websites.
e.g. from the WCAG examples you link to:
> An account registration page requires successful completion of a [Turing test](https://www.w3.org/TR/turingtest/) before the registration form can be accessed.
I think this is a UX problem with screen readers, and actually probably something LLMs might massively help with. If I was designing something for screen readers, I would probably have interactive elements within a context window, i.e.:
<context>To download W3C's free editor/browser Amaya, go to the <a href="..">Amaya Website</a> and select the latest version on the home page.</context>
> See also https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-... , also keeping in mind that since June, the underlying WCAG guideline is a EU-wide legal requirement for company websites.
On this page itself, within the box "Success Criterion (SC)" the listener would hear "purpose of each link", "programmatically determined link context", "ambiguous to users in general". The last one is, well, ambiguous to users in general. Even as a sighted person, without selecting it, I wouldn't know what it is actually going to link to.
I would say that the web is generally actively hostile towards screen readers, and not because of a lack of WCAG adoption. You have text in images (not just static, but also GIFs), JS heavy components, delayed loading, dependant interactions (such as captchas, navigation drop downs, etc), infinite scrolling - the list just goes on. The web is primary a highly visual space and likely will remain so.
I don't think the EU's accessibility act is actually enforceable [1]. Unlike cookies, some of the changes required are massive, to the point where it may not even be worth existing in the EU market if it's enforced.
> Incorporating captions into video content, as well as providing audio descriptions and transcripts
Even proving you are compliant is a lot of cost, which includes audits and training staff. You can always trust the EU to regulate itself out of being competitive.
[1] https://www.wcag.com/compliance/european-accessibility-act/
You can do:
• [Download X] - immediate download link.
• [Learn more about X] - go to webpage, discover other interactions there
• [Register to download X] - if registration required
Short and concise copy is generally better, extra information rarely makes content better.
> You can download the Amaya Browser from [Amaya’s download page]
It’s both explicit for sighted reader and screen readers too.
Yes there’s some duplicated words. But the point of that paragraph isn’t to be artistic, it’s to be informative. You can save the creative word play for your regular paragraphs.
You can [get the Amaya Browser] from the download pageI wonder how successful the screen reader experience is for using the web. Without checking URLs, how can they be sure for example they don't enter this credit card details on http://bank.xyz/scam_page , rather than https://bank.com ?
Or how do they know whether the download page automatically downloads the file whilst they are on it?
I can only imagine that using the web is extremely difficult.
* It's only 10 char and much too short for someone to click when it's inline with other links. Let's not mention text squirming around the screen via molasses JS, kicking your text up, down, and around the screen for several seconds before those short 10 chars finally become stationary.
* With high resolution touch screens, you're maybe 80% accurate on actually clicking right there. Again, my accuracy is my fat finger, and nearby links are just UI landmines.
That was much less of a problem in 2010, and either way not really something for the size of your hyperlink to fix.
————- Learn more about [the browser]
Never hear about [the browser] again
Those links will do very different things.
is preferable to any shorter link.
If, somehow, you have multiple links in a sentence, see if you can manage a word or two of unlinked text in between, or, better yet, stop being pretentious and focus on usefulness.
Not: _You can run web browsers,_ _spreadsheets_ or _drawing software._
You can run:
* _web browsers_
* _spreadsheets_
* _drawing software_
> is preferable to any shorter link.
I agree, but my reasoning is not about length but about semantics. The 'Tell me more about' part carries meaningful intention and makes no sense without the link, so it should be part of the link together with 'Amaya'.
If on the other hand the example sentence was, say, 'You may be interested in Amaya: W3C's free editor/browser...' I would agree that the link should be limited to 'Amaya'—the meaning carried by the 'You may be interested in' part is tangential to the hyperlink.
That is true. And some people don’t see.
Images can contain alt text metadata, but links can't. Why? Because some genius with an opinion decided links aren't allowed to have alt-text. The rationale for why links can't contain alt-text:
Using alt text on a hyperlink would be redundant and potentially confusing for screen reader users, who may hear both the hyperlink text and the alt text
Yet with the current mandatory design examples, it is confusing! The suggested link text is just the name of the product!! What's the link going to do when you click it? Download something? Render a page? Show an image? Something else? How is that helping a blind person OR a non-blind person?!
The spec should allow you to decide how the content is presented, in a way that works for both blind and non-blind people. But we see here that, in order to make a "beautiful engineering design" that supports blind and sighted people, it's actually making it harder for both. If they took away their arbitrary restriction, the content creator could be free to craft it however makes sense, in a way that supports all people well, rather than all people poorly.
With that singular idea in mind, everything else falls into place naturally.
People don't read websites linearly, in the best case they skim read all the buttons and links. I personally would include the verb as it gives important context and is a clearer CTA for the "skimmers".
Amaya is W3C's... "Download Amaya"!
A link that just says "Amaya" could be an internal or external link, and even if it's clear from context that the purpose of following the link is to download Amaya (rather than, for example, read more about it), it's not clear whether it's a direct link to the file or a link to the download page.
Note that aria-label does not work properly in all cases, e.g. when the browser chrome uses a different language than the site itself.
Now that I paste it in this HN comment, the link is gone. If it had said "To get Amaya, click here!" at least you could have seen from the context that it used to be a link.
There's also no explanation in it for why making a verb a link would be bad while nouns are ok.
`contributed Sep 2001 by Aaron Swartz`
Wild to see how much this person contributed to the open web we use today. I think the most notable example was RSS? It’s a shame that rss feeds have been nuked from existence.
So links to my website are fine, while links to my website are inherently not. I also have a strong pet peeve around imperative tone, so I'd never write something like go to my website or follow this link.
I guess this was written at a time when CSS was used relatively conservatively and, whatever the label of the button or link, it was clear you could click on it.
Somehow the current UX trend is to remove those underlines and boxes. I'm not sure how people are meant to intuit that something is clickable _except_ for the label.
Ctrl-K is the almost-universal shortcut for “insert hyperlink”, which is strongly preferred by everyone to a 237-character Sharepoint URL.
> 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.
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.The Newpipe app on Android has such a mode for Youtube descriptions.
They do - Firefox has the option "Search for text when you start typing". I have it enabled for decades.
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.
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.
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.
If you're saying you have relevant stats, then please, share the stats.
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.
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...
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.
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.
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.
With enough experience you learn that what is obvious is less obvious than it appears.
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.
...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....
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
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.
accessibility is usability. build products that are usable by people. that's all.
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.
When using a mouse pointer, you also want that information as a tooltip.
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.
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?
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.
> 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.
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?
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.
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.
Using accessible link text doesn't cost the same as adding an automatic opener to every door in a building.
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.
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.
it's become a trope to the point i know i can ctrl-f "screen reader" if literally anything ui related is being discussed
> 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 principle is something I agree with and try to abide by, though.
I find it funny but I will say that passion often produces amazing results.
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.
“The best tires” becomes “the best vehicular solutions”
- To cancel this purchase [click here].
- To complete this purchase [click here].
I do agree with you about verbs.
I'd suggest:
_Download Amaya here_, W3C's editor/browser
or
W3C's editor/browser: _Download Amaya here_
> 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).
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.
ex.
To download W3C's editor/browser Amaya, [click here].
[Download Amaya]
[Click here] to get Amaya for Windows
All collapse into something singular and sensible like [Download Amaya installer for Windows here] as an action inside the action section.
I don't know. I should probably put on a sleeping mask and navigate the web via a screen reader one of these days to really experience how things are.
> I don't know. I should probably put on a sleeping mask and navigate the web via a screen reader one of these days to really experience how things are. The difference is that it wouldn't be like experiencing it through a screen reader, it'd be like experiencing it with a screen reader that you can't use and will never be motivated enough to learn. Some blind people are known to listen to code in "reading speed" which is pretty incredible.
You'd be like standing on skis for the first time, or using Vim
For example, you have a page about... unemployment benefits. It has some body text that contains hyperlinks to other pages of the website, but at the end is has standalone paragraphs that say, "Click here to check your eligibility and apply online" and "Click here to log into the benefits portal". "Click here" identifies the things you are the most likely to do if you visit this page. This is much easier than scanning the body text for "the _residents_ of the _state_ can _apply online_ to sign up for unemployment benefits".
It's not the best option, an even better option it to pull out all "action" links into a separate panel, so it is typographically distinct from the rest of the page. Then the links can just say "check your eligibility and apply for benefits" and "log into the benefits portal".
"click here" should be a direct link to the latest version. You click on it, it should download the latest version.
There's also SEO benefits here as well because the more descriptive text helps search engines understand what search keywords might be relevant for the page being linked to.
> Ignoring the garbage on Web pages is a skill that some people don't have, and I don't know how to teach it. I'm reminded of this each time I try to help someone who doesn't have my background, use the Web; there are users who look at the literally first thing on the page and think about it carefully, even if it's "Please enable notifications," before they see the second item on the page at all.
> With Google searches now offering multiple screenfulls of garbage before the actual results, well.
> A related issue is failing to understand the epistemic status of different kinds of text on a page. E.g. the user who sees a clickable link with the text "I forgot my password" and believes that that means it's telling him he did forget his password (and it somehow knows this?), rather than just being the place to click if he forgot his password.
> The death of UI standardization, of course, makes this issue much worse.
I remember when Microsoft removed many buttons from their UI and replaced them with vaguely colored text (links) and it became a lot harder to figure out what to click on.
Don't use "click here" for link text
You want to see what good hypertext looks like? Check out: https://www.zetatalk.com
This lady has been promulgating her own brand of UFO kookery since the 90s, always in this same beautiful format. Nicely flowing prose, with only the relevant words turned into a link to delve further into the topic. Wikimedia also has very good practices.
But whenever I get depressed about the state of webshit, I glance back at ZetaTalk, a product of a different era, when hypertext was exciting, "surfing the web" to explore topics was a fun pastime, and anyone could put virtually anything they wanted online.
Anyway, I've learned long ago to ignore UI and UX advice coming from websites that look like theirs.
Nobody appreciates being talked down to with "click here" as if they can't figure out how to follow a link.
This article is from a marketing perspective. It assumes that the goal of the web site is to get the user to click on the link. Not to offer the user the opportunity to get more detailed info if they want it.
I think of "click here" as stage direction mistakenly left in. When most authors write, they often don't write in a hypertext context. Instead of using a Markdown-like notation for links, they default to stage direction.
So who is w3 to say how people should and shouldn't use links? All that I see are just opinions, with no objective metrics/theories to back up their recommendations.
W3 should be in the business of setting up technical standards that go through rigorous processes, not creating nonsense like this.
stogot•18h ago
chungy•18h ago
sham1•18h ago
> While the tips are carefully reviewed by the participants of the group, they should not be seen as anything else than informative bits of wisdom, and especially, they are not normative W3C technical specifications.
hombre_fatal•18h ago
> [Our published tips] should not be seen as anything else than informative bits of wisdom, and especially, they are not normative W3C technical specifications.
rs186•3h ago
I'd very much like to see resources put in more meaningful things, like, drafting standards.
lionkor•18h ago
empiko•17h ago
mannykannot•18h ago