theandrewbailey•5h
Don’t use “click here” as link text (2001)w3.org
211 comments
  • crazygringo•3h

    I couldn't disagree more. Their "bad" example:

    > To download W3C's editor/browser Amaya, _click here_.

    Is extraordinarily clear. I'll click the link and it will either download directly, or it will be a download page.

    In contrast:

    > Get _Amaya_!

    That suggests a link to the Amaya website, not a download page. That's not effective for a download.

    Similarly:

    > Tell me more about _Amaya_: W3C's free editor/browser that lets you create _HTML_, _SVG_, and _MathML_ documents.

    This is terrible. It's not about downloading, and "tell me more" is the command, but not linked! For all I know, the "Amaya" link goes to a corporate landing page, not the "tell me more" information I actually need.

    The conventional uses on the web are totally fine:

    > To download W3C's editor/browser Amaya, _click here_.

    > _Download Amaya_, the W3C's editor/browser.

    The idea that links shouldn't be verbs seems very silly to me. Links should absolutely be verbs, when they involve an action like downloading or finding out more. Obviously that's different from "reference" links like in Wikipedia, where you're finding more about a topic.

    And "click here" makes it exceptionally clear that a link isn't merely a reference link, but an action link. When I see:

    > Get _Amaya_!

    That... doesn't tell me how to get Amaya. That tells me "Amaya" is a reference link, not a download link.

    • nulbyte•2h

      Use a screen reader. Tab through the links. All you hear is, "click here." That's not helpful.

      Build a search engine. What information does "click here" offer your index?

      I agree with you that verbs don't seem all that problematic. Except when the verb is click and the object is here. I can stomach a link whose text is "Click Here to download Amaya," but if the link is literally just the two words, "click here," it is indistinguishable from others in many different contexts.

      • danillonunes•41m

        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.

      • layer8•2h

        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

      • rendaw•2h

        At one point does accessibility decrease accessibility? I'm all for making improvements in the name of accessibility, but not so much about making things worse to support the least common denominator of screen readers. If people are going to need to change their behavior, wouldn't it be better to suggest some aria annotation instead?

        • CoffeeOnWrite•1h

          Links are for clicking. Click here is superfluous noise.

        • hombre_fatal•2h

          Aria tags are something you think might have more developer compliance than better anchor text?

          Most of us never wrote an aria attribute in our life.

          But I haven't used "click here" as anchor text in 20 years because it sucks for these reasons.

          • rovr138•26m

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

      • c22•28m

        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.

      • xanrah•2h

        I'm sorry, should we design websites around SEO, or should search engines just use context properly?

        • •2h
          [deleted]
        • echelon•2h

          Search engines and websites are going to be subsumed by LLMs, so it's not like this argument matters anymore.

          • bigbuppo•21m

            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.

    • kqr•2h

      I strongly dislike "click here" links because when I'm looking for a link, I want to read only the link-formatted words on a page to find the link I'm interested in. "Download Amaya" would be a great link. Just "Amaya" (unless leading to a page with information about Amaya, I suppose) or "click here" are not.

      • jkestner•14m

        Scannability is one of the reasons my formula is to link a complete descriptive phrase, like “Read more about hrefs,” or “take a survey on meeting times.” Links can be long, and probably doesn’t hurt SEO.

      • a3w•2h

        I often want a second source to first check if that is trustworthy: copy paste amaya while having to not accidentally click it is annoying, since often linebreaks and multiword names or company+product splits occur. Selecting and reading text should be easy. Navigating HTML should be wanted, not accidental.

        Therefore, the ``click here'' works best for me.

        PS

        - "_Get Amaya_" should start a file transfer.

        - "Get _amaya_ over there!"

          sounds like "okay next site will be info dump before actual download", which is acceptable to gather trust like brand or imprint recognition over there instead of googling now.
        • crtasm•2h

          Ideally browsers would have a shortcut to enter a text selection mode - this would also fix the annoyance of sites disabling text selection on certain elements.

          The Newpipe app on Android has such a mode for Youtube descriptions.

          • nayuki•48m

            > Ideally browsers would have a shortcut to enter a text selection mode

            They do - Firefox has the option "Search for text when you start typing". I have it enabled for decades.

    • quietbritishjim•2h

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

    • 1317•17m

      I like "_To download W3C's editor/browser Amaya, click here_."

    • sgustard•54m

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

    • layer8•2h

      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.

    • turboponyy•2h

      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.

  • robin_reala•4h

    If you think about this from an accessibility point of view, screen readers for blind users present a linear view of a page. To escape from the linear view, they also typically allow users to access lists of elements like headers and links, out of context of their original position. If every link is labelled “click here” then you’re effectively removing non-linear access from those users.

    • phkahler•3h

      And if every link is just "Amaya" without verbs you can't tell what's what. So I think "get Amaya" and "go to the Amaya website" are rather fine.

      Also poor form is to have your download button on github.io pulling an executable from malware sites like sourceforge. I'm looking at you wxMaxima.

      • jchw•3h

        I don't think this recommendation is suggesting it would be any better to do that; having a bunch of different links be just Amaya would be wrong too. If you had this situation you'd probably want to carefully choose different selections, e.g. "get [Amaya]", "Amaya [documentation]", etc.

        If you need to disambiguate or further clarify links, well, you should also set the title attributes too. That ought to help.

      • raincole•3h

        Go to the [Amaya Website](www.amaya.com) is perfectly fine. I seriously have a hard time understanding what this w3.org article is trying to say.

        A website is a website. To download is to download. The mechanics won't be 'abstracted away' just because you don't call them with the proper terms.

        • jchw•3h

          I don't think it's suggesting "Amaya website" is an incorrect or bad phrase in and of itself, I think it's just using the different passages to show how they'd prefer you style links in hypertext.

          These days I don't think you'd find many people following this style guide, but I think I understand what they're going for. They seem to be making the prose neutral to the technical details; after all, if you're keyboard navigating, maybe you're not "clicking" per-se. Maybe the pages are printed onto paper, etc.

          • raincole•3h

            I do agree "Click Here" is bad because you need to read the context to know what "Here" is, and for the accessibility reason my GP mentioned.

            • jchw•3h

              Hmmm. My first thought was they were avoiding the word "website" in this case so that it would make more sense if you were viewing it on paper or outside of a hypertext environment. But actually, that would make "Get Amaya!" and other such phrases equally awkward. Without the hyperlinks, they become a bit strange. So I guess that was probably not their reasoning.

              Now I really wish the page elaborated a bit more. I do wonder if there's any logic to avoiding "website" or if it's just the different choices they made in the examples.

        • joelfried•3h

          In 2001 websites weren't what they are today. It was 5 years before jQuery's initial release . . . people needed to learn the proper terms somewhere in those days.

          • bornfreddy•3h

            I can assure that there were good and bad pages then, the same as there are good and awful pages today.

      • oneeyedpigeon•3h

        > And if every link is just "Amaya" without verbs you can't tell what's what.

        I'm pretty sure the W3C is not recommending you do that. If you link to the Amaya website, link on the text "Amaya". If you're linking to something else Amaya-related, modify the link text appropriately.

      • rvnx•3h

        [flagged]

        • ceejayoz•3h

          Describing bundled adware as "fostering a sustainable ecosystem" while portraying Chrome as "forced malware" is a hell of a take.

          • rvnx•3h

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

            • ceejayoz•3h

              The toolbars were bad, too.

        • StableAlkyne•3h

          If an ecosystem can't be maintained without bundling malware (adware is by definition malware), then maybe that ecosystem shouldn't exist.

        • wussboy•3h

          I feel like negative opinions are facts.

    • layer8•3h

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

      • bevr1337•1h

        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.

      • cluckindan•3h

        For a more up-to-date version, see WCAG 2.2:

        https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-...

        • layer8•3h

          Thanks, I updated the links.

      • joelanman•54m

        it's true, but these are more fragile than simply having clear link text, especially over time as a site is maintained

      • amenghra•3h

        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

    • MangoToupe•3h

      Ironically, we really need to figure out away to make accessibility tooling more accessible to those who don't have a need for them. I'm not saying alter the tool, but surely there's got to be a way to visualize this for those who aren't going to put the work into figuring out how screen readers work.

      • hombre_fatal•2h

        Ideas for a browser plugin:

        - Toggle/hide aria-hidden items from the page so you can ensure only the important components are there

        - Show the ordered list of links, headings, landmarks you'd see in screen readers like when you use the VO+U rotor in macOS VoiceOver

        - Toggle on a mode where a little "?" appears next to anything with an aria-description that can be hovered as a tooltip

        Prob would be a decent start.

        Though I recommend the more curious HNer to fire up macOS VoiceOver, do its tutorial (Settings -> Accessibility -> VoiceOver -> "Open VoiceOver Tutorial..."), and then navigate your own website. Use Safari for this since it has the best VoiceOver behavior.

        It's very eye opening (heh) and helps you understand what things like aria-hidden actually are for.

        If that's not enough, it also prepares you for bad luck in the future, and it's also just cool being able to use your computer with your eyes closed.

        I had some classes in uni where we weren't allowed to use our laptop screens, and I bet I could have gotten away with having my hands inside a half closed laptop with an airpod in my ear scrolling HN/Reddit while the professor droned on for an hour.

      • nodar86•3h

        This sounds like a great idea, does anyone know a tool like that?

    • ano-ther•3h

      That’s a good argument.

      I would still include more of the action, i.e., ”Get Amaya“ instead of ”Amaya“ as in the article.

      • mattl•1h

        But you’re not getting anything. You’re just surfing to the Amaya website.

    • cluckindan•4h

      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.

    • rerdavies•3h

      Sure. but who labels every link in there header as "click here"? A completely different use-case from inline hyperlinks.

    • bmacho•3h

      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.

    • stogot•4h

      That’s amsomething I had not considered that changes my mind on this

    • charcircuit•4h

      A screen reader should be smart enough to read out what the link is for.

      • hombre_fatal•4h

        How do you imagine that working? By reading surrounding text or by reading the URL? Those are worse experiences than descriptive anchor text.

        You can use something like macOS VoiceOver right now to see how it behaves.

        • crazygringo•3h

          > By reading surrounding text

          Yes, exactly, if ARIA tags haven't been provided. It's not exactly rocket science to have some heuristics that check if a link is solely "click", "click here", etc., and it reads the entire sentence if that's the case. Seems like it would work 99+% of the time with exceedingly little effort.

          There's no expectation, and should be no expectation, that the function of a link should be derivable directly from the text it encloses.

          • account42•1h

            It feels like the screen reader industry has somehow managed to bully the entire web into making things easy for them instead of improving their own software.

        • charcircuit•4h

          >By reading surrounding text

          Yes, or it can summarize the text and explain what the link is to.

          • bluGill•4h

            LLMs attempt that, but their success is mixed - sometimes the summary is very bad.

          • DrewADesign•3h

            Imagine how long it would take to load a page of HN search results, or the table of contents of an online book, or a page with a lot of dead links, or a page with links to a whole bunch of non-textual content that it has to figure out is non-textual.

            • charcircuit•1h

              You don't need to load where the link is going. The base line is the context a sighted person would have when they see the "click here" link.

        • AlienRobot•4h

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

          • cluckindan•4h

            One would hope those work the same in every browser + screen reader + language combination, but alas, it is not so.

            • ndriscoll•2h

              They're not supposed to work the same in every browser. The user is supposed to be able to choose software that works how they want/suits their needs. You follow the standards and the user selects software that interprets those standards in their preferred way.

            • snickerdoodle12•3h

              So maybe those user agents (the browsers and screen readers) should fix their shit instead. Crazy idea, I know.

              • cluckindan•3h

                They definitely should. However, those will be large investments, so at least JAWS and VoiceOver are going to be waiting for WCAG 3.0 before tackling that. NVDA is open source, so I guess you could help them out with it. ;-)

                The larger issue is that developing software for multiple platforms and multiple browsers and multiple different types of human interface devices (from eye tracking to sip-and-puff joysticks) from dozens of vendors is an extremely complex affair.

                Users may even employ multiple different screen readers in different contexts to work around incompatibilities.

                • snickerdoodle12•3h

                  The point is that it's not really my (or other web developers) their responsibility that some 3rd party tool is garbage. It's like designing your whole website around some esoteric browser's behavior that less than 1% of your users use.

                  Sure, sure, we need to accommodate people with disabilities. First step to get there is to make sure the accessibility software isn't trash.

                  • cluckindan•3h

                    I get where you’re coming from, but this garbage is not optional everywhere around the world. Not in the US, even less in the EU.

                    The Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act. The ADA, specifically Title III, applies to public accommodations (including websites), requiring them to be accessible. Section 508 mandates that federal agencies ensure their electronic and information technology, including websites, is accessible to people with disabilities.

                    The EU Web Accessibility Directive and the European Accessibility Act (EAA) are key pieces of legislation aimed at improving digital accessibility for people with disabilities within the European Union. The Directive focuses on public sector websites and mobile applications, while the EAA expands accessibility requirements to a wider range of products and services, including those in e-commerce, banking, and travel.

                    • snickerdoodle12•3h

                      Yes, and it's an embarrassment and a failure to legislate the right thing.

                      • komali2•3h

                        So either fix it by changing the legislation, or fix it by changing the FOSS software... or do the only thing you can actually do right now which is implement websites in a way that's most likely to consistently work well with existing a11y solutions.

                        • snickerdoodle12•2h

                          Yes sir, thank you sir, I will never complain about stupid laws again, sir.

                          Is this how you want these discussions to go?

                          • komali2•2h

                            > complain

                            I guess at some point this button gets a bit worn out and I start wondering what pushing the "do something about it" button will do.

                            • snickerdoodle12•2h

                              You can implement your websites with accessibility in mind while also acknowledging its ridiculous how every web developer has to spend time on that because screen readers are terrible, and responsibility somehow got shifted to every web developer ever instead of the handful of companies making screen readers.

              • DrewADesign•3h

                After a couple decades of relying on pragmatic hacks and loose conventions while hoping developers would start to take accessibility standards seriously, most just seemed to give up hope and concentrate on making software blind people can actually use. And that happened, like, a decade ago.

      • donatj•4h

        What I have learned after years of working with accessibility experts is that screen readers are largely incapable pieces of junk that need to be lead around manually.

        They don't try to be helpful, they only do exactly what they are told.

        Frankly I think there's rear space for interruption here, particularly with AI.

        • snickerdoodle12•3h

          The hilarious part is that we somehow wound up in a situation where the screen readers are useless pieces of crap but instead of fixing those every developer making a website is held responsible instead.

          • rpd9803•3h

            As a developer you should be embarassed if your site isn't accessible to screen readers, its not exactly hard to add some aria roles and alt tags.

            • snickerdoodle12•3h

              I'm embarrassed for the screen reader software for needing so much help.

              • jodrellblank•1h

                If you serve your UI as out-of-order HTML content abusing tables for browser layout, if you merge broken fragments of mismatched XHTML from a content management system to cobble a page together on the fly, if you hide items behind burger menus, if you make interactivity from CSS and minified Javascript to visually look like input boxes and buttons instead of using standard buttons, if you add overlays and blocks to stop people selecting or copying text, if you care nothing about tab order and keyboard shortcuts and image alt text, if you reflow text around images, if you name CSS identifiers with no semantic meaning, if you mix in arbitrary advertising and tracking and framework session state, why is a screenreader "a piece of crap" for not being able to magically infer a human interpretation of the page?

                Why is it embarrassing to need to code against standardised accessibility interfaces so that other tools using those interfaces can function? Is it embarrassing to have to code against a database or filesystem interface to persist data, or a graphics interface to show pictures?

                • snickerdoodle12•1h

                  My eyes, search engines and LLMs manage just fine. Screen readers are the odd ones out, and they haven't evolved in over a decade.

                  • SoftTalker•25m

                    The sad reality is that screen readers have a very small market. There isn't a lot of money to be made so not much innovation happens. Maybe with LLMs there will be a new approach. It's something they might actually be good for.

                    • snickerdoodle12•17m

                      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.

                  • jodrellblank•27m

                    Your eyes manage fine because they're backed by a human intelligence. Other humans don't have working eyes and need tools for help with that, but don't need an LLM describing a picture in 1,000 words of fluff for every time they look at a computer screen. Search engines manage fine at extracting text from a page, but if you think that's all screenreaders do then you don't know enough about screenreaders or disabled people to be commenting and your opinions all over this thread really are as empty and low value as they originally seemed.

                    > "Screen readers are the odd ones out, and they haven't evolved in over a decade."

                    Imagine if a stable accessibility interface existed so that screenreaders, braille output, and all kinds of voice and assistive input devices which emulate keyboards and mice and touch inputs could just keep working reliably year on year for the humans who depend on them, without being forced to 'evolve' to handle piles of junk pushed by "move fast and break things" web developers.

        • rpd9803•3h

          The reason JAWS and Voiceover are to widely used is not because no one else has tried.

          I'd reckon 90% of 'accessiblity' software was written by a sighted or hearing dev that thought they had an idea that would be 'helpful'.

      • pacifika•1h

        Why would every client process the context to the link, when the author can do this once and add it to the link, that's much more efficient.

        • charcircuit•1h

          Because you can't trust people to do extra work themselves.

  • retsibsi•4h

    Personally, I prefer the second example that they advise against. ("To download Amaya, go to the _Amaya_Website_ and get the necessary software.")

    A link that just says "Amaya" could be an internal or external link, and even if it's clear from context that the purpose of following the link is to download Amaya (rather than, for example, read more about it), it's not clear whether it's a direct link to the file or a link to the download page.

    • xixixao•4h

      I like to include icons to indicate whether the destination is external or a file (file extension could work for files too)

      • cluckindan•3h

        Icons do nothing for screen readers, though. Use aria-describedby or aria-labelledby to add an ”external link” text suffix to the link text.

        Note that aria-label does not work properly in all cases, e.g. when the browser chrome uses a different language than the site itself.

    • hammock•4h

      The internal vs external link has already been solved by the little icon that Wikipedia et al use

  • jfax•2h

    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

  • scary-size•4h

    The UK's Government Digital Services make a similar recommendation [1] in their accessibility guidelines.

    [1] https://design.homeoffice.gov.uk/accessibility/links

    • Cthulhu_•4h

      We frequently reference this website / guideline for a reference of maximally accessible components / web design, it's really good. Not the prettiest (thick black / yellow borders on form components and the like), but accessibility trumps design.

      • dkdbejwi383•4h

        > accessibility trumps design

        Good design is accessible by nature. Otherwise it’s just sparkling wank.

        • bigDinosaur•3h

          Not necessarily. For example, good design on a staircase doesn't mean that everyone ever can use it, and not every situation can involve alternatives. Accessibility is always relative and is not a binary state. As another example, not every video can be replaced by its transcript. Thinking in binaries leads to rejecting better-but-not-perfect solutions, such as not rebuilding something to be better for most people because it won't be better (or more accessible) for all people.

        • rpd9803•3h

          Ah the fallacy of 'universal accessibility'

          Not everything done in the name of accesility makes it accessible to all, nor does accessibility have a necessary correlation with 'good design'.

          That's not to say we should't strive for both and require accesible solutions, but let's not pretend putting lightswitches 40" from the floor or those bumpy concrete pads in grocery store parking lots are better for everyone.

        • SilasX•2h

          In theory, yes. In practice, the typical specialist designer is going to optimize for things that come at the cost of accessibility.

          But yes, in general you're absolutely right, that a good designer will take into account all factors, including accessibility. But the way that "design" has evolved in practice in means that the thing we all think of as "web design[er]" is not optimizing for it.

    • rerdavies•4h

      Their recommendation is very different.

      W3c says:

          Get *Amaya*
    Read more about *Amaya*
      The home office says:

          *Get Amaya*
    *Read more about Amaya*
      which seems much more sensible, but suffers from a different problem when used in context.

      Personally, I think both are confounding two different use cases. Links are often used inline in text. The use case that W3c and the Home Office are addressing are use cases that would be better address by out-of-line buttons:

          [Download]
    [Documentation]
      But both seem broken when the use case is hyperlinks in inline text.

      To use a concrete example, how should one rewrite the following?

          PiPedal is a guitar effects pedal that runs 
    on Raspberry Pi. To download PiPedal, *click here*.
    To read the documentation, *click here*.
      I get the objection. But the fix seems unacceptable:

          PiPedal is a guitar effects pedal that runs 
    on Raspberry Pi. Get Pipedal. Read the documentation.
      Nuh uh. Not happening. I'm not sure what you would call that. Meta-grammatically incorrect? Whatever it is, it is not idiomatic English.

         Pipedal is a guitar effects pedal that runs on
   Raspberry Pi. To download PiPedal, visit the *Download
   Page*. To learn more about Pipedal, view the
   *Documentation*.
      Perhaps. That is the actual text I used in my documentation. But, speaking from personal experience, the challenge is that it is often very difficult to nounify "click here"

         Ubuntu Server installs don't suffer from this problem;
   but before choosing an Ubuntu Server install, you
   should read the *Ubuntu Server* section of the 
   "Installing on Ubuntu" page.
      Which makes one wonder, what exactly is the foul that's being committed when "here" is used as a pronoun for the content that's being referenced? In this use case, there is not an actual accessibility issue, because the the link sits inline within a sentence that provides all the context that's necessary to indicate what to expect when you click.

      And in the very first example given, the text is from a lede in a web page where concision matters.

         To download PiPedal, click *here*.
      Is that really an accessibility issue? particularly when there's are buttons right above it that say

          [ Download ] [ Documentation ]
      The actual metric that counts here is: how many times will people visit the Download page? And from that perspective there is significant doubt in my mind as to whether the following text will be better.

        To download PiPedal, visit the *Download Page*.
      • manarth•3h

            PiPedal is a guitar effects pedal that runs 
    on Raspberry Pi.
    You can *download PiPedal*, and learn more
    in the *PiPedal documentation*.
      • LocalPCGuy•3h

        > ...accessibility issue? particularly when there's are buttons right above it that say...

        Yes, those buttons may not be "in context" when the page is not being viewed in a visual medium.

        > To download PiPedal, click here.

        Another appropriate link in this case could be simply:

          *Download PiPedal* now!
        Or like your last example, just link it slightly differently to emphasize the action:

          To *download PiPedal*, visit the Download Page.
      • stavros•4h

        I can't believe you verbified "noun".

      • hapidjus•4h

            PiPedal is a guitar effects pedal that runs on Raspberry Pi. *To download PiPedal, click here*.
    *To read the documentation, click here*.
  • guhcampos•3h

    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.

    • rehevkor5•15m

      Imperative would be appropriate for things like tutorials and howto pages.

  • smallerize•2h

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

  • 1970-01-01•4h

    W3C missed the biggest problems (IMHO) with "click here"

    * It's only 10 char and much too short for someone to click when it's inline with other links. Let's not mention text squirming around the screen via molasses JS, kicking your text up, down, and around the screen for several seconds before those short 10 chars finally become stationary.

    * With high resolution touch screens, you're maybe 80% accurate on actually clicking right there. Again, my accuracy is my fat finger, and nearby links are just UI landmines.

    • thesuitonym•3h

      > It's only 10 char and much too short for someone to click when it's inline with other links. Let's not mention text squirming around the screen via molasses JS, kicking your text up, down, and around the screen for several seconds before those short 10 chars finally become stationary.

      That was much less of a problem in 2010, and either way not really something for the size of your hyperlink to fix.

    • layer8•3h

      If a 10-character text link poses significant problems to be actuated, then something is really wrong with either the browser or the web page, not with the fact of having a 10-character link.

    • kerblang•3h

      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.

  • fkyoureadthedoc•4h

    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.

  • mmaunder•2h

    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.

  • rerdavies•4h

    This seems inelegant:

        Get *Amaya*. 
    Tell me more about *Amaya*.
  • orthoxerox•2h

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

  • latexr•4h

    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.

  • seanwilson•2h

    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.

  • sherburt3•59m

    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.

  • scosman•4h

    Lighthouse also warns against generic link text, like “Learn More”. It’s one of the few lighthouse warnings I just ignore.

    • mrweasel•4h

      How about changing the text ever so slightly, so rather than just "Learn More" it's "Learn move about X"?

      • scosman•3h

        There's a section with a nice header making it's clear it's about X, a paragraph with details about X. Adding redundant text in the button isn't improving design. "Learn more about Synthetic Data Generation" is a truly gnarly button. I have played with making the entire section the link, which makes lighthouse stop complaining, but is lousy for providing an affordance to the user that it's an action.

      • carlosjobim•4h

        Consider a product listings page, with a "Buy" button/link next to every product. Should those links be changed to differ from each other? Google Lighthouse sure thinks so, so it's better ignored.

        • mrweasel•3h

          Fair point, no you're right that would be a bit silly to have "Buy X" instead of just "Buy". I would argue that that's the label of a button, not a link though.

    • Cthulhu_•4h

      In which case you ignore people with screen readers and search engines, too.

      • thesuitonym•3h

        Learn more is perfectly descriptive for people with screen readers.

        • scosman•3h

          And combined with resulting page, perfectly descriptive for search engines.

  • pacifika•1h

    This is a well researched areas with subject experts, our opinion is large irrelevant.

  • flessner•4h

    I get it that "click here" is not descriptive, but so is simply linking "Amaya". What is it? A person? A fruit?

    People don't read websites linearly, in the best case they skim read all the buttons and links. I personally would include the verb as it gives important context and is a clearer CTA for the "skimmers".

    Amaya is W3C's... "Download Amaya"!

  • Aardwolf•4h

    In the example "Get Amaya!" that they give:

    Now that I paste it in this HN comment, the link is gone. If it had said "To get Amaya, click here!" at least you could have seen from the context that it used to be a link.

    There's also no explanation in it for why making a verb a link would be bad while nouns are ok.

  • afandian•3h

    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.

  • ashleyn•3h

    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.

  • dsr_•4h

    _Tell me more about Amaya_

    is preferable to any shorter link.

    If, somehow, you have multiple links in a sentence, see if you can manage a word or two of unlinked text in between, or, better yet, stop being pretentious and focus on usefulness.

    Not: _You can run web browsers,_ _spreadsheets_ or _drawing software._

    You can run:

    * _web browsers_

    * _spreadsheets_

    * _drawing software_

    • Mordisquitos•4h

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

  • smjburton•3h

    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.

  • yard2010•1h

    Remember when googling "click here" led to the acrobat reader download page? I member!

  • johnisgood•2h

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

  • ogou•3h

    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.

    • WickyNilliams•3h

      A compromise is to add visually hidden text to supplement, or use aria-label to override the accessible name of the link

    • txdv•3h

      click here to subscribe

  • t1234s•2h

    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.

  • kleiba•5h

    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.

  • nlawalker•3h

    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.

  • kevinsync•2h

    My stomach is churning already knowing I'm about to type a short-sighted hot take related to LLMs, but I do wonder what a screen reader would look like that could provide a "summarized" version of any given web page (assumingly via LLM). Basically allow the user to swap between the full page rendered with current methodology / presentation of content and links, and a version of the same page with a summarized version of the text content + a collated, deduped section of actions found in the content.

    ex.

    To download W3C's editor/browser Amaya, [click here].

    [Download Amaya]

    [Click here] to get Amaya for Windows

    All collapse into something singular and sensible like [Download Amaya installer for Windows here] as an action inside the action section.

    I don't know. I should probably put on a sleeping mask and navigate the web via a screen reader one of these days to really experience how things are.

    • carlhjerpe•2h

      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

  • jasonlfunk•4h

    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.

  • nikolayasdf123•3h

    I am found of Apple content design has "Learn more..." links at the end of paragraphs. Those look very consistent and look well

  • bitwize•38m

    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.

  • seydor•2h

    "click here" links convert well, so people will use them

  • bArray•4h

    I disagree. I think we need to make it clear that following hyperlinks should always be a cognitive choice.

    > To download W3C's editor/browser Amaya, [click here].

    This gives you an option, where multiple options may be available.

    > To download Amaya, go to the [Amaya Website] and get the necessary software.

    This is even better, as 'click here' assumes the input device.

    > Get [Amaya]!

    Whilst being simpler, it does not make clear that the action is optional.

    Whether I click something may require some additional information around the link, for example:

    > To download W3C's free editor/browser Amaya, go to the [Amaya Website] and select the latest version on the home page.

    Now I know that it's free, and I have instructions to carry out to find what I'm looking for.

    • Cthulhu_•4h

      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.

      • tempfile•3h

        I don't think this is right. The WCAG allows for "programmatically determined link context" which includes text surrounding the actual link. "click here" is bad but "Amaya website" or "Amaya" are fine.

        e.g. from the WCAG examples you link to:

        > An account registration page requires successful completion of a [Turing test](https://www.w3.org/TR/turingtest/) before the registration form can be accessed.

      • bArray•3h

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

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

    • ivan_gammel•4h

      I don’t think either of the suggested options delivers the best possible UX. Copy of course depends on context, but „click here“ is never justified as the best alternative.

      You can do:

      • [Download X] - immediate download link.

      • [Learn more about X] - go to webpage, discover other interactions there

      • [Register to download X] - if registration required

      Short and concise copy is generally better, extra information rarely makes content better.

      • bArray•3h

        I think it really depends on the context. In a news article it rarely makes the content better, but in a documentation wiki, the context can be everything. I think we are fooling ourselves to suggest that there is zero nuance and that there is a 100% correct approach always.

    • hnlmorg•4h

      Best:

      > You can download the Amaya Browser from [Amaya’s download page]

      It’s both explicit for sighted reader and screen readers too.

      Yes there’s some duplicated words. But the point of that paragraph isn’t to be artistic, it’s to be informative. You can save the creative word play for your regular paragraphs.

      • LocalPCGuy•3h

        I would even say you could go with if duplicated words is an issue:

          You can [get the Amaya Browser] from the download page
      • bArray•3h

        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.

  • bravesoul2•4h

    Feels like REST. Use nouns for the path (like the link text)

  • racl101•3h

    # This is a loop that runs n number of times

  • ceejayoz•5h

    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.

  • ChrisArchitect•2h

    A related site/discussion last October:

    Don't use "click here" for link text

    https://news.ycombinator.com/item?id=41925658

  • xyst•3h

    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.

  • guerrilla•4h

    Okay but it doesn't say why. Why should one leave verbs out?

  • fortran77•4h

    I’m going to download Amaya now!

  • 2OEH8eoCRo0•3h

    Clickable hyperlinks are considered harmful IMO

  • JadeNB•5h

    One reason they omit is that, by default, bookmark text is (was? I hardly bookmark any more) the text of the link. So, if you don't curate your bookmarks carefully, you get a folder full of bookmarks called "Click here!"

    • xnx•4h

      > bookmark text is (was? I hardly bookmark any more) the text of the link

      I'm not sure I've seen this behavior. More commonly, it is the <title> of the page.

      • Cthulhu_•4h

        Based on the comment I'd expect an "add link to bookmarks" entry in the right click context menu, but I don't remember ever seeing it. It makes sense to use the link text in that case though, else the browser would have to access the underlying webpage to fetch the title. Which shouldn't be a problem, but at one point some web apps were broken and did destructive actions on GET requests, and Google Gears tried to optimize the internet by prefetching webpages... which caused some whoopsies.

        But, thankfully, web developers and web technology improved since then.

        • JadeNB•4h

          > Based on the comment I'd expect an "add link to bookmarks" entry in the right click context menu, but I don't remember ever seeing it.

          I just checked, and desktop Firefox still offers it. At least, version 138 on macOS does.

      • JadeNB•4h

        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.

  • stogot•5h

    I actually prefer what they don’t recommend, and I don’t know why

    • lionkor•5h

      Me, too. The way they recommend feels like a "link to a Wikipedia article", not a call to action

      • empiko•4h

        Yeah, Wikipedia, but also many news sites use this style. It is mostly not a call to action, but additional optional information you can check out. That's why it feels wrong to use it in these cases. I think that some of the examples are outdated compared to how people format the web nowadays.

    • mannykannot•5h

      I do too - it tells the reader what they have to do in order to bring about the desired result, more directly than do any of the alternatives.

    • chungy•5h

      Same here. This is just a style guideline that W3C has no real business in determining.

      • sham1•5h

        Well good thing that this style guide is just what W3C considers best practices and is not a standard.

        > While the tips are carefully reviewed by the participants of the group, they should not be seen as anything else than informative bits of wisdom, and especially, they are not normative W3C technical specifications.

      • hombre_fatal•4h

        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.

  • piqufoh•4h

    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 (!)

    • xnx•4h

      Jakob Nielsen's recommendation from 1996: https://www.nngroup.com/articles/accessible-design-for-users...

    • piqufoh•4h

      Aaron's suggestion (which seems to have been lost?)

      "Click here" assumes everyone has a computer and mouse. And it's not even needed: most users of the Web understand how to follow links.

      • netsharc•4h

        Yes, most people understand how to navigate around the jankiness...

        For example, most Windows programs have "File" as the first menu item. How do I exit? Go to File, the bottom option is usually "Exit". Does that make sense? No, why is "Exit" a File-related option? Why is it like that? Because it's always been like that.

        Want to learn about the program? Go to Help > About.

        Some more geniuses even got involved and thought "If the user wants to edit preferences, well, they can go to the menu option Edit, and find Preferences. Never mind that Edit is otherwise filled with document related functions like Cut, Copy, and Paste!"

        • stavros•4h

          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.

          • ceejayoz•3h

            I mean, on a Mac, there's always a menu for the current app as the first item, titled after the app. If I want to quit Slack, I open the Slack menu. Which makes a good amount of sense.

        • AlienRobot•4h

          Meanwhile, on GNOME, there is no standard menubar so good look figuring out which one of the icon-only buttons in the headerbar has the dropdown menu with the action that you want.

          Edit -> preferences makes sense because you're editing your preferences. File -> Settings makes no sense. Help -> Options makes even less sense. Help -> KEYBOARD SHORTCUTS is just insane to me.

      • xnx•4h

        > most users of the Web understand how to follow links.

        Often very hard to tell what's a link when it's not underlined and non-blue colors (or no color) is used.

        • rezonant•4h

          Which is also inaccessible (and goes against WCAG [1])

          [1] https://webaim.org/blog/wcag-2-0-and-link-colors/

        • nemomarx•4h

          you shouldn't make things a link without decorations tbh

          when hn could use a more distinct style for it

        • jkestner•3h

          And Nielsen had plenty to say about that too.

          • xnx•3h

            Indeed. Craigslist seems to be about the only site out there that hasn't fallen for every dumb design fad of the past 30 years.

    • px43•4h

      He was 14 when he wrote that.

  • WiFiMap•2h

    [dead]

  • •4h
    [deleted]
  • Lindby•4h

    [flagged]

    • Cthulhu_•4h

      It's aimed at web developers and content authors who have never used a screen reader.

  • jxjnskkzxxhx•4h

    Exactly what is wrong about "to do XYZ click here"?

    • alabhyajindal•4h

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

      • jxjnskkzxxhx•4h

        Sounds equivalent to saying we shouldnt the words "he" or "she" because some people identify with neither. Exclusionary towards people of different mouse abilities.

        • jxjnskkzxxhx•35m

          Towards differently abled devices would've been funnier wording.

    • jaas•4h

      The idea is that some people don’t click - that refers mainly to people using a mouse, and many people are not using a mouse. So it is overstating information about what to do.

    • micromacrofoot•4h

      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

  • 0xbadcafebee•4h

    I like it when pages tell me to "click here". It is clear and direct communication that doesn't assume I will infer exactly where I'm supposed to click for what thing. Not everyone sees or intuitively understands things the same way you do.

    • eCa•4h

      > Not everyone sees or intuitively understands things the same way you do.

      That is true. And some people don’t see.

      • 0xbadcafebee•39m

        I'm fully aware. I grew up with a kid who was almost blind.

        Images can contain alt text metadata, but links can't. Why? Because some genius with an opinion decided links aren't allowed to have alt-text. The rationale for why links can't contain alt-text:

          Using alt text on a hyperlink would be redundant and potentially confusing for screen reader users, who may hear both the hyperlink text and the alt text
        Except we see here a great example of why this is wrong. We could tell a sighted user to click here, and simultaneously add alt-text that describes "this is a hyperlink which downloads the software". (which, by the way, would also help sighted people!!) An author drafting the link could choose what text is shown for the link, and what (if any) is shown for the alt-text. It doesn't have to be confusing.

        Yet with the current mandatory design examples, it is confusing! The suggested link text is just the name of the product!! What's the link going to do when you click it? Download something? Render a page? Show an image? Something else? How is that helping a blind person OR a non-blind person?!

        The spec should allow you to decide how the content is presented, in a way that works for both blind and non-blind people. But we see here that, in order to make a "beautiful engineering design" that supports blind and sighted people, it's actually making it harder for both. If they took away their arbitrary restriction, the content creator could be free to craft it however makes sense, in a way that supports all people well, rather than all people poorly.

    • hammock•4h

      You like being told what to do and not having to figure it out yourself? Pay me $100 here: 35bSzXvRKLpHsHMrzb82f617cV4Srnt7hS

    • layer8•3h

      Depends on context. You don’t want every link in a Wikipedia article to be worded with “click here”, for example.

  • baggachipz•4h

    Counterpoint to the other opinions so far:

    I feel like a link should be used for more information retrieval; therefore, the link should be descriptive of its forthcoming content. Instead of using a link as a call to action, shouldn't it be a button? This feels more "pure" in the semantic web context.

    • Cthulhu_•4h

      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.