Don’t use “click here” as link text (2001)
333 comments
·July 2, 2025robin_reala
phkahler
And if every link is just "Amaya" without verbs you can't tell what's what. So I think "get Amaya" and "go to the Amaya website" are rather fine.
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.
raincole
Go to the [Amaya Website](www.amaya.com) is perfectly fine. I seriously have a hard time understanding what this w3.org article is trying to say.
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.
bigbuppo
This was the web between 1995 and 2002:
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.
joelfried
In 2001 websites weren't what they are today. It was 5 years before jQuery's initial release . . . people needed to learn the proper terms somewhere in those days.
jchw
I don't think it's suggesting "Amaya website" is an incorrect or bad phrase in and of itself, I think it's just using the different passages to show how they'd prefer you style links in hypertext.
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.
jchw
I don't think this recommendation is suggesting it would be any better to do that; having a bunch of different links be just Amaya would be wrong too. If you had this situation you'd probably want to carefully choose different selections, e.g. "get [Amaya]", "Amaya [documentation]", etc.
If you need to disambiguate or further clarify links, well, you should also set the title attributes too. That ought to help.
oneeyedpigeon
> And if every link is just "Amaya" without verbs you can't tell what's what.
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.
rvnx
[flagged]
ceejayoz
Describing bundled adware as "fostering a sustainable ecosystem" while portraying Chrome as "forced malware" is a hell of a take.
StableAlkyne
If an ecosystem can't be maintained without bundling malware (adware is by definition malware), then maybe that ecosystem shouldn't exist.
wussboy
I feel like negative opinions are facts.
MangoToupe
Ironically, we really need to figure out away to make accessibility tooling more accessible to those who don't have a need for them. I'm not saying alter the tool, but surely there's got to be a way to visualize this for those who aren't going to put the work into figuring out how screen readers work.
hombre_fatal
Ideas for a browser plugin:
- 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.
paulryanrogers
Like WAVE?
nodar86
This sounds like a great idea, does anyone know a tool like that?
SilasX
I already kind of get this with extensions that let you browse from the keyboard (e.g. click a link without using the mouse) like Tridactyl. It lets me know when clickable elements are not detected as clickable, and, sadly, this happens quite a lot.
layer8
There are techniques to solve that:
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.)
cluckindan
For a more up-to-date version, see WCAG 2.2:
https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-...
layer8
Thanks, I updated the links.
bevr1337
I'm particularly fond of the latter approach. There's some joy in applying hints that can be optionally read and only provide clarity. It's a great writing challenge.
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.
amenghra
In a similar vain to the second link, I previously wrote about using css to truncate git hashes so that search functionality continues to work: https://www.quaxio.com/truncating_hashes.html
joelanman
it's true, but these are more fragile than simply having clear link text, especially over time as a site is maintained
ano-ther
That’s a good argument.
I would still include more of the action, i.e., ”Get Amaya“ instead of ”Amaya“ as in the article.
mattl
But you’re not getting anything. You’re just surfing to the Amaya website.
theandrewbailey
Getting it is what the website wants you to do. It's (presumably) the entire point of why that website exists.
cluckindan
Screen readers commonly provide several different ways to navigate on the page, and linear movement through the page is the least efficient method. Users can move e.g. between landmarks or between headings, or both at once in an ”outline” navigation mode.
Crucially: screen reader navigation is NOT the same as keyboard navigation.
jameshart
One of my favorite accessibility accommodation attempts I have ever seen on a website: paragraph on the homepage saying
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?’
bmacho
Surely this is not true, a screen reader must be able to read text with html links inside, and be able to open the next/current/previous link. What is it able to do, if not that?
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.
inopinatus
I find the accessibility concern a much more compelling argument than this article’s focus on “calls to action”, which is primarily a marketing/engagement concern and one that therefore earns my automatic distrust.
crazygringo
I couldn't disagree more. Their "bad" example:
> 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.
nulbyte
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.
danillonunes
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.
burningChrome
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.
Gormo
"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.
al_borland
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.
eichin
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...)
layer8
There are techniques to solve that, however:
runarberg
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.
rendaw
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?
CoffeeOnWrite
Links are for clicking. Click here is superfluous noise.
madeofpalk
> accessibility decrease accessibility
accessibility is usability. build products that are usable by people. that's all.
hombre_fatal
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.
DonHopkins
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.
crazygringo
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.
rhdunn
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.
theteapot
In contrast, using descriptive link text does seem extraordinarily easy.
cube00
> 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.
01HNNWZ0MV43FF
Do you use `aria-label`, then?
xanrah
I'm sorry, should we design websites around SEO, or should search engines just use context properly?
null
echelon
Search engines and websites are going to be subsumed by LLMs, so it's not like this argument matters anymore.
thousand_nights
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
rhdunn
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.
const_cast
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.
c22
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.
kqr
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.
jkestner
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.
a3w
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.
crtasm
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.
quietbritishjim
> > 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.
sgustard
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].
jakeinspace
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.
_ZeD_
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.
Diggsey
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.
chipsrafferty
I don't read documents online. I use applications.
dalmo3
'Member the 80s?
1-more
"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.
anotheryou
Agreed.
I'd suggest:
_Download Amaya here_, W3C's editor/browser
or
W3C's editor/browser: _Download Amaya here_
scary-size
The UK's Government Digital Services make a similar recommendation [1] in their accessibility guidelines.
Cthulhu_
We frequently reference this website / guideline for a reference of maximally accessible components / web design, it's really good. Not the prettiest (thick black / yellow borders on form components and the like), but accessibility trumps design.
dkdbejwi383
> accessibility trumps design
Good design is accessible by nature. Otherwise it’s just sparkling wank.
bigDinosaur
Not necessarily. For example, good design on a staircase doesn't mean that everyone ever can use it, and not every situation can involve alternatives. Accessibility is always relative and is not a binary state. As another example, not every video can be replaced by its transcript. Thinking in binaries leads to rejecting better-but-not-perfect solutions, such as not rebuilding something to be better for most people because it won't be better (or more accessible) for all people.
SilasX
In theory, yes. In practice, the typical specialist designer is going to optimize for things that come at the cost of accessibility.
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.
rpd9803
Ah the fallacy of 'universal accessibility'
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.
rerdavies
Their recommendation is very different.
W3c says:
Get *Amaya*
Read more about *Amaya*
The home office says: *Get Amaya*
*Read more about Amaya*
which seems much more sensible, but suffers from a different problem when used in context.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]
But both seem broken when the use case is hyperlinks in inline text.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*.
I get the objection. But the fix seems unacceptable: PiPedal is a guitar effects pedal that runs
on Raspberry Pi. Get Pipedal. Read the documentation.
Nuh uh. Not happening. I'm not sure what you would call that. Meta-grammatically incorrect? Whatever it is, it is not idiomatic English. 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*.
Perhaps. That is the actual text I used in my documentation. But, speaking from personal experience, the challenge is that it is often very difficult to nounify "click here" 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.
Which makes one wonder, what exactly is the foul that's
being committed when "here" is used as a pronoun for the
content that's being referenced? In this use case, there
is not an actual accessibility issue, because the the link sits inline within a sentence that provides all the context
that's necessary to indicate what to expect when you click.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*.
Is that really an accessibility issue? particularly when there's are buttons right above it that say [ Download ] [ Documentation ]
The actual metric that counts here is: how many times will people visit the Download page? And from that perspective there is significant doubt in my mind as to whether the following text will be better. To download PiPedal, visit the *Download Page*.
manarth
PiPedal is a guitar effects pedal that runs
on Raspberry Pi.
You can *download PiPedal*, and learn more
in the *PiPedal documentation*.
stavros
I can't believe you verbified "noun".
LocalPCGuy
> ...accessibility issue? particularly when there's are buttons right above it that say...
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!
Or like your last example, just link it slightly differently to emphasize the action: To *download PiPedal*, visit the Download Page.
hapidjus
PiPedal is a guitar effects pedal that runs on Raspberry Pi. *To download PiPedal, click here*.
*To read the documentation, click here*.
eightnoneone
This is the internet hill I'll likely die on. A call-to-action is one thing, but a page that only links the word "here" is a hard fail of an author not understanding the hypertext medium.
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.
retsibsi
Personally, I prefer the second example that they advise against. ("To download Amaya, go to the _Amaya_Website_ and get the necessary software.")
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.
xixixao
I like to include icons to indicate whether the destination is external or a file (file extension could work for files too)
cluckindan
Icons do nothing for screen readers, though. Use aria-describedby or aria-labelledby to add an ”external link” text suffix to the link text.
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.
hammock
The internal vs external link has already been solved by the little icon that Wikipedia et al use
guhcampos
Maybe it's because I'm old, but I have always instinctivelly thought of links as pointing to to nouns: links point to a place, and that place has a name, not a verb, maybe an adjective.
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.
rdiddly
Makes sense to me, maybe I'm old too. Although things get murky when the link kicks off an action like downloading something. But it's still a noun if you think of it as "a download" or "a downloader."
rehevkor5
Imperative would be appropriate for things like tutorials and howto pages.
jfax
I'm reminded of this post I read regarding links that read "I forgot my password". I thought maybe wording it as "click here if..." would improve that but I somehow intuitively knew that's not right either.
> 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.
wvenable
If "I forgot my password" is visibly a button then it's more effective than a link in that context.
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.
mitchdoogle
I would go for a verb that matches what the user actually is doing, i.e. "Reset Password". Also, I think a panel with a red or yellow background coming up after a couple of unsuccessful attempts to login with a complete sentence, "If you have forgotten your password, please visit this link to reset your password"
smallerize
Dragan Espenschied (despens) has an essay from 2022 about how link text has changed over time https://despens.systems/2022/06/button-pushes-you/ He identifies a shift from a call-to-action to button text describing the user: "Instead, they’re supposed to reconfigure the user’s state. Users have to accept the spelled out mantra and change their attitude before accessing the next piece of information."
fkyoureadthedoc
Assuming that all their examples are consistent and actually download "Amaya", I'd prefer simply the hyperlink [Download Amaya](http://link-to-file).
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.
rs186
I don't see any concern of accessibility in the article, and to my knowledge there is no accessibility issue in any of the examples.
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.
rerdavies
This seems inelegant:
Get *Amaya*.
Tell me more about *Amaya*.
xp84
Okay, but why not “Learn [More about Amaya]” ? More about Amaya is a noun phrase so it fits their standard.
rerdavies
My specific point of discomfort is that imperatives may be fine in menus, and lists, and buttons (where "click here" is never going to happen anyway). But as an inline hyperlink they seem idiomatically incorrect. "Learn more about Amaya" is still an imperative sentence.
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.
pooloo
Inelegant was the state of the Internet back then, I loved it.
1970-01-01
W3C missed the biggest problems (IMHO) with "click here"
* 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.
layer8
If a 10-character text link poses significant problems to be actuated, then something is really wrong with either the browser or the web page, not with the fact of having a 10-character link.
thesuitonym
> 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.
That was much less of a problem in 2010, and either way not really something for the size of your hyperlink to fix.
kerblang
Aye! Big fat isolated links win it for me. Can barely use touchscreens. Even with a mouse I am somewhat handicapped. The world has no sympathy. We need some kind of medical condition like "Slob Syndrome" to shame & guilt people with.
If you think about this from an accessibility point of view, screen readers for blind users present a linear view of a page. To escape from the linear view, they also typically allow users to access lists of elements like headers and links, out of context of their original position. If every link is labelled “click here” then you’re effectively removing non-linear access from those users.