311theandrewbailey2457/2/2025, 11:39:12 AM w3.org ↗
Comments (245)
crazygringo · 4h ago
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 · 4h ago
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 · 2h ago
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 · 2h ago
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.
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.
layer8 · 42m ago
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.
rendaw · 4h ago
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 · 3h ago
Links are for clicking. Click here is superfluous noise.
wvenable · 1h ago
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.
mitchdoogle · 48m ago
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
cube00 · 12m ago
> I have this fight with some developers all the time.
Please consider reading the rest of this thread before you keep fighting developers to do it your way.
After that if you still want "click here" that's your call but at least be open to better alternatives rather this dismissing this discussion.
wvenable · 10m ago
I'm not specifically talking about "click here". I'd say it has it's place sometimes but it's rare. But I 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 a less obvious than it appears.
mat_b · 36m ago
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.
Dylan16807 · 53m ago
Sometimes you need a placeholder. Think of it like a physical button where nothing is written on it and the description is next to it.
madeofpalk · 2h ago
> accessibility decrease accessibility
accessibility is usability. build products that are usable by people. that's all.
hombre_fatal · 4h ago
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.
rovr138 · 2h ago
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...
Izkata · 2h ago
> 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.
rovr138 · 49m ago
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.
crazygringo · 39m ago
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.
theteapot · 14m ago
In contrast, using descriptive link text does seem extraordinarily easy.
cube00 · 23m ago
> 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 · 17m ago
Do you use `aria-label`, then?
xanrah · 4h ago
I'm sorry, should we design websites around SEO, or should search engines just use context properly?
echelon · 4h ago
Search engines and websites are going to be subsumed by LLMs, so it's not like this argument matters anymore.
bigbuppo · 2h ago
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.
bee_rider · 2h ago
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.
bigbuppo · 1h ago
As best I can tell, your typical person here doesn't tend to hang out with normies, which definitely skews things.
echelon · 47m ago
> The general consensus is that the dislike of AI is so strong
This is such an echo chamber. Most people love AI. It's one of the fastest growing types of content across all social media.
The news media is telling us we hate it (eg. John Oliver, 404 Media), but this is not the mainstream consensus. Views and likes don't lie.
"Normies" think this technology is magical. Some organs of the traditional news media are trying to skew their opinions.
c22 · 2h ago
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.
tgsovlerkhgsel · 33m ago
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.
cube00 · 19m ago
That's not a fair comparison.
Using accessible link text doesn't cost the same as adding an automatic opener to every door in a building.
kqr · 4h ago
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 · 2h ago
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 · 4h ago
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 · 4h ago
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.
nayuki · 3h ago
> Ideally browsers would have a shortcut to enter a text selection mode
They do - Firefox has the option "Search for text when you start typing". I have it enabled for decades.
quietbritishjim · 4h ago
> > 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 · 3h ago
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].
1-more · 2h ago
"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.
layer8 · 4h ago
I mostly agree. One terminological difficulty is that, depending on the website, most users don’t “click” anymore, but “tap”, so something like “see here” could be more universal.
anotheryou · 2h ago
Agreed.
I'd suggest:
_Download Amaya here_, W3C's editor/browser
or
W3C's editor/browser: _Download Amaya here_
1317 · 2h ago
I like "_To download W3C's editor/browser Amaya, click here_."
turboponyy · 4h ago
Yea, the examples are wrong, and I'd interpret them the same way.
The principle is something I agree with and try to abide by, though.
eadmund · 1h ago
It’s not really about clarity, or even about accessibility (although both of those are great!): it’s about what a Web page is. A Web page is a document which can link to other documents.
> Links should absolutely be verbs
No, links imply a verb: ‘get.’ Buttons imply another verb: ‘post.’ It’d be awesome if there were ways in HTML to indicate other verbs, such as put and delete.
> > Get _Amaya_!
> That... doesn't tell me how to get Amaya.
No, it doesn’t: it is a document calling its reader to action. That’s something a document does: it tells a reader how to do something, or calls the reader to do something. Clicking is just an artifact of a particular technology at a particular point in time (heck, I imagine most people nowadays don’t click, because they are using smartphones — they tap instead).
iLoveOncall · 1h ago
Yes and we all know that websites are not built to be consumed by humans, so this argument makes perfect sense.
robin_reala · 6h ago
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.
phkahler · 5h ago
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.
jchw · 5h ago
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.
raincole · 5h ago
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.
jchw · 5h ago
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.
raincole · 5h ago
I do agree "Click Here" is bad because you need to read the context to know what "Here" is, and for the accessibility reason my GP mentioned.
jchw · 5h ago
Hmmm. My first thought was they were avoiding the word "website" in this case so that it would make more sense if you were viewing it on paper or outside of a hypertext environment. But actually, that would make "Get Amaya!" and other such phrases equally awkward. Without the hyperlinks, they become a bit strange. So I guess that was probably not their reasoning.
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.
joelfried · 5h ago
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.
bornfreddy · 4h ago
I can assure that there were good and bad pages then, the same as there are good and awful pages today.
oneeyedpigeon · 5h ago
> 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.
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 · 5h ago
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 · 3h ago
it's true, but these are more fragile than simply having clear link text, especially over time as a site is maintained
MangoToupe · 5h ago
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 · 4h ago
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.
nodar86 · 5h ago
This sounds like a great idea, does anyone know a tool like that?
ano-ther · 5h ago
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 · 3h ago
But you’re not getting anything. You’re just surfing to the Amaya website.
cluckindan · 5h ago
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.
bmacho · 5h ago
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.
Vegenoid · 1h ago
From my naive point of view, this seems a very easy problem for screen readers to solve, especially with LLMs: if the link does not describe what it is, include context like the preceding phrase.
rerdavies · 5h ago
Sure. but who labels every link in there header as "click here"? A completely different use-case from inline hyperlinks.
stogot · 6h ago
That’s amsomething I had not considered that changes my mind on this
charcircuit · 6h ago
A screen reader should be smart enough to read out what the link is for.
hombre_fatal · 6h ago
How do you imagine that working? By reading surrounding text or by reading the URL? Those are worse experiences than descriptive anchor text.
You can use something like macOS VoiceOver right now to see how it behaves.
crazygringo · 4h ago
> By reading surrounding text
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.
account42 · 3h ago
It feels like the screen reader industry has somehow managed to bully the entire web into making things easy for them instead of improving their own software.
charcircuit · 6h ago
>By reading surrounding text
Yes, or it can summarize the text and explain what the link is to.
bluGill · 5h ago
LLMs attempt that, but their success is mixed - sometimes the summary is very bad.
DrewADesign · 5h ago
Imagine how long it would take to load a page of HN search results, or the table of contents of an online book, or a page with a lot of dead links, or a page with links to a whole bunch of non-textual content that it has to figure out is non-textual.
charcircuit · 3h ago
You don't need to load where the link is going. The base line is the context a sighted person would have when they see the "click here" link.
AlienRobot · 6h ago
If only there were 4 different HTML attributes[1][2][3][4] you could use to add a descriptive label to an arbitrary HTML element....
One would hope those work the same in every browser + screen reader + language combination, but alas, it is not so.
ndriscoll · 4h ago
They're not supposed to work the same in every browser. The user is supposed to be able to choose software that works how they want/suits their needs. You follow the standards and the user selects software that interprets those standards in their preferred way.
snickerdoodle12 · 5h ago
So maybe those user agents (the browsers and screen readers) should fix their shit instead. Crazy idea, I know.
cluckindan · 5h ago
They definitely should. However, those will be large investments, so at least JAWS and VoiceOver are going to be waiting for WCAG 3.0 before tackling that. NVDA is open source, so I guess you could help them out with it. ;-)
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.
snickerdoodle12 · 5h ago
The point is that it's not really my (or other web developers) their responsibility that some 3rd party tool is garbage. It's like designing your whole website around some esoteric browser's behavior that less than 1% of your users use.
Sure, sure, we need to accommodate people with disabilities. First step to get there is to make sure the accessibility software isn't trash.
cluckindan · 5h ago
I get where you’re coming from, but this garbage is not optional everywhere around the world. Not in the US, even less in the EU.
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.
snickerdoodle12 · 5h ago
Yes, and it's an embarrassment and a failure to legislate the right thing.
komali2 · 4h ago
So either fix it by changing the legislation, or fix it by changing the FOSS software... or do the only thing you can actually do right now which is implement websites in a way that's most likely to consistently work well with existing a11y solutions.
snickerdoodle12 · 4h ago
Yes sir, thank you sir, I will never complain about stupid laws again, sir.
Is this how you want these discussions to go?
komali2 · 4h ago
> complain
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.
snickerdoodle12 · 3h ago
You can implement your websites with accessibility in mind while also acknowledging its ridiculous how every web developer has to spend time on that because screen readers are terrible, and responsibility somehow got shifted to every web developer ever instead of the handful of companies making screen readers.
DrewADesign · 5h ago
After a couple decades of relying on pragmatic hacks and loose conventions while hoping developers would start to take accessibility standards seriously, most just seemed to give up hope and concentrate on making software blind people can actually use. And that happened, like, a decade ago.
donatj · 5h ago
What I have learned after years of working with accessibility experts is that screen readers are largely incapable pieces of junk that need to be lead around manually.
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.
snickerdoodle12 · 5h ago
The hilarious part is that we somehow wound up in a situation where the screen readers are useless pieces of crap but instead of fixing those every developer making a website is held responsible instead.
rpd9803 · 5h ago
As a developer you should be embarassed if your site isn't accessible to screen readers, its not exactly hard to add some aria roles and alt tags.
snickerdoodle12 · 5h ago
I'm embarrassed for the screen reader software for needing so much help.
jodrellblank · 3h ago
If you serve your UI as out-of-order HTML content abusing tables for browser layout, if you merge broken fragments of mismatched XHTML from a content management system to cobble a page together on the fly, if you hide items behind burger menus, if you make interactivity from CSS and minified Javascript to visually look like input boxes and buttons instead of using standard buttons, if you add overlays and blocks to stop people selecting or copying text, if you care nothing about tab order and keyboard shortcuts and image alt text, if you reflow text around images, if you name CSS identifiers with no semantic meaning, if you mix in arbitrary advertising and tracking and framework session state, why is a screenreader "a piece of crap" for not being able to magically infer a human interpretation of the page?
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?
snickerdoodle12 · 3h ago
My eyes, search engines and LLMs manage just fine. Screen readers are the odd ones out, and they haven't evolved in over a decade.
SoftTalker · 2h ago
The sad reality is that screen readers have a very small market. There isn't a lot of money to be made so not much innovation happens. Maybe with LLMs there will be a new approach. It's something they might actually be good for.
snickerdoodle12 · 2h ago
Right, and the insane part is that instead of this small market improving itself the burder is instead shifted to everyone else, even mandated by laws.
rpd9803 · 5h ago
The reason JAWS and Voiceover are to widely used is not because no one else has tried.
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'.
pacifika · 3h ago
Why would every client process the context to the link, when the author can do this once and add it to the link, that's much more efficient.
charcircuit · 3h ago
Because you can't trust people to do extra work themselves.
scary-size · 6h ago
The UK's Government Digital Services make a similar recommendation [1] in their accessibility guidelines.
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 · 6h ago
> accessibility trumps design
Good design is accessible by nature. Otherwise it’s just sparkling wank.
bigDinosaur · 5h ago
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.
rpd9803 · 5h ago
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.
SilasX · 4h ago
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.
rerdavies · 6h ago
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 · 5h ago
PiPedal is a guitar effects pedal that runs
on Raspberry Pi.
You can *download PiPedal*, and learn more
in the *PiPedal documentation*.
stavros · 6h ago
I can't believe you verbified "noun".
LocalPCGuy · 5h ago
> ...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 · 5h ago
PiPedal is a guitar effects pedal that runs on Raspberry Pi. *To download PiPedal, click here*.
*To read the documentation, click here*.
retsibsi · 6h ago
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 · 5h ago
I like to include icons to indicate whether the destination is external or a file (file extension could work for files too)
cluckindan · 5h ago
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 · 5h ago
The internal vs external link has already been solved by the little icon that Wikipedia et al use
guhcampos · 5h ago
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 · 1h ago
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 · 2h ago
Imperative would be appropriate for things like tutorials and howto pages.
jfax · 4h ago
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.
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 · 33m ago
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 · 3h ago
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 · 6h ago
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.
1970-01-01 · 6h ago
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.
thesuitonym · 5h ago
> 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.
layer8 · 5h ago
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.
kerblang · 5h ago
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.
rerdavies · 6h ago
This seems inelegant:
Get *Amaya*.
Tell me more about *Amaya*.
pooloo · 1h ago
Inelegant was the state of the Internet back then, I loved it.
seanwilson · 4h ago
It's worth emphasising that if something like "learn more" does work fine for non-screen-readers (like for a call-to-action button at the end of a section, which makes sense to me), you can add extra text just for screen readers so it reads something like "Learn more _about Amaya_" only on screen readers (via aria-label or a CSS class that hides text).
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.
mmaunder · 4h ago
Ah I remember this when it came out. At the time the web was rife with click-here links. This had a huge effect on solving the problem. Might have appeared on Slashdot.
latexr · 6h ago
The rule I follow is to write in a way that if all links were removed, it would still make sense. So “click here” never happens, because you can’t click text which isn’t a link.
With that singular idea in mind, everything else falls into place naturally.
orthoxerox · 4h ago
It's not the best option for "action" hyperlinks, but I prefer it to making them look just like "information" hyperlinks.
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".
scosman · 6h ago
Lighthouse also warns against generic link text, like “Learn More”. It’s one of the few lighthouse warnings I just ignore.
mrweasel · 6h ago
How about changing the text ever so slightly, so rather than just "Learn More" it's "Learn move about X"?
scosman · 5h ago
There's a section with a nice header making it's clear it's about X, a paragraph with details about X. Adding redundant text in the button isn't improving design. "Learn more about Synthetic Data Generation" is a truly gnarly button. I have played with making the entire section the link, which makes lighthouse stop complaining, but is lousy for providing an affordance to the user that it's an action.
carlosjobim · 6h ago
Consider a product listings page, with a "Buy" button/link next to every product. Should those links be changed to differ from each other? Google Lighthouse sure thinks so, so it's better ignored.
mrweasel · 5h ago
Fair point, no you're right that would be a bit silly to have "Buy X" instead of just "Buy". I would argue that that's the label of a button, not a link though.
Cthulhu_ · 6h ago
In which case you ignore people with screen readers and search engines, too.
thesuitonym · 5h ago
Learn more is perfectly descriptive for people with screen readers.
scosman · 5h ago
And combined with resulting page, perfectly descriptive for search engines.
theletterf · 1h ago
A similar a11y battle is positional language, for example" "The image below" is positional language that might not mean anything to visually impaired users or folks using different layouts.
pacifika · 3h ago
This is a well researched areas with subject experts, our opinion is large irrelevant.
briandilley · 59m ago
None of this matters, considering that "click here" converts better by a long shot.
lysace · 15m ago
Got any data on that?
flessner · 6h ago
I get it that "click here" is not descriptive, but so is simply linking "Amaya". What is it? A person? A fruit?
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"!
Aardwolf · 5h ago
In the example "Get Amaya!" that they give:
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.
afandian · 5h ago
This advice distinguishes between the form (a link or button) and the content. I think it makes sense because you had other ways of knowing that it's a link than the content (underline, blue text, button border).
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.
dsr_ · 6h ago
_Tell me more about Amaya_
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_
Mordisquitos · 6h ago
> _Tell me more about Amaya_
> 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.
ashleyn · 5h ago
Back in the days when Google was still driven largely by Pagerank, I remember googling the phrase "click here" for shits and giggles. The top links were for Flash player, Silverlight, and Java. Meaning that these were the most common links for the text "click here" - i.e. "Need Flash? Click here." Relic of a dark age where nothing was accessible and the performance didn't matter.
sherburt3 · 3h ago
Always annoys me when people attempt to frame their personal preferences as a codified rule rather than a recommendation. All the examples seem fine with some being marginally better than others.
smjburton · 5h ago
Another benefit of using text other than "click here" is that it's helpful for web crawlers too. Google, Bing, and other crawlers use link context (e.g. "lawn care in new jersey" vs "click here") to establish authority/relevance for the site being linked to. The closer the context of the link, the more authority a website (generally) gets for that topic.
ogou · 5h ago
These are good recommendations from a usability and accessibility standpoint. But, marketing managers will bulldoze over all of it. These links are also Calls To Action in the marketing world. They will choose the most clicked version, which is usually the most simplistic and obvious. Many years of A/B/n testing has shown this to be true.
iammrpayments · 1h ago
This. I’d never do this on a landing page it would cause a lot of lost sales.
WickyNilliams · 5h ago
A compromise is to add visually hidden text to supplement, or use aria-label to override the accessible name of the link
txdv · 5h ago
click here to subscribe
kleiba · 6h ago
I remember that I often got confused in the early days of Wikipedia because the way they use link text was different from what was common on the web back in the day.
swyx · 1h ago
alternative proposal for 2025 update: Don't use "get started" as button text
johnisgood · 4h ago
> To download W3C's editor/browser Amaya, click here.
"click here" should be a direct link to the latest version. You click on it, it should download the latest version.
t1234s · 4h ago
If you find you are having to put instructions in your UI like "click here" you may have to rethink it to be more obvious. You don't want make your users have to think.
nlawalker · 4h ago
Somewhat related suggestion for other media like emails, docs, and chats:
Ctrl-K is the almost-universal shortcut for “insert hyperlink”, which is strongly preferred by everyone to a 237-character Sharepoint URL.
jasonlfunk · 6h ago
The verb seems pretty important to me…
————-
Learn more about [the browser]
Never hear about [the browser] again
Those links will do very different things.
yard2010 · 3h ago
Remember when googling "click here" led to the acrobat reader download page? I member!
kevinsync · 4h ago
My stomach is churning already knowing I'm about to type a short-sighted hot take related to LLMs, but I do wonder what a screen reader would look like that could provide a "summarized" version of any given web page (assumingly via LLM). Basically allow the user to swap between the full page rendered with current methodology / presentation of content and links, and a version of the same page with a summarized version of the text content + a collated, deduped section of actions found in the content.
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.
carlhjerpe · 4h ago
When we can run our own models that are good enough on local hardware (practically) it'll really take off, I believe AI accelerators in end user electronics will revolutionize how we utilize computers.
> 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
nikolayasdf123 · 5h ago
I am found of Apple content design has "Learn more..." links at the end of paragraphs. Those look very consistent and look well
bArray · 6h ago
I disagree. I think we need to make it clear that following hyperlinks should always be a cognitive choice.
> 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.
Cthulhu_ · 6h ago
This is very much from a sighted person's point of view. When you use screen readers, you can switch to a 'links' navigation mode and only go through links, in which case all you'd hear would be "click here", "Amaya website" and "Amaya".
I don't think this is right. The WCAG allows for "programmatically determined link context" which includes text surrounding the actual link. "click here" is bad but "Amaya website" or "Amaya" are fine.
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.
bArray · 5h ago
> This is very much from a sighted person's point of view. When you use screen readers, you can switch to a 'links' navigation mode and only go through links, in which case all you'd hear would be "click here", "Amaya website" and "Amaya".
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>
The user would hear "Amaya Website" and would then have some ability to also hear the link context. For pages missing the context windows some attempt could be made to create one automatically.
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.
I don’t think either of the suggested options delivers the best possible UX. Copy of course depends on context, but „click here“ is never justified as the best alternative.
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.
bArray · 5h ago
I think it really depends on the context. In a news article it rarely makes the content better, but in a documentation wiki, the context can be everything. I think we are fooling ourselves to suggest that there is zero nuance and that there is a 100% correct approach always.
hnlmorg · 6h ago
Best:
> 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.
LocalPCGuy · 5h ago
I would even say you could go with if duplicated words is an issue:
You can [get the Amaya Browser] from the download page
hnlmorg · 23m ago
Nice refinement there.
bArray · 5h ago
I still think that the missing context is an issue. Imagine the page is some 10k words, by the time you get to the bottom, you might not remember what "Amaya" is. So just saying "Amaya's download page" tells the user that it is a download, but nothing about what it is a download for.
I 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.
hnlmorg · 24m ago
Yeah, context matters. If it’s a Amaya product page then the context is already there. But if it’s a large article that meanders across a few topics, then your approach would be better. Though in that scenario I think you’re better still by directing people to a product page instead of a download page.
_Yguy_ · 1h ago
But... why?
seydor · 4h ago
"click here" links convert well, so people will use them
lucaspauker · 2h ago
This seems like dogma
iLoveOncall · 1h ago
They don't take their own (bad) advice. They have a "Learn more" link on their homepage: https://www.w3.org/QA/IG/
Anyway, I've learned long ago to ignore UI and UX advice coming from websites that look like theirs.
bitwize · 2h ago
It's 2025. HTML is, first and foremost, a GUI toolkit. People have forgotten how hypertext works.
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.
bravesoul2 · 5h ago
Feels like REST. Use nouns for the path (like the link text)
racl101 · 5h ago
# This is a loop that runs n number of times
ceejayoz · 6h ago
I used to make websites for internal use at a hospital by docs.
“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.
No comments yet
guerrilla · 6h ago
Okay but it doesn't say why. Why should one leave verbs out?
One reason they omit is that, by default, bookmark text is (was? I hardly bookmark any more) the text of the link. So, if you don't curate your bookmarks carefully, you get a folder full of bookmarks called "Click here!"
xnx · 6h ago
> bookmark text is (was? I hardly bookmark any more) the text of the link
I'm not sure I've seen this behavior. More commonly, it is the <title> of the page.
Cthulhu_ · 6h ago
Based on the comment I'd expect an "add link to bookmarks" entry in the right click context menu, but I don't remember ever seeing it. It makes sense to use the link text in that case though, else the browser would have to access the underlying webpage to fetch the title. Which shouldn't be a problem, but at one point some web apps were broken and did destructive actions on GET requests, and Google Gears tried to optimize the internet by prefetching webpages... which caused some whoopsies.
But, thankfully, web developers and web technology improved since then.
JadeNB · 6h ago
> Based on the comment I'd expect an "add link to bookmarks" entry in the right click context menu, but I don't remember ever seeing it.
I just checked, and desktop Firefox still offers it. At least, version 138 on macOS does.
JadeNB · 6h ago
I think it depends on how you get the bookmark. As far as I can tell, on mobile Firefox (the mobile browser I have easily to hand), you can only bookmark the page you are currently visiting, where the default bookmark title is the title of the page. But, on desktop Firefox, you can also create a bookmark directly from a link, in which case the default bookmark title is the text of the link. This makes some sense to me, since you probably wouldn't want the act of bookmarking a link to fetch the linked page just to find out its title.
xyst · 5h ago
I suppose the reason this is posted here:
`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.
piqufoh · 6h ago
From the bottom of the page;
> contributed Sep 2001 by Aaron Swartz
Thoughts
-- this advice is 24 years old (and I think largely ignored)
Yes, this was common web design advice in the mid 90s, though often people's first response was to simply replace "Click here to..." with "Follow this link to...", which was almost as bad.
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.
piqufoh · 6h ago
Aaron's suggestion (which seems to have been lost?)
"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.
netsharc · 6h ago
Yes, most people understand how to navigate around the jankiness...
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!"
stavros · 6h ago
I somehow think it would be more janky if the "exit" or the "preferences" items were in some random menu. I've never cared that "exit" doesn't seem to fit with "file" because it's always seemed more convenient for me that it's always in the same place.
netsharc · 39m ago
Yes, it's janky but familiar. On the phone you'll see a "Click here" and know to use your thumb to touch the area of the screen to do whatever action is behind that, on the text-based browser you know you can tab to that "Click here" text and hit Enter to navigate. If a kid saw this you'd have to explain to them the historical context of desktop computers and mice.
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?
ceejayoz · 5h ago
I mean, on a Mac, there's always a menu for the current app as the first item, titled after the app. If I want to quit Slack, I open the Slack menu. Which makes a good amount of sense.
AlienRobot · 6h ago
Meanwhile, on GNOME, there is no standard menubar so good look figuring out which one of the icon-only buttons in the headerbar has the dropdown menu with the action that you want.
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.
xnx · 6h ago
> 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.
rezonant · 6h ago
Which is also inaccessible (and goes against WCAG [1])
you shouldn't make things a link without decorations tbh
when hn could use a more distinct style for it
jkestner · 5h ago
And Nielsen had plenty to say about that too.
xnx · 5h ago
Indeed. Craigslist seems to be about the only site out there that hasn't fallen for every dumb design fad of the past 30 years.
px43 · 6h ago
He was 14 when he wrote that.
reddalo · 6h ago
We lost him too soon.
stogot · 7h ago
I actually prefer what they don’t recommend, and I don’t know why
lionkor · 6h ago
Me, too. The way they recommend feels like a "link to a Wikipedia article", not a call to action
empiko · 6h ago
Yeah, Wikipedia, but also many news sites use this style. It is mostly not a call to action, but additional optional information you can check out. That's why it feels wrong to use it in these cases. I think that some of the examples are outdated compared to how people format the web nowadays.
mannykannot · 6h ago
I do too - it tells the reader what they have to do in order to bring about the desired result, more directly than do any of the alternatives.
chungy · 6h ago
Same here. This is just a style guideline that W3C has no real business in determining.
sham1 · 6h ago
Well good thing that this style guide is just what W3C considers best practices and is not a standard.
> 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 · 6h ago
We shouldn't be so sensitive.
> [Our published tips] should not be seen as anything else than informative bits of wisdom, and especially, they are not normative W3C technical specifications.
jxjnskkzxxhx · 6h ago
Exactly what is wrong about "to do XYZ click here"?
alabhyajindal · 6h ago
From the suggestion email¹:
> "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.
Sounds equivalent to saying we shouldnt the words "he" or "she" because some people identify with neither. Exclusionary towards people of different mouse abilities.
jxjnskkzxxhx · 2h ago
Towards differently abled devices would've been funnier wording.
jaas · 6h ago
The idea is that some people don’t click - that refers mainly to people using a mouse, and many people are not using a mouse. So it is overstating information about what to do.
micromacrofoot · 6h ago
it's a little pedantic, but hyperlinks should describe what you get when you click on them
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
baggachipz · 6h ago
Counterpoint to the other opinions so far:
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.
Cthulhu_ · 6h ago
For sure; as other commenters pointed out that "click here" is unnecessary, as you can assume people know how links work. That is, it's not a call to action, unless the CTA is to "read more" about something or to "go to" a download page. But the action is to navigate, nothing more. If the action is to do something else, like start a download or submit a form, it should be a button.
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.
0xbadcafebee · 6h ago
I like it when pages tell me to "click here". It is clear and direct communication that doesn't assume I will infer exactly where I'm supposed to click for what thing. Not everyone sees or intuitively understands things the same way you do.
eCa · 6h ago
> Not everyone sees or intuitively understands things the same way you do.
That is true. And some people don’t see.
0xbadcafebee · 2h ago
I'm fully aware. I grew up with a kid who was almost blind.
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
Except we see here a great example of why this is wrong. We could tell a sighted user to click here, and simultaneously add alt-text that describes "this is a hyperlink which downloads the software". (which, by the way, would also help sighted people!!) An author drafting the link could choose what text is shown for the link, and what (if any) is shown for the alt-text. It doesn't have to be confusing.
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.
hammock · 5h ago
You like being told what to do and not having to figure it out yourself? Pay me $100 here: 35bSzXvRKLpHsHMrzb82f617cV4Srnt7hS
layer8 · 5h ago
Depends on context. You don’t want every link in a Wikipedia article to be worded with “click here”, for 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.
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 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.
https://www.w3.org/WAI/WCAG22/Techniques/html/H33
https://www.w3.org/WAI/WCAG22/Techniques/css/C7
When using a mouse pointer, you also want that information as a tooltip.
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 a less obvious than it appears.
accessibility is usability. build products that are usable by people. that's all.
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.
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.
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.
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.
Therefore, the ``click here'' works best for me.
PS
- "_Get Amaya_" should start a file transfer.
- "Get _amaya_ over there!"
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.
> 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.
- 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_
The principle is something I agree with and try to abide by, though.
> 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).
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.
If you need to disambiguate or further clarify links, well, you should also set the title attributes too. That ought to help.
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'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.
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.
- 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.
I would still include more of the action, i.e., ”Get Amaya“ instead of ”Amaya“ as in the article.
Crucially: screen reader navigation is NOT the same as keyboard navigation.
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.
You can use something like macOS VoiceOver right now to see how it behaves.
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.
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.
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?
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'.
[1] https://design.homeoffice.gov.uk/accessibility/links
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.
W3c says:
The home office says: 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:
But both seem broken when the use case is hyperlinks in inline text.To use a concrete example, how should one rewrite the following?
I get the objection. But the fix seems unacceptable: Nuh uh. Not happening. I'm not sure what you would call that. Meta-grammatically incorrect? Whatever it is, it is not idiomatic English. 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" 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.
Is that really an accessibility issue? particularly when there's are buttons right above it that say 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.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:
Or like your last example, just link it slightly differently to emphasize the action: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.
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.
> 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.
https://mstdn.io/@mattskala/113188291223682980
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.
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.
* 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.
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.
With that singular idea in mind, everything else falls into place naturally.
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".
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"!
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.
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.
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.
"click here" should be a direct link to the latest version. You click on it, it should download the latest version.
Ctrl-K is the almost-universal shortcut for “insert hyperlink”, which is strongly preferred by everyone to a 237-character Sharepoint URL.
————- Learn more about [the browser]
Never hear about [the browser] again
Those links will do very different things.
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
> 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.:
The user would hear "Amaya Website" and would then have some ability to also hear the link context. For pages missing the context windows some attempt could be made to create one automatically.> 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.
I 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.
Anyway, I've learned long ago to ignore UI and UX advice coming from websites that look like theirs.
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.
“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.
No comments yet
Don't use "click here" for link text
https://news.ycombinator.com/item?id=41925658
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.
`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.
> contributed Sep 2001 by Aaron Swartz
Thoughts
-- this advice is 24 years old (and I think largely ignored)
-- Aaron Swartz (!)
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.
"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.
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.
Often very hard to tell what's a link when it's not underlined and non-blue colors (or no color) is used.
[1] https://webaim.org/blog/wcag-2-0-and-link-colors/
when hn could use a more distinct style for it
> 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.
> [Our published tips] should not be seen as anything else than informative bits of wisdom, and especially, they are not normative W3C technical specifications.
> "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
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.
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:
Except we see here a great example of why this is wrong. We could tell a sighted user to click here, and simultaneously add alt-text that describes "this is a hyperlink which downloads the software". (which, by the way, would also help sighted people!!) An author drafting the link could choose what text is shown for the link, and what (if any) is shown for the alt-text. It doesn't have to be confusing.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.