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.
To see our latest news, click here, or click here if you want to request a catalog. The latest board minutes can be found by clicking here. Click here for product documentation. If you have any comments about our web site, click here to email us, or click here to call. If you were confused by this click here, or click here to let us know it met your expectations. Click here to see how many people have visited our internet web site.
On the plus side, there was actual useful content on the web, rather than the content-free designs that popped up in the Web 2.0 era.
Something to keep in mind is that a modern web page would be virtually unusable by the standards of 2002 and a 1995 web page would have been virtually unusable without the "click here" links. Conventions have to be established. While those blue underlined links may have had some precedent among some computer users (e.g. many help systems of the era used colored text to highlight hyperlinks), they would have little meaning to someone who bought their first computer to get on that newfangled Internet thingy. So while I agree that they were a bad thing over all, they were a necessary stopgap.
It takes less than five minutes for a person to learn how to click on links. They're a different color and underlined. It's obvious they are special. Despite "UX" being a discipline that actually exists, we've actually gone backwards on usability in that nobody can figure out what's clickable these days. For example... all those greyed-out pipe-delimitted links at the top of this comment. Despite its ubiquity for about 15 years now, at least once a month I have to teach someone that the ubiquitous three line "hamburger" menu is clickable.
Someone tell Wikipedia please, they have a weird sort of moving/hidden hamburger that floats which I've not seen anywhere else, I wonder if there's public stats on activity following the layout update.
Whereas if you removed the "click here" tags and associated text, you'd be left with:
> See our latest news, request a catalog. The latest board minutes. Product documentation. If you have any comments about our web site, email us, or call. If you were confused by this, let us know it met your expectations. See how many people have visited our internet web site.
It's okay, though, you would most certainly have the main navigation menu repeated several times on the page. The new web master is learning this thing called Balinese Caligraphy or JavaScript or something along those lines and have even added a new drop down menu in two spots so it will be even easier to find the link to the page with the contact page and info on how to send us a fax to get a catalog mailed to them.
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.
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.
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.
I don't suggest "follow this link" either, or even anything that mentions a link. Obviously it's an extreme example involving traditional prose, but think for example of a Wikipedia article: the links in Wikipedia articles are natural and obvious. Links in navigation panels and navbars also follow this pattern generally speaking: like at the bottom of Hacker News itself, "Guidlines" "FAQ" "List" ...
In cases where you want to do something involving a call to action, like "Click here to download", I think "Download" or "Download now!" are better. And hell, often times CTAs are better as buttons (at least visually) than links anyways.
That said, it's not like I follow this religiously. But anyway, I think it's highly likely people are taking away the wrong message here.
I guess to put it another way, it's not that the terminology we use is dated or wrong per-se; I mean sure, people tap on hyperlinks more than they click on them these days probably, but the point isn't that the terminology is dated or isn't understood. It's that well-structured hypertext can avoid it altogether.
I see your point, but I'm less anti the use of "click".
Firstly because of the acceptance of "click is to web as dial is to phone", that the term "click" as a verb meaning to follow a navigation link or interact with a button, or generally interact at all with something on a website or app. I think this is useful and should be encouraged [0].
Secondly because it was used in the first place because it was very clear instruction. "Download" by itself assumes that the user knows how to download, and if the UI element isn't clear that it's a link or a button (or interactive) then that's not obvious how that should happen. "Click here to download" is much more clear, obvious, and helpful. I think it was old-school SourceForge that had "Download" buttons that didn't look like buttons, and ran adverts that had very prominent "Click here to download" buttons, and that ended up being very confusing and getting a lot of people to click on shitty ads.
Thirdly, and purely as a matter of personal taste, I don't subscribe to the design philosophy that less is better. I prefer clear instructions to ambiguous ones, even if that means more words. The impulse to surround everything in whitespace, remove scroll bars, and make it look pretty at the cost of usability should be discouraged imho. A button should look like a button. It should be clearly labelled with what it does, or what you need to do to make it do the thing. I realise I'm in a minority here, but that's not unusual.
[0] though maybe the new verbal usage of "I'm double-clicking on this concept" to mean supporting it is probably a bit much.
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.
> 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.
Of course I exaggerated it on purpose, but think about it:
Remember, in ~2010, it was a trend to add toolbars to Internet Explorer (it was called BHO I think?)
These toolbars were changing the search engine for Bing, Yahoo, etc. This is why they were called "Yahoo toolbar".
But then, came Chrome, which was bundled among other in:
- Adobe Flash Player updates
- Java Runtime Environment (via Oracle)
- CCleaner
- Avast and AVG installers
- Many download portals (e.g., Softonic, CNET Download.com, SourceForge)
So, the objective of Chrome, instead of replacing the search engine with a toolbar, it was to do it by installing a new app, but this is exactly the same goal. At the end, the goal of Google was not the save the web, it was to replace the search engine and display ads on these pages (+ make sure that the targeting + rendering is under their control).
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.
- 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 already kind of get this with extensions that let you browse from the keyboard (e.g. click a link without using the mouse) like Tridactyl. It lets me know when clickable elements are not detected as clickable, and, sadly, this happens quite a lot.
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.
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
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.
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.
I find the accessibility concern a much more compelling argument than this article’s focus on “calls to action”, which is primarily a marketing/engagement concern and one that therefore earns my automatic distrust.
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.
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.
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.
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.
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.
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.
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.
The ADA is very good legislation and something I'm very thankful for as someone who is completely able-bodied. The reality is private entities won't do jack shit unless you force their hand and threaten them. It sucks it's that way, but that's the reality we have to acknowledge.
And, I benefit greatly from accommodations around accessibility. Both in the physical world and online.
Great, so force the hand of the screen reader makers to do a better job, or force the makers of browsers to integrate them properly, instead of burdening everyone else by piling workaround upon workaround.
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.
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.
I don't loop within loops, I free memory after I allocate it, and I add aria tags to html elements. I don't really see the big deal, just seems like a normal part of the job.
If you just do stuff without reflecting on why it's necessary that's... odd. Two of these examples have actual reasons on why they're necessary, the third is because screenreaders are crap.
I'm not trying to be difficult, but how is it any different than matching what an HTML parser (such as a web browser) expects by making sure you close your tags?
Excellent example because web browsers will render most documents just fine if you don't close your tags. Because they care about being compatible with websites that aren't perfect, and they consider it their job to render all websites that exist. Instead screen readers expect you to change your website instead of working with what's already there.
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.
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.
While that would work in many situations, I think the number of edge cases would be too great to make it reliable as a primary mode for communicating meaning in an accessible interface. As an alternative assistive feature? Sure. Something to rely on? I'll believe it when I hear it.
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.
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.
It's not adding roles/alt tags/etc. that's the issue. It's finding out that a screen reader doesn't support the ARIA markup (from the ARIA spec) that you are trying to use [1]. -- For example, using aria-describedby on an img doesn't work on most browser + screen reader combinations [2].
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?
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.
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.
> They don't try to be helpful, they only do exactly what they are told.
This is how software should work. Attempting to be "helpful" usually makes things worse. Doing exactly what it's told makes it predictable and usable.
Just look at how much of the HTML 5 spec is a nightmare of parsing rules for handling malformed SGML. Look at how it got there - all the invocations of Postel's law justifying attempting to handle malformed input in "helpful" ways, until things were eventually such a compatibility nightmare that a new spec was created to give precise rules for parsing every single input the same way. "Helpful" was specified away, because it was so broken.
Now if only screen readers provided consistency in following rules, too. They're not in a great state, but your attempted solution is worse.
> To download W3C's editor/browser Amaya, _click here_.
Is extraordinarily clear. I'll click the link and it will either download directly, or it will be a download page.
In contrast:
> Get _Amaya_!
That suggests a link to the Amaya website, not a download page. That's not effective for a download.
Similarly:
> Tell me more about _Amaya_: W3C's free editor/browser that lets you create _HTML_, _SVG_, and _MathML_ documents.
This is terrible. It's not about downloading, and "tell me more" is the command, but not linked! For all I know, the "Amaya" link goes to a corporate landing page, not the "tell me more" information I actually need.
The conventional uses on the web are totally fine:
> To download W3C's editor/browser Amaya, _click here_.
> _Download Amaya_, the W3C's editor/browser.
The idea that links shouldn't be verbs seems very silly to me. Links should absolutely be verbs, when they involve an action like downloading or finding out more. Obviously that's different from "reference" links like in Wikipedia, where you're finding more about a topic.
And "click here" makes it exceptionally clear that a link isn't merely a reference link, but an action link. When I see:
> Get _Amaya_!
That... doesn't tell me how to get Amaya. That tells me "Amaya" is a reference link, not a download link.
Use a screen reader. Tab through the links. All you hear is, "click here." That's not helpful.
Build a search engine. What information does "click here" offer your index?
I agree with you that verbs don't seem all that problematic. Except when the verb is click and the object is here. I can stomach a link whose text is "Click Here to download Amaya," but if the link is literally just the two words, "click here," it is indistinguishable from others in many different contexts.
The problem here is that the screen reader will just read the link text and not the contract around it. In this case, the correct examples proposed by W3C will read just as "Amaya”, which are almost as unhelpful.
Even the WCAG level A success criteria clearly states:
The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.
together with its programmatically determined link context really is the operative phrase in this quote. I would encourage you to actually read the examples on the page you link to - several of them announce just one or two words.
"Download Amaya" as the link text makes the most sense in your scenario. A link that just says "Amaya" isn't any better than one that just says "click here" -- neither is sufficiently conveying that clicking the link will download the software.
Making the entire thing a link is IMO the clearest option if you just want someone to download your app, but doesn’t work as well when you want a list of software and links for details.
A list where: “Click here” to download “V 16.23.4” has two links one of which gives info on the download and their other starts a download is fine, especially if the info page also has a download link.
As a user, I wouldn’t intuitively understand that “click here” is going to download a file and “V 16.23.4” is going to give me information. I’d assume they were both download links and be confused why there are 2 and which one I should click.
If the download link is on the information page, a simple solution is just to send people to the information page where they can download. I tend to prefer that anyway. I find premature direct download links to be jarring where I’m not expecting it.
Isn't this also better from a Fitts' Law perspective (for sighted mouse users) - simply because more text makes the "target" larger? (Not that I've seen a desktop browser doing anything sensible with artificially boosting hitbox sizes since the late 1990s...)
I never understood why the visually hidden has not been incorporated into the CSS standard proper (something like display: visually-none). Instead the standard is effectively recommending authors use a hack to do what is a very common pattern.
It's a hack either way. Screen readers really should support the title attribute like they do for image links; or maybe HTML should have had an alt attribute for <a href> as well.
When using a mouse pointer, you also want that information as a tooltip.
At one point does accessibility decrease accessibility? I'm all for making improvements in the name of accessibility, but not so much about making things worse to support the least common denominator of screen readers. If people are going to need to change their behavior, wouldn't it be better to suggest some aria annotation instead?
It is an interesting point, because in 2001, what is a link was usually clear and standardized: blue, underlined, often both, like on the article page. Now, just look at Hacker News, only the links in comments are underlined, and they have no special color, you have to mouse over if you want to know. And Hacker News is not in any way special in that regard.
So I would argue that "click here" is more relevant now than it once was. Same idea for buttons by the way. They used to look like, well, buttons, often with a 3D look. Now, there is often no real difference between a button and regular framed text. It means we need more context to guess which is which.
I have this fight with some developers all the time. Users are dumb, impaired, fearful animals and if you don't spell it out to them they have no idea what to do. "Click here" might be superfluous noise but that doesn't mean it's not necessary (sometimes).
Put something better. "Visit our site", "View Results", "Download File", "Next Page". Almost anything is better than "Click here". "Click here" is the result of laziness - think about what the button does for a couple minutes and you should be able to come up with better text
If your users have really never used a web browser before, and you are absolutely sure they are using a mouse on a desktop computer, and you can't imagine them ever using a mobile phone, and purposefully want to confuse them if they do, then phrase it like:
Click this hypertext link: <a href="more-info.html">More Info</a>
Put the device specific call to action outside of the link, and make the link say what it links to, not what physical action to take to follow the link.
Anyway, mobile phone touch screens don't click. Saying "click here" is like using a floppy disk as a save icon.
Obviously for the same reason you also should not say "touch here" either. Touching your desktop computer's screen doesn't work unless you have a touch screen, which is rare.
That's the point, why saying "click here" or "touch here" is always wrong.
I dare you to use a different icon than the floppy disk for save. People still use "click" terminology for tapping things on their phone and I doubt that will ever go away.
> If your users have really never used a web browser before, and you are absolutely sure they are using a mouse on a desktop computer, and you can't imagine them ever using a mobile phone
...have you ever used a mobile phone? Clicking is the only action you can take on one.
Clicking with your finger is called "snapping" and you can't snap at traditional mobile phone interfaces and expect that to work. Touching with your finger on a screen makes no sound, not a click, not a thump, not a knock. It's silent, short of haptic or audio feedback, and that's not your finger clicking, it's the phone. That is my point. That's why they call them "touch screens" not "click screens". Do you disagree, or do you touch your phone so violently with your finger that it emits a click? Maybe that is the glass breaking!
Or is your entire point that you think it's actually a good idea to put the words "click here" in links? Then explain why?
I'm not explicitly talking about just "click here". I'd say it has it's place sometimes but it's rare. But a lot of developers have issues with redundancy or explicitly spelling things out for users for things that are "obvious".
With enough experience you learn that what is obvious is less obvious than it appears.
It's not superfluous noise at all. As a user of the World Wide Web I personally find "click here" to be easy to quickly identify and understand. When I see the underlined "click here" I quickly know exactly what I need to do.
And you don't find links with the underlined name of where they lead to be "easy to quickly identify and understand"?
Are you saying that you need links to say "click here" in order to understand what to do?
Then how did you manage to navigate to this discussion and press the reply link, which did not say "click here"?
Do you not think this looks like superfluous noise at all?
click here for mat_b click here for 1 hour ago | click here for undown | click here for root | click here for parent | click here for prev | click here for next click here to collapse [–]
Everything in user interface design is a trade-off. There are many usability and accessibility and readability and design factors that every interface designer must balance and trade off against each other.
So of course usability can decrease usability, readability can decrease readability, accessibility can decrease accessibility, beauty can decrease beauty, and all those desirable traits can decrease each other, because there is no one single "technique" you just apply mindlessly to achieve any of those goals.
There are many many ways of achieving (and ruining) each of those goals, and you constantly have to balance and trade them all off against each other.
If somebody is so lazy and careless and poorly educated that they always use links saying "click here" as a solution to their problem of not being creative enough to come up with a better more descriptive link, I can guarantee you 100% of the time they are not going to give a flying fuck about aria or even have a clue what it is.
I think the links just need to be longer vs a couple of words.
We are used to small areas, but the problem is that you end up with 'click here', like in the example. But if you linked the whole text, it's basically the same thing as adding aria.
IMO, most cases that I see using aria seem like a fix after the fact vs doing it the right way.
There are use cases for it, but in the case of the example, making the whole sentence a link would be good.
Regarding screen readers, you can have it read all links, which is why the 'click here' is an issue. So you want a balance. Change "for x, <a href=...>click here</a>" "<a href=...>for x, click here</a>"... ta-da?
You need to optimize for people using accessibility tools, but also for the people looking at the site...
> Regarding screen readers, you can have it read all links, which is why the 'click here' is an issue. So you want a balance. Change "for x, <a href=...>click here</a>" "<a href=...>for x, click here</a>"... ta-da?
No, you want the verb to be whatever "x" does or is for, not the action taken to get there. The action taken to get there is the same for all links regardless of what they're for. So this is a bad example simply because we don't know what "x" is so we don't know what a better verb would be.
It depends on x, right? For example, it could end up being, 'for learning more about Hacker news click here'.
I think that signals to visitor using screen readers and without, what that is and how to interact with it.
If someone with a screen reader is jumping through links, they'll get context for the link. A visitor not using it will see get the context since it's all highlighted together. Someone using a keyboard, the outline will highlight all of it.
I am just a keyboard user. I have no idea if this is the best way. But I think it gives the same info to everyone.
That's a screen reader problem and search engine problem.
It would be an extraordinarily easy for screen readers to have a heuristic that whenever a link is just "click here" or common variations like "tap here", "click", etc., to read the entire sentence containing the link. It's not exactly rocket science. Yes, you need an internationalized list of strings to detect. Also, if aria-label is present, just use that.
Likewise, search engines are great at inferring meaning from the page as a whole. I'm not going to change my link text for the benefit of search engines.
Screen reader heuristics are the wrong approach. If you want to use "click here", "download", "pdf", or something generic then use aria-label, aria-labelledby, or some other mechanism to give the additional context to screen readers and other assistive technologies. There's no need for any heuristics other than those in the specifications that the screen readers, web browsers, and web sites agree/conform to.
There may not be a surrounding sentence (e.g. in a "PDF"/"Download" link). The surrounding sentence may not add any/enough additional context, e.g. "You can click here for help." or "To view the article [one of many] you can click here.".
You then run into issues where 1) the screen reader/AT is overriding the ARIA/a11y markup on the page against WAI-ARIA and WCAG standards; and 2) you can end up with different behaviour on each screen reader, in addition to the places they already differ.
It's bad enough when web browsers introduced heuristics on form labels such that "name" + "label" fields were detected as a login form and other situations where bad heuristics were used and the web browsers overrode what websites were specifying.
It's not a "central dependency" that needs an "authority". It's just part of building internationalized software.
Shouldn't screen readers have intelligent heuristics to most appropriately convey context when required? Seeing as most of the web doesn't have accessibility annotations?
The general consensus is that the dislike of AI is so strong, that a large chunk of the population will disregard something if they even think it is generated by AI. Also, the LLMs need a continuous feed of new, original material to ingest or they'll be all thumbs.
While the long-running trend of SEO stuffing from low-value content farms has polluted search results for years now, Google didn't really care about fixing that problem because there's a perverse incentive to generate more ad revenue by making the first page results usesless. Who cares about doing the right thing? Daddy's got to get his quarterly numbers up. I should also note that those content farms were also early adopters of genAI as we know it today.
Infinite growth isn't a thing. Every cancer eventually kills its host.
Are you sure that’s the general consensus about AI? HN has a very intense relationship with this stuff, because we have hardcore boosters and hardcore skeptics. Among people I meet offline the feelings seem a lot weaker in either direction.
I see constant comments on social media complaining something is AI sometimes even when it’s not. Those commenters are all viewing it but they aren’t choosing it. And “likes” absolutely lie because there isn’t a “dislike” option.
If you are doing front-end web development then you really need to have some knowledge about accessibility, screen readers, etc. so you don't make simple/common mistakes. More so if you are involved in addressing accessibility issues for customers/your company.
I dunno, color blindness is brought up just as often here IMO.
On the whole I'd say it's a good thing because it means that the various awareness campaigns are working. Better that this kind of stuff is "overdiscussed" than not discussing it at all.
And besides, this focus has some useful side effects. For example, pages designed with screen readers in mind are also that much easier to interact with from scripts and other automation.
Screen readers are deterministic website or web application navigation applications. Building for screen readers isn't just for the disabled, it's for you, too. That will become infrastructure for testing and automation.
IMO that's the problem of the screen reader/search engine. It's a fine line between "accessibility" and actively making things worse (i.e. less accessible) for the majority just to cater to a small group of screen reader users.
That's similar to replacing all major doors in a building with automatic ones that can't be operated manually and take forever to open, despite the typical occupancy by wheelchair users being 0. Accessibility is great, but accessibility for few should not come at the cost of accessibility for most.
That's a programmed behavior of the screen reader and a limitation of the contextual awareness of the search engine. Apparently this has been an issue in the wild since at least 2001 so I don't know what to tell you.
I strongly dislike "click here" links because when I'm looking for a link, I want to read only the link-formatted words on a page to find the link I'm interested in. "Download Amaya" would be a great link. Just "Amaya" (unless leading to a page with information about Amaya, I suppose) or "click here" are not.
Scannability is one of the reasons my formula is to link a complete descriptive phrase, like “Read more about hrefs,” or “take a survey on meeting times.” Links can be long, and probably doesn’t hurt SEO.
I often want a second source to first check if that is trustworthy:
copy paste amaya while having to not accidentally click it is annoying, since often linebreaks and multiword names or company+product splits occur. Selecting and reading text should be easy. Navigating HTML should be wanted, not accidental.
Therefore, the ``click here'' works best for me.
PS
- "_Get Amaya_" should start a file transfer.
- "Get _amaya_ over there!"
sounds like "okay next site will be info dump before actual download", which is acceptable to gather trust like brand or imprint recognition over there instead of googling now.
Ideally browsers would have a shortcut to enter a text selection mode - this would also fix the annoyance of sites disabling text selection on certain elements.
The Newpipe app on Android has such a mode for Youtube descriptions.
> That suggests a link to the Amaya website, not a download page. That's not effective for a download.
In all their examples, the link is to the homepage of the Amaya website, not some download page (never mind the actual download).
It seems their message is watered down quite a bit by conflating the issue around "click here", which as other comments have said is an accessibility issue, with whether the text accurately reflects the target.
"click here" makes sense in that context, but links can be viewed in the screen reader rotor, where they just show up as a list of links out of context. aria-describedby can help out, but if you just make the text inside the link better then you can avoid having to do that.
Besides screen readers, using a single descriptive noun as the link text might help for maintainability in some situations. First, it reduces the chances of a given link accidentally getting copied to another section by an unscrupulous maintainer. Second, in case of a dead link with a non-obvious URL (like maybe some ancient sourceforge link to a now renamed project), the link text is an extra bit of information to remind you if and how the dead link should be updated (assuming no comment exists). I admit that's a pretty minor benefit.
A rule of thumb I've been following lately (when communicating in e.g. GH issues or Slack messages), is to use the title of the page where possible. Hopefully, the page title should reflect the page's content, and thus automatically works as a link title a lot of the time.
In your example, I would expect the download page of Amaya to be titled "Download Amaya", so my link can simply be "If you are interested, [Download Amaya]!"
Documents don't contain calls to action like "Download X" or "Tell me more about Y", so your argument falls down in relation to the examples presented by W3C.
It’s not really about clarity, or even about accessibility (although both of those are great!): it’s about what a Web page is. A Web page is a document which can link to other documents.
> Links should absolutely be verbs
No, links imply a verb: ‘get.’ Buttons imply another verb: ‘post.’ It’d be awesome if there were ways in HTML to indicate other verbs, such as put and delete.
> > Get _Amaya_!
> That... doesn't tell me how to get Amaya.
No, it doesn’t: it is a document calling its reader to action. That’s something a document does: it tells a reader how to do something, or calls the reader to do something. Clicking is just an artifact of a particular technology at a particular point in time (heck, I imagine most people nowadays don’t click, because they are using smartphones — they tap instead).
I mostly agree. One terminological difficulty is that, depending on the website, most users don’t “click” anymore, but “tap”, so something like “see here” could be more universal.
Am I the only one who is amused by seeing UIs fuss about using “tap” vs “click”? Is there anyone who has ever gotten confused and started looking for a mouse to plug into their phone because something said “click the X button” instead of “tap” it?
No, but for young people who only ever used a smartphone or tablet, it might be relatively unfamiliar terminology, and even when they do know what it means, may seem misplaced for how they use technology.
As an analogy, consider how you would feel if the instruction manual of your microwave oven (or other physical appliance) would instruct you to "click" its buttons. It's not that you wouldn't understand what to do or that you'd be looking for a mouse port, it's that the word wouldn't be the right one for the circumstance.
Incidentally, as a keyboard user I sometimes feel that way when there are instructions to "click" some UI button, but I will press the appropriate keyboard shortcut instead.
This sort of pedantic need for correctness at the cost of clarity seems to also crop up as businesses become increasingly corporate and expand their offerings.
“The best tires” becomes “the best vehicular solutions”
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.
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.
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.
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.
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.
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.
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.
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."
This is the internet hill I'll likely die on. A call-to-action is one thing, but a page that only links the word "here" is a hard fail of an author not understanding the hypertext medium.
I think of "click here" as stage direction mistakenly left in. When most authors write, they often don't write in a hypertext context. Instead of using a Markdown-like notation for links, they default to stage direction.
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.
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"
We should remember that UI conventions are mostly an arbitrary invention or are derivations of prior arbitrary inventions.
Users intuitively adapt themselves to the machine and developers adapt themselves to the users forming a feedback loop.
To put it another way: the meaning of language has probably been changed by so many websites and apps having an "I forgot my password" link. At least in that context most humans will adapt to understand the intent. Newer generations that have known nothing else won't even consider it to be worth their notice. In that sense there is also value in sticking to convention even if the convention makes no sense when considered in isolation.
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.
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."
My specific point of discomfort is that imperatives may be fine in menus, and lists, and buttons (where "click here" is never going to happen anyway). But as an inline hyperlink they seem idiomatically incorrect. "Learn more about Amaya" is still an imperative sentence.
I guess technically, "To learn more about Amaya, view the datasheet." is also an imperative sentence. But to my mind, it scans better as inline text. Not quite sure how to nounify that one either. And interestingly, inability to find the "learn more about" link on landing pages for products I'm interested in is a source of constant frustration for me. There should be a word for "something halfway between the the breathless lede on a landing page, and "here's a thousand pages of documentation". For hardware products, the "datasheet" is exactly what I'm looking for; there doesn't seem to be an equivalent for software products.
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.
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.
> 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.
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.
I mostly agree with the descriptions described there. However, sometimes a verb or verb phrase is appropriate, especially if it is "download", but then it should be a direct download link; the verb should be directly what it corresponds to and should make sense it context. Often a verb phrase would not be appropriate, though.
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.
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.
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.
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.
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.
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.
I don't see any concern of accessibility in the article, and to my knowledge there is no accessibility issue in any of the examples.
So who is w3 to say how people should and shouldn't use links? All that I see are just opinions, with no objective metrics/theories to back up their recommendations.
W3 should be in the business of setting up technical standards that go through rigorous processes, not creating nonsense like this.
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.
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".
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".
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.
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.
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._
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.
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.
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.
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.
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.
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.
This article is from a marketing perspective. It assumes that the goal of the web site is to get the user to click on the link. Not to offer the user the opportunity to get more detailed info if they want it.
You don't have to be marketing anything. When putting links in a website, you are calling the visitor to action - the action of viewing other content or getting a file.
Articles in the 90s would suggest webmasters to use "click here" as link text to let users know that a hyperlink is clickable. The advice kind of make sense since hypertext was new back then and users need that little bit of help to navigate.
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!"
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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 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.
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.
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.
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
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.
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!"
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.
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.
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?
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.
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.
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.
> [Our published tips] should not be seen as anything else than informative bits of wisdom, and especially, they are not normative W3C technical specifications.
Sounds equivalent to saying we shouldnt the words "he" or "she" because some people identify with neither. Exclusionary towards people of different mouse abilities.
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.
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.
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.
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.
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.
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.
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.
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.
This was the web between 1995 and 2002:
To see our latest news, click here, or click here if you want to request a catalog. The latest board minutes can be found by clicking here. Click here for product documentation. If you have any comments about our web site, click here to email us, or click here to call. If you were confused by this click here, or click here to let us know it met your expectations. Click here to see how many people have visited our internet web site.
On the plus side, there was actual useful content on the web, rather than the content-free designs that popped up in the Web 2.0 era.
Something to keep in mind is that a modern web page would be virtually unusable by the standards of 2002 and a 1995 web page would have been virtually unusable without the "click here" links. Conventions have to be established. While those blue underlined links may have had some precedent among some computer users (e.g. many help systems of the era used colored text to highlight hyperlinks), they would have little meaning to someone who bought their first computer to get on that newfangled Internet thingy. So while I agree that they were a bad thing over all, they were a necessary stopgap.
It takes less than five minutes for a person to learn how to click on links. They're a different color and underlined. It's obvious they are special. Despite "UX" being a discipline that actually exists, we've actually gone backwards on usability in that nobody can figure out what's clickable these days. For example... all those greyed-out pipe-delimitted links at the top of this comment. Despite its ubiquity for about 15 years now, at least once a month I have to teach someone that the ubiquitous three line "hamburger" menu is clickable.
Someone tell Wikipedia please, they have a weird sort of moving/hidden hamburger that floats which I've not seen anywhere else, I wonder if there's public stats on activity following the layout update.
Whereas if you removed the "click here" tags and associated text, you'd be left with:
> See our latest news, request a catalog. The latest board minutes. Product documentation. If you have any comments about our web site, email us, or call. If you were confused by this, let us know it met your expectations. See how many people have visited our internet web site.
Which imho is not any better, and arguably worse.
It's okay, though, you would most certainly have the main navigation menu repeated several times on the page. The new web master is learning this thing called Balinese Caligraphy or JavaScript or something along those lines and have even added a new drop down menu in two spots so it will be even easier to find the link to the page with the contact page and info on how to send us a fax to get a catalog mailed to them.
Click on of the following links:
See our latest news
request a catalog
Read the latest board minutes
Product documentation
email us with questions about our website
Call us
So a little indicator that these are links without "click here" and now the link text is very informative. But this would look like a menu.
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.
I can assure that there were good and bad pages then, the same as there are good and awful pages today.
There are good pages today?
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.
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.
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.
We don't dial phone numbers any more either, but the terminology remains.
I would suggest that "click here" is more concise, meaningful, and well understood than "follow this link" or alternatives.
I don't suggest "follow this link" either, or even anything that mentions a link. Obviously it's an extreme example involving traditional prose, but think for example of a Wikipedia article: the links in Wikipedia articles are natural and obvious. Links in navigation panels and navbars also follow this pattern generally speaking: like at the bottom of Hacker News itself, "Guidlines" "FAQ" "List" ...
In cases where you want to do something involving a call to action, like "Click here to download", I think "Download" or "Download now!" are better. And hell, often times CTAs are better as buttons (at least visually) than links anyways.
That said, it's not like I follow this religiously. But anyway, I think it's highly likely people are taking away the wrong message here.
I guess to put it another way, it's not that the terminology we use is dated or wrong per-se; I mean sure, people tap on hyperlinks more than they click on them these days probably, but the point isn't that the terminology is dated or isn't understood. It's that well-structured hypertext can avoid it altogether.
I see your point, but I'm less anti the use of "click".
Firstly because of the acceptance of "click is to web as dial is to phone", that the term "click" as a verb meaning to follow a navigation link or interact with a button, or generally interact at all with something on a website or app. I think this is useful and should be encouraged [0].
Secondly because it was used in the first place because it was very clear instruction. "Download" by itself assumes that the user knows how to download, and if the UI element isn't clear that it's a link or a button (or interactive) then that's not obvious how that should happen. "Click here to download" is much more clear, obvious, and helpful. I think it was old-school SourceForge that had "Download" buttons that didn't look like buttons, and ran adverts that had very prominent "Click here to download" buttons, and that ended up being very confusing and getting a lot of people to click on shitty ads.
Thirdly, and purely as a matter of personal taste, I don't subscribe to the design philosophy that less is better. I prefer clear instructions to ambiguous ones, even if that means more words. The impulse to surround everything in whitespace, remove scroll bars, and make it look pretty at the cost of usability should be discouraged imho. A button should look like a button. It should be clearly labelled with what it does, or what you need to do to make it do the thing. I realise I'm in a minority here, but that's not unusual.
[0] though maybe the new verbal usage of "I'm double-clicking on this concept" to mean supporting it is probably a bit much.
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.
> 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.
[flagged]
Describing bundled adware as "fostering a sustainable ecosystem" while portraying Chrome as "forced malware" is a hell of a take.
Of course I exaggerated it on purpose, but think about it:
Remember, in ~2010, it was a trend to add toolbars to Internet Explorer (it was called BHO I think?)
These toolbars were changing the search engine for Bing, Yahoo, etc. This is why they were called "Yahoo toolbar".
But then, came Chrome, which was bundled among other in:
- Adobe Flash Player updates
- Java Runtime Environment (via Oracle)
- CCleaner
- Avast and AVG installers
- Many download portals (e.g., Softonic, CNET Download.com, SourceForge)
So, the objective of Chrome, instead of replacing the search engine with a toolbar, it was to do it by installing a new app, but this is exactly the same goal. At the end, the goal of Google was not the save the web, it was to replace the search engine and display ads on these pages (+ make sure that the targeting + rendering is under their control).
The toolbars were bad, too.
If an ecosystem can't be maintained without bundling malware (adware is by definition malware), then maybe that ecosystem shouldn't exist.
I feel like negative opinions are facts.
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.
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.
Like WAVE?
I already kind of get this with extensions that let you browse from the keyboard (e.g. click a link without using the mouse) like Tridactyl. It lets me know when clickable elements are not detected as clickable, and, sadly, this happens quite a lot.
This sounds like a great idea, does anyone know a tool like that?
There are techniques to solve that:
https://www.w3.org/WAI/WCAG22/Techniques/html/H33
https://www.w3.org/WAI/WCAG22/Techniques/css/C7
However, I don’t know how well the first one is supported by screen readers.
(Edit: Updated the links from WCAG 2.0 to 2.2.)
For a more up-to-date version, see WCAG 2.2:
https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-...
Thanks, I updated the links.
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.
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
it's true, but these are more fragile than simply having clear link text, especially over time as a site is maintained
That’s a good argument.
I would still include more of the action, i.e., ”Get Amaya“ instead of ”Amaya“ as in the article.
But you’re not getting anything. You’re just surfing to the Amaya website.
Getting it is what the website wants you to do. It's (presumably) the entire point of why that website exists.
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.
That’s amsomething I had not considered that changes my mind on this
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.
Sure. but who labels every link in there header as "click here"? A completely different use-case from inline hyperlinks.
One of my favorite accessibility accommodation attempts I have ever seen on a website: paragraph on the homepage saying
Click here for screen reader accessible version
It’s like… ‘click here. No, here. Left a bit. Almost. Come on, you can get it. What are you, blind or something?’
I find the accessibility concern a much more compelling argument than this article’s focus on “calls to action”, which is primarily a marketing/engagement concern and one that therefore earns my automatic distrust.
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.
A screen reader should be smart enough to read out what the link is for.
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.
> 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.
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.
Good. The web industry needs a lot MORE bullies forcing developers to build things in more predictable ways.
Besides, AMP is the almighty master of this practice, and they’re not trying to help disabled people, they’re trying to control the internet.
It's a travesty how much "Freedom" Scientific charges for a developer JAWS licence
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....
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...
One would hope those work the same in every browser + screen reader + language combination, but alas, it is not so.
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.
So maybe those user agents (the browsers and screen readers) should fix their shit instead. Crazy idea, I know.
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.
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.
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.
Yes, and it's an embarrassment and a failure to legislate the right thing.
The ADA is very good legislation and something I'm very thankful for as someone who is completely able-bodied. The reality is private entities won't do jack shit unless you force their hand and threaten them. It sucks it's that way, but that's the reality we have to acknowledge.
And, I benefit greatly from accommodations around accessibility. Both in the physical world and online.
Great, so force the hand of the screen reader makers to do a better job, or force the makers of browsers to integrate them properly, instead of burdening everyone else by piling workaround upon workaround.
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.
Yes sir, thank you sir, I will never complain about stupid laws again, sir.
Is this how you want these discussions to go?
> 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.
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.
I don't loop within loops, I free memory after I allocate it, and I add aria tags to html elements. I don't really see the big deal, just seems like a normal part of the job.
If you just do stuff without reflecting on why it's necessary that's... odd. Two of these examples have actual reasons on why they're necessary, the third is because screenreaders are crap.
I'm not trying to be difficult, but how is it any different than matching what an HTML parser (such as a web browser) expects by making sure you close your tags?
Excellent example because web browsers will render most documents just fine if you don't close your tags. Because they care about being compatible with websites that aren't perfect, and they consider it their job to render all websites that exist. Instead screen readers expect you to change your website instead of working with what's already there.
And yet we close our tags anyway, so even if screen readers are better, we wouldn't change our behavior. So I still don't get it.
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.
> How do you imagine that working? By reading surrounding text or by reading the URL?
Yes.
If I had "Amaya!" as the link text to download something, I'd be not much better off and would reach for context too.
What's the problem with reading the surrounding text or the URL?
It's less reliable than the author just telling you what it is. And more expensive too.
>By reading surrounding text
Yes, or it can summarize the text and explain what the link is to.
LLMs attempt that, but their success is mixed - sometimes the summary is very bad.
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.
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.
While that would work in many situations, I think the number of edge cases would be too great to make it reliable as a primary mode for communicating meaning in an accessible interface. As an alternative assistive feature? Sure. Something to rely on? I'll believe it when I hear it.
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.
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.
[flagged]
It's not adding roles/alt tags/etc. that's the issue. It's finding out that a screen reader doesn't support the ARIA markup (from the ARIA spec) that you are trying to use [1]. -- For example, using aria-describedby on an img doesn't work on most browser + screen reader combinations [2].
[1] https://www.powermapper.com/tests/screen-readers/aria/
[2] https://www.powermapper.com/tests/screen-readers/labelling/i...
I'm embarrassed for the screen reader software for needing so much help.
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?
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.
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.
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.
[flagged]
Oh look, personal attacks. Good argument!
[flagged]
> They don't try to be helpful, they only do exactly what they are told.
This is how software should work. Attempting to be "helpful" usually makes things worse. Doing exactly what it's told makes it predictable and usable.
Just look at how much of the HTML 5 spec is a nightmare of parsing rules for handling malformed SGML. Look at how it got there - all the invocations of Postel's law justifying attempting to handle malformed input in "helpful" ways, until things were eventually such a compatibility nightmare that a new spec was created to give precise rules for parsing every single input the same way. "Helpful" was specified away, because it was so broken.
Now if only screen readers provided consistency in following rules, too. They're not in a great state, but your attempted solution is worse.
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'.
Most blind people don't even use a Mac, they use JAWS or NVDA on Windows.
I think the AI argument is muddying the waters. I don't think I'm being arrogant in saying it's not that complicated a problem.
Simply either read the surrounding text (possibly by additional instruction) or the URL. I can't fathom how that's a difficult task.
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.
Because you can't trust people to do extra work themselves.
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.
Use a screen reader. Tab through the links. All you hear is, "click here." That's not helpful.
Build a search engine. What information does "click here" offer your index?
I agree with you that verbs don't seem all that problematic. Except when the verb is click and the object is here. I can stomach a link whose text is "Click Here to download Amaya," but if the link is literally just the two words, "click here," it is indistinguishable from others in many different contexts.
The problem here is that the screen reader will just read the link text and not the contract around it. In this case, the correct examples proposed by W3C will read just as "Amaya”, which are almost as unhelpful.
Even the WCAG level A success criteria clearly states:
The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.
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.
together with its programmatically determined link context really is the operative phrase in this quote. I would encourage you to actually read the examples on the page you link to - several of them announce just one or two words.
OP's comment addressed that:
The problem here is that the screen reader will just read the link text and not the contract around it.
I would encourage you to read OP's comment first?
I'm not sure what you mean now. Did you intend your quote from the WCAG to support OP's point, or to indicate that the screen reader has a bug?
"Download Amaya" as the link text makes the most sense in your scenario. A link that just says "Amaya" isn't any better than one that just says "click here" -- neither is sufficiently conveying that clicking the link will download the software.
I tend to agree with this as well. The "Click here" portion of "Click here to download Amaya" is implied by the simple fact that it's a link.
Making the entire thing a link is IMO the clearest option if you just want someone to download your app, but doesn’t work as well when you want a list of software and links for details.
A list where: “Click here” to download “V 16.23.4” has two links one of which gives info on the download and their other starts a download is fine, especially if the info page also has a download link.
As a user, I wouldn’t intuitively understand that “click here” is going to download a file and “V 16.23.4” is going to give me information. I’d assume they were both download links and be confused why there are 2 and which one I should click.
If the download link is on the information page, a simple solution is just to send people to the information page where they can download. I tend to prefer that anyway. I find premature direct download links to be jarring where I’m not expecting it.
Isn't this also better from a Fitts' Law perspective (for sighted mouse users) - simply because more text makes the "target" larger? (Not that I've seen a desktop browser doing anything sensible with artificially boosting hitbox sizes since the late 1990s...)
There are techniques to solve that, however:
https://www.w3.org/WAI/WCAG22/Techniques/html/H33
https://www.w3.org/WAI/WCAG22/Techniques/css/C7
I never understood why the visually hidden has not been incorporated into the CSS standard proper (something like display: visually-none). Instead the standard is effectively recommending authors use a hack to do what is a very common pattern.
It's a hack either way. Screen readers really should support the title attribute like they do for image links; or maybe HTML should have had an alt attribute for <a href> as well.
When using a mouse pointer, you also want that information as a tooltip.
At one point does accessibility decrease accessibility? I'm all for making improvements in the name of accessibility, but not so much about making things worse to support the least common denominator of screen readers. If people are going to need to change their behavior, wouldn't it be better to suggest some aria annotation instead?
Links are for clicking. Click here is superfluous noise.
And how do you know it is a link?
It is an interesting point, because in 2001, what is a link was usually clear and standardized: blue, underlined, often both, like on the article page. Now, just look at Hacker News, only the links in comments are underlined, and they have no special color, you have to mouse over if you want to know. And Hacker News is not in any way special in that regard.
So I would argue that "click here" is more relevant now than it once was. Same idea for buttons by the way. They used to look like, well, buttons, often with a 3D look. Now, there is often no real difference between a button and regular framed text. It means we need more context to guess which is which.
I have this fight with some developers all the time. Users are dumb, impaired, fearful animals and if you don't spell it out to them they have no idea what to do. "Click here" might be superfluous noise but that doesn't mean it's not necessary (sometimes).
Put something better. "Visit our site", "View Results", "Download File", "Next Page". Almost anything is better than "Click here". "Click here" is the result of laziness - think about what the button does for a couple minutes and you should be able to come up with better text
Note that all of these would fail the criteria in TFA - either as verb phrases, or not clearly describing the link target.
If your users have really never used a web browser before, and you are absolutely sure they are using a mouse on a desktop computer, and you can't imagine them ever using a mobile phone, and purposefully want to confuse them if they do, then phrase it like:
Click this hypertext link: <a href="more-info.html">More Info</a>
Put the device specific call to action outside of the link, and make the link say what it links to, not what physical action to take to follow the link.
Anyway, mobile phone touch screens don't click. Saying "click here" is like using a floppy disk as a save icon.
Obviously for the same reason you also should not say "touch here" either. Touching your desktop computer's screen doesn't work unless you have a touch screen, which is rare.
That's the point, why saying "click here" or "touch here" is always wrong.
I dare you to use a different icon than the floppy disk for save. People still use "click" terminology for tapping things on their phone and I doubt that will ever go away.
> If your users have really never used a web browser before, and you are absolutely sure they are using a mouse on a desktop computer, and you can't imagine them ever using a mobile phone
...have you ever used a mobile phone? Clicking is the only action you can take on one.
> Anyway, mobile phone touch screens don't click.
Let's check the dictionary!
https://en.wiktionary.org/wiki/click
- (verb) 2. [intransitive] To emit a click.
Phones don't do that, but that can't be relevant to the text "click here" because that text is directed at the user, not at the phone.
- (verb) 5. [transitive, graphical user interface] To select a software item using usually, but not always, the pressing of a mouse button.
Hmm....
Clicking with your finger is called "snapping" and you can't snap at traditional mobile phone interfaces and expect that to work. Touching with your finger on a screen makes no sound, not a click, not a thump, not a knock. It's silent, short of haptic or audio feedback, and that's not your finger clicking, it's the phone. That is my point. That's why they call them "touch screens" not "click screens". Do you disagree, or do you touch your phone so violently with your finger that it emits a click? Maybe that is the glass breaking!
Or is your entire point that you think it's actually a good idea to put the words "click here" in links? Then explain why?
> I 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.
I'm not explicitly talking about just "click here". I'd say it has it's place sometimes but it's rare. But a lot of developers have issues with redundancy or explicitly spelling things out for users for things that are "obvious".
With enough experience you learn that what is obvious is less obvious than it appears.
It's not superfluous noise at all. As a user of the World Wide Web I personally find "click here" to be easy to quickly identify and understand. When I see the underlined "click here" I quickly know exactly what I need to do.
And you don't find links with the underlined name of where they lead to be "easy to quickly identify and understand"?
Are you saying that you need links to say "click here" in order to understand what to do?
Then how did you manage to navigate to this discussion and press the reply link, which did not say "click here"?
Do you not think this looks like superfluous noise at all?
click here for mat_b click here for 1 hour ago | click here for undown | click here for root | click here for parent | click here for prev | click here for next click here to collapse [–]
bla bla bla
click here for reply
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.
> accessibility decrease accessibility
accessibility is usability. build products that are usable by people. that's all.
Everything in user interface design is a trade-off. There are many usability and accessibility and readability and design factors that every interface designer must balance and trade off against each other.
So of course usability can decrease usability, readability can decrease readability, accessibility can decrease accessibility, beauty can decrease beauty, and all those desirable traits can decrease each other, because there is no one single "technique" you just apply mindlessly to achieve any of those goals.
There are many many ways of achieving (and ruining) each of those goals, and you constantly have to balance and trade them all off against each other.
If somebody is so lazy and careless and poorly educated that they always use links saying "click here" as a solution to their problem of not being creative enough to come up with a better more descriptive link, I can guarantee you 100% of the time they are not going to give a flying fuck about aria or even have a clue what it is.
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.
I think the links just need to be longer vs a couple of words.
We are used to small areas, but the problem is that you end up with 'click here', like in the example. But if you linked the whole text, it's basically the same thing as adding aria.
IMO, most cases that I see using aria seem like a fix after the fact vs doing it the right way.
There are use cases for it, but in the case of the example, making the whole sentence a link would be good.
Regarding screen readers, you can have it read all links, which is why the 'click here' is an issue. So you want a balance. Change "for x, <a href=...>click here</a>" "<a href=...>for x, click here</a>"... ta-da?
You need to optimize for people using accessibility tools, but also for the people looking at the site...
> Regarding screen readers, you can have it read all links, which is why the 'click here' is an issue. So you want a balance. Change "for x, <a href=...>click here</a>" "<a href=...>for x, click here</a>"... ta-da?
No, you want the verb to be whatever "x" does or is for, not the action taken to get there. The action taken to get there is the same for all links regardless of what they're for. So this is a bad example simply because we don't know what "x" is so we don't know what a better verb would be.
It depends on x, right? For example, it could end up being, 'for learning more about Hacker news click here'.
I think that signals to visitor using screen readers and without, what that is and how to interact with it.
If someone with a screen reader is jumping through links, they'll get context for the link. A visitor not using it will see get the context since it's all highlighted together. Someone using a keyboard, the outline will highlight all of it.
I am just a keyboard user. I have no idea if this is the best way. But I think it gives the same info to everyone.
That's a screen reader problem and search engine problem.
It would be an extraordinarily easy for screen readers to have a heuristic that whenever a link is just "click here" or common variations like "tap here", "click", etc., to read the entire sentence containing the link. It's not exactly rocket science. Yes, you need an internationalized list of strings to detect. Also, if aria-label is present, just use that.
Likewise, search engines are great at inferring meaning from the page as a whole. I'm not going to change my link text for the benefit of search engines.
Screen reader heuristics are the wrong approach. If you want to use "click here", "download", "pdf", or something generic then use aria-label, aria-labelledby, or some other mechanism to give the additional context to screen readers and other assistive technologies. There's no need for any heuristics other than those in the specifications that the screen readers, web browsers, and web sites agree/conform to.
There may not be a surrounding sentence (e.g. in a "PDF"/"Download" link). The surrounding sentence may not add any/enough additional context, e.g. "You can click here for help." or "To view the article [one of many] you can click here.".
You then run into issues where 1) the screen reader/AT is overriding the ARIA/a11y markup on the page against WAI-ARIA and WCAG standards; and 2) you can end up with different behaviour on each screen reader, in addition to the places they already differ.
It's bad enough when web browsers introduced heuristics on form labels such that "name" + "label" fields were detected as a login form and other situations where bad heuristics were used and the web browsers overrode what websites were specifying.
In contrast, using descriptive link text does seem extraordinarily easy.
Except that it's not? As demonstrated by the entire internet. It forces you to write sentences awkwardly.
> 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.
The screen reader developer.
It's not a "central dependency" that needs an "authority". It's just part of building internationalized software.
Shouldn't screen readers have intelligent heuristics to most appropriately convey context when required? Seeing as most of the web doesn't have accessibility annotations?
Do you use `aria-label`, then?
I'm sorry, should we design websites around SEO, or should search engines just use context properly?
Search engines and websites are going to be subsumed by LLMs, so it's not like this argument matters anymore.
The general consensus is that the dislike of AI is so strong, that a large chunk of the population will disregard something if they even think it is generated by AI. Also, the LLMs need a continuous feed of new, original material to ingest or they'll be all thumbs.
While the long-running trend of SEO stuffing from low-value content farms has polluted search results for years now, Google didn't really care about fixing that problem because there's a perverse incentive to generate more ad revenue by making the first page results usesless. Who cares about doing the right thing? Daddy's got to get his quarterly numbers up. I should also note that those content farms were also early adopters of genAI as we know it today.
Infinite growth isn't a thing. Every cancer eventually kills its host.
Are you sure that’s the general consensus about AI? HN has a very intense relationship with this stuff, because we have hardcore boosters and hardcore skeptics. Among people I meet offline the feelings seem a lot weaker in either direction.
As best I can tell, your typical person here doesn't tend to hang out with normies, which definitely skews things.
> 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.
I see constant comments on social media complaining something is AI sometimes even when it’s not. Those commenters are all viewing it but they aren’t choosing it. And “likes” absolutely lie because there isn’t a “dislike” option.
> Views and likes don't lie.
If you're saying you have relevant stats, then please, share the stats.
if i only read HN threads i'd assume 95% of users exclusively use some screen readers to read the web
it's become a trope to the point i know i can ctrl-f "screen reader" if literally anything ui related is being discussed
If you are doing front-end web development then you really need to have some knowledge about accessibility, screen readers, etc. so you don't make simple/common mistakes. More so if you are involved in addressing accessibility issues for customers/your company.
Although he has a point - it seems overdiscussed compared to other types of accessibility or design topics.
I dunno, color blindness is brought up just as often here IMO.
On the whole I'd say it's a good thing because it means that the various awareness campaigns are working. Better that this kind of stuff is "overdiscussed" than not discussing it at all.
And besides, this focus has some useful side effects. For example, pages designed with screen readers in mind are also that much easier to interact with from scripts and other automation.
Screen readers are deterministic website or web application navigation applications. Building for screen readers isn't just for the disabled, it's for you, too. That will become infrastructure for testing and automation.
IMO that's the problem of the screen reader/search engine. It's a fine line between "accessibility" and actively making things worse (i.e. less accessible) for the majority just to cater to a small group of screen reader users.
That's similar to replacing all major doors in a building with automatic ones that can't be operated manually and take forever to open, despite the typical occupancy by wheelchair users being 0. Accessibility is great, but accessibility for few should not come at the cost of accessibility for most.
That's not a fair comparison.
Using accessible link text doesn't cost the same as adding an automatic opener to every door in a building.
That's a programmed behavior of the screen reader and a limitation of the contextual awareness of the search engine. Apparently this has been an issue in the wild since at least 2001 so I don't know what to tell you.
I strongly dislike "click here" links because when I'm looking for a link, I want to read only the link-formatted words on a page to find the link I'm interested in. "Download Amaya" would be a great link. Just "Amaya" (unless leading to a page with information about Amaya, I suppose) or "click here" are not.
Scannability is one of the reasons my formula is to link a complete descriptive phrase, like “Read more about hrefs,” or “take a survey on meeting times.” Links can be long, and probably doesn’t hurt SEO.
I often want a second source to first check if that is trustworthy: copy paste amaya while having to not accidentally click it is annoying, since often linebreaks and multiword names or company+product splits occur. Selecting and reading text should be easy. Navigating HTML should be wanted, not accidental.
Therefore, the ``click here'' works best for me.
PS
- "_Get Amaya_" should start a file transfer.
- "Get _amaya_ over there!"
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.
> 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.
> > 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.
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].
"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.
Besides screen readers, using a single descriptive noun as the link text might help for maintainability in some situations. First, it reduces the chances of a given link accidentally getting copied to another section by an unscrupulous maintainer. Second, in case of a dead link with a non-obvious URL (like maybe some ancient sourceforge link to a now renamed project), the link text is an extra bit of information to remind you if and how the dead link should be updated (assuming no comment exists). I admit that's a pretty minor benefit.
A rule of thumb I've been following lately (when communicating in e.g. GH issues or Slack messages), is to use the title of the page where possible. Hopefully, the page title should reflect the page's content, and thus automatically works as a link title a lot of the time.
In your example, I would expect the download page of Amaya to be titled "Download Amaya", so my link can simply be "If you are interested, [Download Amaya]!"
You don't get hyperlinks in a document-centric approach...
You think of them as action, they're not.
Actions are for applications. You are reading a document.
They are metadata.
Think of them like "footnootes" of a paragraph, or references.
Remember, you're reading a document, not using an application.
Documents don't contain calls to action like "Download X" or "Tell me more about Y", so your argument falls down in relation to the examples presented by W3C.
I don't read documents online. I use applications.
'Member the 80s?
I think that the goal was to help ppl move away from an overly verbose, printed document like style
Agreed.
I'd suggest:
_Download Amaya here_, W3C's editor/browser
or
W3C's editor/browser: _Download Amaya here_
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).
Yes and we all know that websites are not built to be consumed by humans, so this argument makes perfect sense.
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.
I mostly agree. One terminological difficulty is that, depending on the website, most users don’t “click” anymore, but “tap”, so something like “see here” could be more universal.
Am I the only one who is amused by seeing UIs fuss about using “tap” vs “click”? Is there anyone who has ever gotten confused and started looking for a mouse to plug into their phone because something said “click the X button” instead of “tap” it?
No, but for young people who only ever used a smartphone or tablet, it might be relatively unfamiliar terminology, and even when they do know what it means, may seem misplaced for how they use technology.
As an analogy, consider how you would feel if the instruction manual of your microwave oven (or other physical appliance) would instruct you to "click" its buttons. It's not that you wouldn't understand what to do or that you'd be looking for a mouse port, it's that the word wouldn't be the right one for the circumstance.
Incidentally, as a keyboard user I sometimes feel that way when there are instructions to "click" some UI button, but I will press the appropriate keyboard shortcut instead.
I’m still looking for a keyboard with an “Any” key. “Press Any Key” is very difficult without.
This sort of pedantic need for correctness at the cost of clarity seems to also crop up as businesses become increasingly corporate and expand their offerings.
“The best tires” becomes “the best vehicular solutions”
I sit near to one of these teams at work. They are very earnest and lovely, but torture themselves at great length over this stuff.
I find it funny but I will say that passion often produces amazing results.
I like "_To download W3C's editor/browser Amaya, click here_."
The UK's Government Digital Services make a similar recommendation [1] in their accessibility guidelines.
[1] https://design.homeoffice.gov.uk/accessibility/links
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.
> accessibility trumps design
Good design is accessible by nature. Otherwise it’s just sparkling wank.
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.
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.
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.
Their recommendation is very different.
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.I can't believe you verbified "noun".
> ...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:
Or like your last example, just link it slightly differently to emphasize the action: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.
I like to include icons to indicate whether the destination is external or a file (file extension could work for files too)
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.
The internal vs external link has already been solved by the little icon that Wikipedia et al use
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.
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."
Imperative would be appropriate for things like tutorials and howto pages.
This is the internet hill I'll likely die on. A call-to-action is one thing, but a page that only links the word "here" is a hard fail of an author not understanding the hypertext medium.
I think of "click here" as stage direction mistakenly left in. When most authors write, they often don't write in a hypertext context. Instead of using a Markdown-like notation for links, they default to stage direction.
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.
https://mstdn.io/@mattskala/113188291223682980
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.
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"
We should remember that UI conventions are mostly an arbitrary invention or are derivations of prior arbitrary inventions.
Users intuitively adapt themselves to the machine and developers adapt themselves to the users forming a feedback loop.
To put it another way: the meaning of language has probably been changed by so many websites and apps having an "I forgot my password" link. At least in that context most humans will adapt to understand the intent. Newer generations that have known nothing else won't even consider it to be worth their notice. In that sense there is also value in sticking to convention even if the convention makes no sense when considered in isolation.
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.
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."
This seems inelegant:
Okay, but why not “Learn [More about Amaya]” ? More about Amaya is a noun phrase so it fits their standard.
My specific point of discomfort is that imperatives may be fine in menus, and lists, and buttons (where "click here" is never going to happen anyway). But as an inline hyperlink they seem idiomatically incorrect. "Learn more about Amaya" is still an imperative sentence.
I guess technically, "To learn more about Amaya, view the datasheet." is also an imperative sentence. But to my mind, it scans better as inline text. Not quite sure how to nounify that one either. And interestingly, inability to find the "learn more about" link on landing pages for products I'm interested in is a source of constant frustration for me. There should be a word for "something halfway between the the breathless lede on a landing page, and "here's a thousand pages of documentation". For hardware products, the "datasheet" is exactly what I'm looking for; there doesn't seem to be an equivalent for software products.
Inelegant was the state of the Internet back then, I loved it.
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.
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.
> 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.
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.
I mostly agree with the descriptions described there. However, sometimes a verb or verb phrase is appropriate, especially if it is "download", but then it should be a direct download link; the verb should be directly what it corresponds to and should make sense it context. Often a verb phrase would not be appropriate, though.
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.
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.
Lighthouse also warns against generic link text, like “Learn More”. It’s one of the few lighthouse warnings I just ignore.
How about changing the text ever so slightly, so rather than just "Learn More" it's "Learn move about X"?
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.
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.
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.
Yes, but Lighthouse considers buttons and links to be the same if there's a "href".
In which case you ignore people with screen readers and search engines, too.
Learn more is perfectly descriptive for people with screen readers.
And combined with resulting page, perfectly descriptive for search engines.
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.
I don't see any concern of accessibility in the article, and to my knowledge there is no accessibility issue in any of the examples.
So who is w3 to say how people should and shouldn't use links? All that I see are just opinions, with no objective metrics/theories to back up their recommendations.
W3 should be in the business of setting up technical standards that go through rigorous processes, not creating nonsense like this.
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.
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".
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"!
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.
It's 2025. HTML is, first and foremost, a GUI toolkit. People have forgotten how hypertext works.
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.
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.
Linking manual for Wikipedia pages: https://en.m.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Li...
_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_
> _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.
This is a well researched areas with subject experts, our opinion is large irrelevant.
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.
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.
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.
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.
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.
A compromise is to add visually hidden text to supplement, or use aria-label to override the accessible name of the link
This. I’d never do this on a landing page it would cause a lot of lost sales.
click here to subscribe
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.
"If you want to call your reader to action..."
This article is from a marketing perspective. It assumes that the goal of the web site is to get the user to click on the link. Not to offer the user the opportunity to get more detailed info if they want it.
You don't have to be marketing anything. When putting links in a website, you are calling the visitor to action - the action of viewing other content or getting a file.
Articles in the 90s would suggest webmasters to use "click here" as link text to let users know that a hyperlink is clickable. The advice kind of make sense since hypertext was new back then and users need that little bit of help to navigate.
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!"
> 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.
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.
> 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.
There are browser, that lack basic features like bookmarking links?
I couldn't figure out how to do it on mobile Firefox, though I couldn't swear it's not possible. I didn't do a survey of others.
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.
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.
A related site/discussion last October:
Don't use "click here" for link text
https://news.ycombinator.com/item?id=41925658
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.
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.
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.
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.
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".
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.
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.
> 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.:
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/
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.
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.
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.
I would even say you could go with if duplicated words is an issue:
Nice refinement there.
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.
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.
As ClickOps is to DevOps, ClickSplaining is to ManSplaining.
Nobody appreciates being talked down to with "click here" as if they can't figure out how to follow a link.
> 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.
Okay but it doesn't say why. Why should one leave verbs out?
I am found of Apple content design has "Learn more..." links at the end of paragraphs. Those look very consistent and look well
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.
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
I’m reading the comments and thinking: only the HN crowd could get so worked up about something so trivial.
It's a reasonable CTA for simple cases, but definitely makes assumptions and presupposes a bit.
But my website is called go-here.nl
Remember when googling "click here" led to the acrobat reader download page? I member!
Keep doing whatever you've been doing for the last 24 years, it's fine.
I’m going to download Amaya now!
Click here!
"click here" links convert well, so people will use them
I still use "Click here" in corporate america
Consider not. There are many accessibility reasons to not, and corporate america has screen reader users in it too.
Feels like REST. Use nouns for the path (like the link text)
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.
[flagged]
[dead]
The times when this was relevant are long past
# This is a loop that runs n number of times
alternative proposal for 2025 update: Don't use "get started" as button text
But... why?
Local LLMs will solve this.
This seems like dogma
Clickable hyperlinks are considered harmful IMO
...Unless you are linking to a discussion about how you should not use "click here" as link text.
Dumbest shit ever, in the case of a download, it SHOULD mention the word “download” in the actual link
People are _still_ doing this shit. Unsubscribe links. Official government site. Fucking terrible.
I remember this, it stuck in my head and I never did it again. ¯\_(ツ)_/¯
"2001"
From the bottom of the page;
> contributed Sep 2001 by Aaron Swartz
Thoughts
-- this advice is 24 years old (and I think largely ignored)
-- Aaron Swartz (!)
Jakob Nielsen's recommendation from 1996: https://www.nngroup.com/articles/accessible-design-for-users...
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.
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.
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!"
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.
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.
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?
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.
> 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.
Which is also inaccessible (and goes against WCAG [1])
[1] https://webaim.org/blog/wcag-2-0-and-link-colors/
you shouldn't make things a link without decorations tbh
when hn could use a more distinct style for it
And Nielsen had plenty to say about that too.
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.
He was 14 when he wrote that.
We lost him too soon.
[dead]
[flagged]
It's aimed at web developers and content authors who have never used a screen reader.
I actually prefer what they don’t recommend, and I don’t know why
Me, too. The way they recommend feels like a "link to a Wikipedia article", not a call to action
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.
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.
Same here. This is just a style guideline that W3C has no real business in determining.
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.
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.
Then they shouldn't be publishing "tips" in the first place.
I'd very much like to see resources put in more meaningful things, like, drafting standards.
None of this matters, considering that "click here" converts better by a long shot.
Got any data on that?
Exactly what is wrong about "to do XYZ click here"?
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.
1. https://lists.w3.org/Archives/Public/www-qa/2001Sep/0007.htm...
Sounds equivalent to saying we shouldnt the words "he" or "she" because some people identify with neither. Exclusionary towards people of different mouse abilities.
Towards differently abled devices would've been funnier wording.
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.
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
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.
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.
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.
> Not everyone sees or intuitively understands things the same way you do.
That is true. And some people don’t see.
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:
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.
You like being told what to do and not having to figure it out yourself? Pay me $100 here: 35bSzXvRKLpHsHMrzb82f617cV4Srnt7hS
Depends on context. You don’t want every link in a Wikipedia article to be worded with “click here”, for example.