[HN Gopher] Don't use "click here" as link text (2001)
___________________________________________________________________
Don't use "click here" as link text (2001)
Author : theandrewbailey
Score : 387 points
Date : 2025-07-02 11:39 UTC (11 hours ago)
(HTM) web link (www.w3.org)
(TXT) w3m dump (www.w3.org)
| stogot wrote:
| I actually prefer what they don't recommend, and I don't know why
| chungy wrote:
| Same here. This is just a style guideline that W3C has no real
| business in determining.
| sham1 wrote:
| 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 wrote:
| 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.
| lionkor wrote:
| Me, too. The way they recommend feels like a "link to a
| Wikipedia article", not a call to action
| empiko wrote:
| 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 wrote:
| 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.
| kleiba wrote:
| 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.
| ceejayoz wrote:
| 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.
| JadeNB wrote:
| 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 wrote:
| > 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_ wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| scary-size wrote:
| The UK's Government Digital Services make a similar
| recommendation [1] in their accessibility guidelines.
|
| [1] https://design.homeoffice.gov.uk/accessibility/links
| rerdavies wrote:
| 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*.
| stavros wrote:
| I can't believe you verbified "noun".
| hapidjus wrote:
| PiPedal is a guitar effects pedal that runs on Raspberry Pi.
| *To download PiPedal, click here*. *To read the
| documentation, click here*.
| LocalPCGuy wrote:
| > ...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.
| manarth wrote:
| PiPedal is a guitar effects pedal that runs on
| Raspberry Pi. You can *download PiPedal*, and learn
| more in the *PiPedal documentation*.
| Cthulhu_ wrote:
| 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 wrote:
| > accessibility trumps design
|
| Good design is accessible by nature. Otherwise it's just
| sparkling wank.
| bigDinosaur wrote:
| 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 wrote:
| 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 wrote:
| 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.
| baggachipz wrote:
| 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_ wrote:
| 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.
| jxjnskkzxxhx wrote:
| Exactly what is wrong about "to do XYZ click here"?
| alabhyajindal wrote:
| From the suggestion email1:
|
| > "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 wrote:
| 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 wrote:
| Towards differently abled devices would've been funnier
| wording.
| micromacrofoot wrote:
| 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
| jaas wrote:
| 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.
| robin_reala wrote:
| 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.
| charcircuit wrote:
| A screen reader should be smart enough to read out what the
| link is for.
| hombre_fatal wrote:
| 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.
| charcircuit wrote:
| >By reading surrounding text
|
| Yes, or it can summarize the text and explain what the link
| is to.
| bluGill wrote:
| LLMs attempt that, but their success is mixed - sometimes
| the summary is very bad.
| DrewADesign wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| One would hope those work the same in every browser +
| screen reader + language combination, but alas, it is not
| so.
| snickerdoodle12 wrote:
| So maybe those user agents (the browsers and screen
| readers) should fix their shit instead. Crazy idea, I
| know.
| cluckindan wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Yes, and it's an embarrassment and a failure to legislate
| the right thing.
| komali2 wrote:
| 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 wrote:
| Yes sir, thank you sir, I will never complain about
| stupid laws again, sir.
|
| Is this how you want these discussions to go?
| komali2 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| ndriscoll wrote:
| 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.
| crazygringo wrote:
| > _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 wrote:
| 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.
| kulahan wrote:
| 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.
| ghusto wrote:
| > 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?
| donatj wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I'm embarrassed for the screen reader software for
| needing so much help.
| jodrellblank wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| rhdunn wrote:
| 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...
| rpd9803 wrote:
| 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'.
| chowells wrote:
| > 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.
| ghusto wrote:
| 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.
| pacifika wrote:
| 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 wrote:
| Because you can't trust people to do extra work themselves.
| stogot wrote:
| That's amsomething I had not considered that changes my mind on
| this
| cluckindan wrote:
| 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.
| layer8 wrote:
| There are techniques to solve that:
|
| https://www.w3.org/WAI/WCAG22/Techniques/html/H33
|
| https://www.w3.org/WAI/WCAG22/Techniques/css/C7
|
| However, I don't know how well the first one is supported by
| screen readers.
|
| (Edit: Updated the links from WCAG 2.0 to 2.2.)
| cluckindan wrote:
| For a more up-to-date version, see WCAG 2.2:
|
| https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-
| in-...
| layer8 wrote:
| Thanks, I updated the links.
| amenghra wrote:
| 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
| bevr1337 wrote:
| 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.
| joelanman wrote:
| it's true, but these are more fragile than simply having
| clear link text, especially over time as a site is maintained
| phkahler wrote:
| And if every link is just "Amaya" without verbs you can't tell
| what's what. So I think "get Amaya" and "go to the Amaya
| website" are rather fine.
|
| Also poor form is to have your download button on github.io
| pulling an executable from malware sites like sourceforge. I'm
| looking at you wxMaxima.
| raincole wrote:
| 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.
| joelfried wrote:
| 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 wrote:
| I can assure that there were good and bad pages then, the
| same as there are good and awful pages today.
| jchw wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jchw wrote:
| I don't think this recommendation is suggesting it would be
| any better to do that; having a bunch of different links be
| just Amaya would be wrong too. If you had this situation
| you'd probably want to carefully choose different selections,
| e.g. "get [Amaya]", "Amaya [documentation]", etc.
|
| If you need to disambiguate or further clarify links, well,
| you should also set the title attributes too. That ought to
| help.
| oneeyedpigeon wrote:
| > 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.
| ano-ther wrote:
| 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 wrote:
| But you're not getting anything. You're just surfing to the
| Amaya website.
| MangoToupe wrote:
| 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.
| nodar86 wrote:
| This sounds like a great idea, does anyone know a tool like
| that?
| hombre_fatal wrote:
| 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.
| SilasX wrote:
| 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.
| rerdavies wrote:
| Sure. but who labels every link in there header as "click
| here"? A completely different use-case from inline hyperlinks.
| bmacho wrote:
| Surely this is not true, a screen reader must be able to read
| text with html links inside, and be able to open the
| next/current/previous link. What is it able to do, if not that?
|
| Anyway, "click here" is more accessible for anyone else, since
| links should look like links, and random half-bold words in a
| wall of text are not cutting it.
| Vegenoid wrote:
| 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.
| inopinatus wrote:
| 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.
| rerdavies wrote:
| This seems inelegant: Get *Amaya*.
| Tell me more about *Amaya*.
| pooloo wrote:
| Inelegant was the state of the Internet back then, I loved it.
| xp84 wrote:
| Okay, but why not "Learn [More about Amaya]" ? More about Amaya
| is a noun phrase so it fits their standard.
| piqufoh wrote:
| 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 (!)
| piqufoh wrote:
| 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.
| xnx wrote:
| > 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.
| nemomarx wrote:
| you shouldn't make things a link without decorations tbh
|
| when hn could use a more distinct style for it
| rezonant wrote:
| Which is also inaccessible (and goes against WCAG [1])
|
| [1] https://webaim.org/blog/wcag-2-0-and-link-colors/
| jkestner wrote:
| And Nielsen had plenty to say about that too.
| xnx wrote:
| 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.
| netsharc wrote:
| 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 wrote:
| 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 wrote:
| 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.
| netsharc wrote:
| 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?
| AlienRobot wrote:
| 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 wrote:
| Jakob Nielsen's recommendation from 1996:
| https://www.nngroup.com/articles/accessible-design-for-users...
| roryirvine wrote:
| 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.
| px43 wrote:
| He was 14 when he wrote that.
| reddalo wrote:
| We lost him too soon.
| fkyoureadthedoc wrote:
| 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.
| fortran77 wrote:
| I'm going to download Amaya now!
| bravesoul2 wrote:
| Click here!
| scosman wrote:
| Lighthouse also warns against generic link text, like "Learn
| More". It's one of the few lighthouse warnings I just ignore.
| Cthulhu_ wrote:
| In which case you ignore people with screen readers and search
| engines, too.
| thesuitonym wrote:
| Learn more is perfectly descriptive for people with screen
| readers.
| scosman wrote:
| And combined with resulting page, perfectly descriptive for
| search engines.
| mrweasel wrote:
| How about changing the text ever so slightly, so rather than
| just "Learn More" it's "Learn move about X"?
| carlosjobim wrote:
| 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 wrote:
| 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.
| carlosjobim wrote:
| Yes, but Lighthouse considers buttons and links to be the
| same if there's a "href".
| scosman wrote:
| 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.
| bArray wrote:
| 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_ wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I would even say you could go with if duplicated words is an
| issue: You can [get the Amaya Browser] from
| the download page
| hnlmorg wrote:
| Nice refinement there.
| bArray wrote:
| I still think that the missing context is an issue. Imagine
| the page is some 10k words, by the time you get to the
| bottom, you might not remember what "Amaya" is. So just
| saying "Amaya's download page" tells the user that it is a
| download, but nothing about what it is a download for.
|
| I wonder how successful the screen reader experience is for
| using the web. Without checking URLs, how can they be sure
| for example they don't enter this credit card details on
| http://bank.xyz/scam_page , rather than https://bank.com ?
|
| Or how do they know whether the download page automatically
| downloads the file whilst they are on it?
|
| I can only imagine that using the web is extremely difficult.
| hnlmorg wrote:
| 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.
| 1970-01-01 wrote:
| W3C missed the biggest problems (IMHO) with "click here"
|
| * It's only 10 char and much too short for someone to click when
| it's inline with other links. Let's not mention text squirming
| around the screen via molasses JS, kicking your text up, down,
| and around the screen for several seconds before those short 10
| chars finally become stationary.
|
| * With high resolution touch screens, you're maybe 80% accurate
| on actually clicking right there. Again, my accuracy is my fat
| finger, and nearby links are just UI landmines.
| layer8 wrote:
| If a 10-character text link poses significant problems to be
| actuated, then something is really wrong with either the
| browser or the web page, not with the fact of having a
| 10-character link.
| thesuitonym wrote:
| > It's only 10 char and much too short for someone to click
| when it's inline with other links. Let's not mention text
| squirming around the screen via molasses JS, kicking your text
| up, down, and around the screen for several seconds before
| those short 10 chars finally become stationary.
|
| That was much less of a problem in 2010, and either way not
| really something for the size of your hyperlink to fix.
| kerblang wrote:
| 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.
| jasonlfunk wrote:
| 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.
| dsr_ wrote:
| _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 wrote:
| > __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.
| 0xbadcafebee wrote:
| 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 wrote:
| > Not everyone sees or intuitively understands things the same
| way you do.
|
| That is true. And some people don't see.
| 0xbadcafebee wrote:
| 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 wrote:
| You like being told what to do and not having to figure it out
| yourself? Pay me $100 here: 35bSzXvRKLpHsHMrzb82f617cV4Srnt7hS
| layer8 wrote:
| Depends on context. You don't want every link in a Wikipedia
| article to be worded with "click here", for example.
| guerrilla wrote:
| Okay but it doesn't say why. Why should one leave verbs out?
| latexr wrote:
| 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.
| flessner wrote:
| 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"!
| retsibsi wrote:
| 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.
| hammock wrote:
| The internal vs external link has already been solved by the
| little icon that Wikipedia et al use
| xixixao wrote:
| I like to include icons to indicate whether the destination is
| external or a file (file extension could work for files too)
| cluckindan wrote:
| 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.
| Aardwolf wrote:
| 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.
| bravesoul2 wrote:
| Feels like REST. Use nouns for the path (like the link text)
| racl101 wrote:
| # This is a loop that runs n number of times
| xyst wrote:
| 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.
| 2OEH8eoCRo0 wrote:
| Clickable hyperlinks are considered harmful IMO
| ogou wrote:
| 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.
| txdv wrote:
| click here to subscribe
| WickyNilliams wrote:
| A compromise is to add visually hidden text to supplement, or
| use aria-label to override the accessible name of the link
| iammrpayments wrote:
| This. I'd never do this on a landing page it would cause a lot
| of lost sales.
| smjburton wrote:
| 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.
| nikolayasdf123 wrote:
| I am found of Apple content design has "Learn more..." links at
| the end of paragraphs. Those look very consistent and look well
| ashleyn wrote:
| 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.
| guhcampos wrote:
| 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 wrote:
| Imperative would be appropriate for things like tutorials and
| howto pages.
| rdiddly wrote:
| 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."
| afandian wrote:
| 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.
| nlawalker wrote:
| 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.
| crazygringo wrote:
| 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.
| kqr wrote:
| 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.
| a3w wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| jkestner wrote:
| 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.
| nulbyte wrote:
| 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.
| xanrah wrote:
| I'm sorry, should we design websites around SEO, or should
| search engines just use context properly?
| echelon wrote:
| Search engines and websites are going to be subsumed by
| LLMs, so it's not like this argument matters anymore.
| bigbuppo wrote:
| The general consensus is that the dislike of AI is so
| strong, that a large chunk of the population will
| disregard something if they even _think_ it is generated
| by AI. Also, the LLMs need a continuous feed of new,
| original material to ingest or they 'll be all thumbs.
|
| While the long-running trend of SEO stuffing from low-
| value content farms has polluted search results for years
| now, Google didn't really care about fixing that problem
| because there's a perverse incentive to generate more ad
| revenue by making the first page results usesless. Who
| cares about doing the right thing? Daddy's got to get his
| quarterly numbers up. I should also note that those
| content farms were also early adopters of genAI as we
| know it today.
|
| Infinite growth isn't a thing. Every cancer eventually
| kills its host.
| bee_rider wrote:
| Are you sure that's the general consensus about AI? HN
| has a very _intense_ relationship with this stuff,
| because we have hardcore boosters and hardcore skeptics.
| Among people I meet offline the feelings seem a lot
| weaker in either direction.
| bigbuppo wrote:
| As best I can tell, your typical person here doesn't tend
| to hang out with normies, which definitely skews things.
| echelon wrote:
| > 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.
| cgriswald wrote:
| 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.
| creata wrote:
| > Views and likes don't lie.
|
| If you're saying you have relevant stats, then please,
| share the stats.
| rendaw wrote:
| 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?
| hombre_fatal wrote:
| 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 wrote:
| I think the links just need to be longer vs a couple of
| words.
|
| We are used to small areas, but the problem is that you
| end up with 'click here', like in the example. But if you
| linked the whole text, it's basically the same thing as
| adding aria.
|
| IMO, most cases that I see using aria seem like a fix
| after the fact vs doing it the right way.
|
| There are use cases for it, but in the case of the
| example, making the whole sentence a link would be good.
|
| Regarding screen readers, you can have it read all links,
| which is why the 'click here' is an issue. So you want a
| balance. Change "for x, <a href=...>click here</a>" "<a
| href=...>for x, click here</a>"... ta-da?
|
| You need to optimize for people using accessibility
| tools, but also for the people looking at the site...
| Izkata wrote:
| > Regarding screen readers, you can have it read all
| links, which is why the 'click here' is an issue. So you
| want a balance. Change "for x, <a href=...>click
| here</a>" "<a href=...>for x, click here</a>"... ta-da?
|
| No, you want the verb to be whatever "x" does or is for,
| not the action taken to get there. The action taken to
| get there is the same for all links regardless of what
| they're for. So this is a bad example simply because we
| don't know what "x" is so we don't know what a better
| verb would be.
| rovr138 wrote:
| 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.
| CoffeeOnWrite wrote:
| Links are for clicking. Click here is superfluous noise.
| wvenable wrote:
| 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).
| mitchdoogle wrote:
| 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
| danlitt wrote:
| Note that all of these would fail the criteria in TFA -
| either as verb phrases, or not clearly describing the
| link target.
| cube00 wrote:
| > I have this fight with some developers all the time.
|
| Please consider reading the rest of this thread before
| you keep fighting developers to do it your way.
|
| After that if you still want "click here" that's your
| call but at least be open to better alternatives rather
| this dismissing this discussion.
| wvenable wrote:
| 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.
| DonHopkins wrote:
| 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.
| wvenable wrote:
| 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.
| thaumasiotes wrote:
| > 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....
| Dylan16807 wrote:
| 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.
| mat_b wrote:
| 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.
| DonHopkins wrote:
| 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
| GuB-42 wrote:
| 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.
| madeofpalk wrote:
| > accessibility decrease accessibility
|
| accessibility is usability. build products that are usable
| by people. that's all.
| DonHopkins wrote:
| 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.
| layer8 wrote:
| 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
| runarberg wrote:
| I never understood why the visually hidden has not been
| incorporated into the CSS standard proper (something like
| display: visually-none). Instead the standard is
| effectively recommending authors use a hack to do what is a
| very common pattern.
| layer8 wrote:
| 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.
| danillonunes wrote:
| The problem here is that the screen reader will just read the
| link text and not the contract around it. In this case, the
| correct examples proposed by W3C will read just as "Amaya",
| which are almost as unhelpful.
| burningChrome wrote:
| 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.
| danlitt wrote:
| _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.
| burningChrome wrote:
| 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?
| c22 wrote:
| 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.
| crazygringo wrote:
| 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.
| cube00 wrote:
| > 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.
| crazygringo wrote:
| 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?
| 01HNNWZ0MV43FF wrote:
| Do you use `aria-label`, then?
| theteapot wrote:
| In contrast, using descriptive link text does seem
| _extraordinarily_ easy.
| crazygringo wrote:
| Except that it's not? As demonstrated by the entire
| internet. It forces you to write sentences awkwardly.
| rhdunn wrote:
| 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.
| tgsovlerkhgsel wrote:
| IMO that's the problem of the screen reader/search engine.
| It's a fine line between "accessibility" and actively making
| things worse (i.e. less accessible) for the majority just to
| cater to a small group of screen reader users.
|
| That's similar to replacing all major doors in a building
| with automatic ones that can't be operated manually and take
| forever to open, despite the typical occupancy by wheelchair
| users being 0. Accessibility is great, but accessibility for
| few should not come at the cost of accessibility for most.
| cube00 wrote:
| 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.
| Gormo wrote:
| "Download Amaya" as the link text makes the most sense in
| your scenario. A link that just says "Amaya" isn't any better
| than one that just says "click here" -- neither is
| sufficiently conveying that clicking the link will download
| the software.
| al_borland wrote:
| 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.
| Retric wrote:
| 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.
| al_borland wrote:
| 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.
| eichin wrote:
| 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...)
| thousand_nights wrote:
| if i only read HN threads i'd assume 95% of users exclusively
| use some screen readers to read the web
|
| it's become a trope to the point i know i can ctrl-f "screen
| reader" if literally anything ui related is being discussed
| rhdunn wrote:
| 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.
| quietbritishjim wrote:
| > > 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.
| turboponyy wrote:
| 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.
| layer8 wrote:
| 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.
| xp84 wrote:
| 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?
| loloquwowndueo wrote:
| I'm still looking for a keyboard with an "Any" key. "Press
| Any Key" is very difficult without.
| Spooky23 wrote:
| 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.
| layer8 wrote:
| 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.
| cellularmitosis wrote:
| 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"
| sgustard wrote:
| 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].
| 1317 wrote:
| I like "_To download W3C's editor/browser Amaya, click here_."
| 1-more wrote:
| "click here" makes sense in that context, but links can be
| viewed in the screen reader rotor, where they just show up as a
| list of links out of context. aria-describedby can help out,
| but if you just make the text inside the link better then you
| can avoid having to do that.
|
| I do agree with you about verbs.
| anotheryou wrote:
| Agreed.
|
| I'd suggest:
|
| _Download Amaya here_, W3C's editor/browser
|
| or
|
| W3C's editor/browser: _Download Amaya here_
| eadmund wrote:
| It's not really about clarity, or even about accessibility
| (although both of those are great!): it's about what a Web page
| _is_. A Web page is a _document_ which can link to other
| _documents_.
|
| > Links should absolutely be verbs
|
| No, links _imply_ a verb: 'get.' Buttons imply another verb:
| 'post.' It'd be awesome if there were ways in HTML to indicate
| other verbs, such as put and delete.
|
| > > Get _Amaya_!
|
| > That... doesn't tell me how to get Amaya.
|
| No, it doesn't: it is a document calling its reader to action.
| That's something a document does: it tells a reader how to do
| something, or calls the reader to do something. Clicking is
| just an artifact of a particular technology at a particular
| point in time (heck, I imagine most people nowadays _don't_
| click, because they are using smartphones -- they tap instead).
| iLoveOncall wrote:
| Yes and we all know that websites are not built to be
| consumed by humans, so this argument makes perfect sense.
| _ZeD_ wrote:
| You don't get hyperlinks in a document-centric approach...
|
| You think of them as action, they're not.
|
| Actions are for applications. You are reading a document.
|
| They are metadata.
|
| Think of them like "footnootes" of a paragraph, or references.
|
| Remember, you're reading a document, not using an application.
| Diggsey wrote:
| 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.
| dalmo3 wrote:
| 'Member the 80s?
| chipsrafferty wrote:
| I don't read documents online. I use applications.
| jakeinspace wrote:
| 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.
| kevinsync wrote:
| 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 wrote:
| 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
| orthoxerox wrote:
| 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".
| t1234s wrote:
| 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.
| seydor wrote:
| "click here" links convert well, so people will use them
| johnisgood wrote:
| > 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.
| mmaunder wrote:
| 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.
| seanwilson wrote:
| 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.
| jfax wrote:
| 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
| wvenable wrote:
| If "I forgot my password" is visibly a button then it's more
| effective than a link in that context.
|
| I remember when Microsoft removed many buttons from their UI
| and replaced them with vaguely colored text (links) and it
| became a lot harder to figure out what to click on.
| mitchdoogle wrote:
| 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"
| ChrisArchitect wrote:
| A related site/discussion last October:
|
| _Don 't use "click here" for link text_
|
| https://news.ycombinator.com/item?id=41925658
| smallerize wrote:
| 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."
| pacifika wrote:
| This is a well researched areas with subject experts, our opinion
| is large irrelevant.
| yard2010 wrote:
| Remember when googling "click here" led to the acrobat reader
| download page? I member!
| sherburt3 wrote:
| 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.
| bitwize wrote:
| 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.
| lucaspauker wrote:
| This seems like dogma
| theletterf wrote:
| 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.
| swyx wrote:
| alternative proposal for 2025 update: Don't use "get started" as
| button text
| iLoveOncall wrote:
| 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.
| _Yguy_ wrote:
| But... why?
| briandilley wrote:
| None of this matters, considering that "click here" converts
| better by a long shot.
| lysace wrote:
| Got any data on that?
| ivanjermakov wrote:
| Linking manual for Wikipedia pages:
| https://en.m.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Li...
| DonHopkins wrote:
| ...Unless you are linking to a discussion about how you should
| not use "click here" as link text.
| DonHopkins wrote:
| 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.
| jrappswe wrote:
| Dumbest shit ever, in the case of a download, it SHOULD mention
| the word "download" in the actual link
| neuroelectron wrote:
| "2001"
| drellybochelly wrote:
| It's a reasonable CTA for simple cases, but definitely makes
| assumptions and presupposes a bit.
| rednafi wrote:
| I'm reading the comments and thinking: only the HN crowd could
| get so worked up about something so trivial.
| Animats wrote:
| _" 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.
| einpoklum wrote:
| 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.
| darqis wrote:
| The times when this was relevant are long past
| wolpoli wrote:
| 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.
| jcims wrote:
| I remember this, it stuck in my head and I never did it again.
| -\\_(tsu)_/-
| karaterobot wrote:
| Keep doing whatever you've been doing for the last 24 years, it's
| fine.
| theendisney wrote:
| But my website is called go-here.nl
| zzo38computer wrote:
| 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.
| eightnoneone wrote:
| 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.
___________________________________________________________________
(page generated 2025-07-02 23:00 UTC)