If you think about this from an accessibility point of view, screen readers for blind users present a linear view of a page. To escape from the linear view, they also typically allow users to access lists of elements like headers and links, out of context of their original position. If every link is labelled “click here” then you’re effectively removing non-linear access from those users.
To see our latest news, click here, or click here if you want to request a catalog. The latest board minutes can be found by clicking here. Click here for product documentation. If you have any comments about our web site, click here to email us, or click here to call. If you were confused by this click here, or click here to let us know it met your expectations. Click here to see how many people have visited our internet web site.
On the plus side, there was actual useful content on the web, rather than the content-free designs that popped up in the Web 2.0 era.
Something to keep in mind is that a modern web page would be virtually unusable by the standards of 2002 and a 1995 web page would have been virtually unusable without the "click here" links. Conventions have to be established. While those blue underlined links may have had some precedent among some computer users (e.g. many help systems of the era used colored text to highlight hyperlinks), they would have little meaning to someone who bought their first computer to get on that newfangled Internet thingy. So while I agree that they were a bad thing over all, they were a necessary stopgap.
It takes less than five minutes for a person to learn how to click on links. They're a different color and underlined. It's obvious they are special. Despite "UX" being a discipline that actually exists, we've actually gone backwards on usability in that nobody can figure out what's clickable these days. For example... all those greyed-out pipe-delimitted links at the top of this comment. Despite its ubiquity for about 15 years now, at least once a month I have to teach someone that the ubiquitous three line "hamburger" menu is clickable.
Someone tell Wikipedia please, they have a weird sort of moving/hidden hamburger that floats which I've not seen anywhere else, I wonder if there's public stats on activity following the layout update.
Whereas if you removed the "click here" tags and associated text, you'd be left with:
> See our latest news, request a catalog. The latest board minutes. Product documentation. If you have any comments about our web site, email us, or call. If you were confused by this, let us know it met your expectations. See how many people have visited our internet web site.
It's okay, though, you would most certainly have the main navigation menu repeated several times on the page. The new web master is learning this thing called Balinese Caligraphy or JavaScript or something along those lines and have even added a new drop down menu in two spots so it will be even easier to find the link to the page with the contact page and info on how to send us a fax to get a catalog mailed to them.
In 2001 websites weren't what they are today. It was 5 years before jQuery's initial release . . . people needed to learn the proper terms somewhere in those days.
I don't think it's suggesting "Amaya website" is an incorrect or bad phrase in and of itself, I think it's just using the different passages to show how they'd prefer you style links in hypertext.
These days I don't think you'd find many people following this style guide, but I think I understand what they're going for. They seem to be making the prose neutral to the technical details; after all, if you're keyboard navigating, maybe you're not "clicking" per-se. Maybe the pages are printed onto paper, etc.
Hmmm. My first thought was they were avoiding the word "website" in this case so that it would make more sense if you were viewing it on paper or outside of a hypertext environment. But actually, that would make "Get Amaya!" and other such phrases equally awkward. Without the hyperlinks, they become a bit strange. So I guess that was probably not their reasoning.
Now I really wish the page elaborated a bit more. I do wonder if there's any logic to avoiding "website" or if it's just the different choices they made in the examples.
I don't suggest "follow this link" either, or even anything that mentions a link. Obviously it's an extreme example involving traditional prose, but think for example of a Wikipedia article: the links in Wikipedia articles are natural and obvious. Links in navigation panels and navbars also follow this pattern generally speaking: like at the bottom of Hacker News itself, "Guidlines" "FAQ" "List" ...
In cases where you want to do something involving a call to action, like "Click here to download", I think "Download" or "Download now!" are better. And hell, often times CTAs are better as buttons (at least visually) than links anyways.
That said, it's not like I follow this religiously. But anyway, I think it's highly likely people are taking away the wrong message here.
I guess to put it another way, it's not that the terminology we use is dated or wrong per-se; I mean sure, people tap on hyperlinks more than they click on them these days probably, but the point isn't that the terminology is dated or isn't understood. It's that well-structured hypertext can avoid it altogether.
I see your point, but I'm less anti the use of "click".
Firstly because of the acceptance of "click is to web as dial is to phone", that the term "click" as a verb meaning to follow a navigation link or interact with a button, or generally interact at all with something on a website or app. I think this is useful and should be encouraged [0].
Secondly because it was used in the first place because it was very clear instruction. "Download" by itself assumes that the user knows how to download, and if the UI element isn't clear that it's a link or a button (or interactive) then that's not obvious how that should happen. "Click here to download" is much more clear, obvious, and helpful. I think it was old-school SourceForge that had "Download" buttons that didn't look like buttons, and ran adverts that had very prominent "Click here to download" buttons, and that ended up being very confusing and getting a lot of people to click on shitty ads.
Thirdly, and purely as a matter of personal taste, I don't subscribe to the design philosophy that less is better. I prefer clear instructions to ambiguous ones, even if that means more words. The impulse to surround everything in whitespace, remove scroll bars, and make it look pretty at the cost of usability should be discouraged imho. A button should look like a button. It should be clearly labelled with what it does, or what you need to do to make it do the thing. I realise I'm in a minority here, but that's not unusual.
[0] though maybe the new verbal usage of "I'm double-clicking on this concept" to mean supporting it is probably a bit much.
I don't think this recommendation is suggesting it would be any better to do that; having a bunch of different links be just Amaya would be wrong too. If you had this situation you'd probably want to carefully choose different selections, e.g. "get [Amaya]", "Amaya [documentation]", etc.
If you need to disambiguate or further clarify links, well, you should also set the title attributes too. That ought to help.
> And if every link is just "Amaya" without verbs you can't tell what's what.
I'm pretty sure the W3C is not recommending you do that. If you link to the Amaya website, link on the text "Amaya". If you're linking to something else Amaya-related, modify the link text appropriately.
Of course I exaggerated it on purpose, but think about it:
Remember, in ~2010, it was a trend to add toolbars to Internet Explorer (it was called BHO I think?)
These toolbars were changing the search engine for Bing, Yahoo, etc. This is why they were called "Yahoo toolbar".
But then, came Chrome, which was bundled among other in:
- Adobe Flash Player updates
- Java Runtime Environment (via Oracle)
- CCleaner
- Avast and AVG installers
- Many download portals (e.g., Softonic, CNET Download.com, SourceForge)
So, the objective of Chrome, instead of replacing the search engine with a toolbar, it was to do it by installing a new app, but this is exactly the same goal. At the end, the goal of Google was not the save the web, it was to replace the search engine and display ads on these pages (+ make sure that the targeting + rendering is under their control).
Ironically, we really need to figure out away to make accessibility tooling more accessible to those who don't have a need for them. I'm not saying alter the tool, but surely there's got to be a way to visualize this for those who aren't going to put the work into figuring out how screen readers work.
- Toggle/hide aria-hidden items from the page so you can ensure only the important components are there
- Show the ordered list of links, headings, landmarks you'd see in screen readers like when you use the VO+U rotor in macOS VoiceOver
- Toggle on a mode where a little "?" appears next to anything with an aria-description that can be hovered as a tooltip
Prob would be a decent start.
Though I recommend the more curious HNer to fire up macOS VoiceOver, do its tutorial (Settings -> Accessibility -> VoiceOver -> "Open VoiceOver Tutorial..."), and then navigate your own website. Use Safari for this since it has the best VoiceOver behavior.
It's very eye opening (heh) and helps you understand what things like aria-hidden actually are for.
If that's not enough, it also prepares you for bad luck in the future, and it's also just cool being able to use your computer with your eyes closed.
I had some classes in uni where we weren't allowed to use our laptop screens, and I bet I could have gotten away with having my hands inside a half closed laptop with an airpod in my ear scrolling HN/Reddit while the professor droned on for an hour.
I already kind of get this with extensions that let you browse from the keyboard (e.g. click a link without using the mouse) like Tridactyl. It lets me know when clickable elements are not detected as clickable, and, sadly, this happens quite a lot.
I'm particularly fond of the latter approach. There's some joy in applying hints that can be optionally read and only provide clarity. It's a great writing challenge.
I did sweat localization with this approach. We use a workflow to ensure some peer review but it's an added challenge. Seemingly all good.
In a similar vain to the second link, I previously wrote about using css to truncate git hashes so that search functionality continues to work:
https://www.quaxio.com/truncating_hashes.html
Screen readers commonly provide several different ways to navigate on the page, and linear movement through the page is the least efficient method. Users can move e.g. between landmarks or between headings, or both at once in an ”outline” navigation mode.
Crucially: screen reader navigation is NOT the same as keyboard navigation.
Surely this is not true, a screen reader must be able to read text with html links inside, and be able to open the next/current/previous link. What is it able to do, if not that?
Anyway, "click here" is more accessible for anyone else, since links should look like links, and random half-bold words in a wall of text are not cutting it.
I find the accessibility concern a much more compelling argument than this article’s focus on “calls to action”, which is primarily a marketing/engagement concern and one that therefore earns my automatic distrust.
From my naive point of view, this seems a very easy problem for screen readers to solve, especially with LLMs: if the link does not describe what it is, include context like the preceding phrase.
Yes, exactly, if ARIA tags haven't been provided. It's not exactly rocket science to have some heuristics that check if a link is solely "click", "click here", etc., and it reads the entire sentence if that's the case. Seems like it would work 99+% of the time with exceedingly little effort.
There's no expectation, and should be no expectation, that the function of a link should be derivable directly from the text it encloses.
It feels like the screen reader industry has somehow managed to bully the entire web into making things easy for them instead of improving their own software.
They're not supposed to work the same in every browser. The user is supposed to be able to choose software that works how they want/suits their needs. You follow the standards and the user selects software that interprets those standards in their preferred way.
They definitely should. However, those will be large investments, so at least JAWS and VoiceOver are going to be waiting for WCAG 3.0 before tackling that. NVDA is open source, so I guess you could help them out with it. ;-)
The larger issue is that developing software for multiple platforms and multiple browsers and multiple different types of human interface devices (from eye tracking to sip-and-puff joysticks) from dozens of vendors is an extremely complex affair.
Users may even employ multiple different screen readers in different contexts to work around incompatibilities.
The point is that it's not really my (or other web developers) their responsibility that some 3rd party tool is garbage. It's like designing your whole website around some esoteric browser's behavior that less than 1% of your users use.
Sure, sure, we need to accommodate people with disabilities. First step to get there is to make sure the accessibility software isn't trash.
I get where you’re coming from, but this garbage is not optional everywhere around the world. Not in the US, even less in the EU.
The Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act. The ADA, specifically Title III, applies to public accommodations (including websites), requiring them to be accessible. Section 508 mandates that federal agencies ensure their electronic and information technology, including websites, is accessible to people with disabilities.
The EU Web Accessibility Directive and the European Accessibility Act (EAA) are key pieces of legislation aimed at improving digital accessibility for people with disabilities within the European Union. The Directive focuses on public sector websites and mobile applications, while the EAA expands accessibility requirements to a wider range of products and services, including those in e-commerce, banking, and travel.
The ADA is very good legislation and something I'm very thankful for as someone who is completely able-bodied. The reality is private entities won't do jack shit unless you force their hand and threaten them. It sucks it's that way, but that's the reality we have to acknowledge.
And, I benefit greatly from accommodations around accessibility. Both in the physical world and online.
Great, so force the hand of the screen reader makers to do a better job, or force the makers of browsers to integrate them properly, instead of burdening everyone else by piling workaround upon workaround.
So either fix it by changing the legislation, or fix it by changing the FOSS software... or do the only thing you can actually do right now which is implement websites in a way that's most likely to consistently work well with existing a11y solutions.
You can implement your websites with accessibility in mind while also acknowledging its ridiculous how every web developer has to spend time on that because screen readers are terrible, and responsibility somehow got shifted to every web developer ever instead of the handful of companies making screen readers.
I don't loop within loops, I free memory after I allocate it, and I add aria tags to html elements. I don't really see the big deal, just seems like a normal part of the job.
If you just do stuff without reflecting on why it's necessary that's... odd. Two of these examples have actual reasons on why they're necessary, the third is because screenreaders are crap.
I'm not trying to be difficult, but how is it any different than matching what an HTML parser (such as a web browser) expects by making sure you close your tags?
Excellent example because web browsers will render most documents just fine if you don't close your tags. Because they care about being compatible with websites that aren't perfect, and they consider it their job to render all websites that exist. Instead screen readers expect you to change your website instead of working with what's already there.
After a couple decades of relying on pragmatic hacks and loose conventions while hoping developers would start to take accessibility standards seriously, most just seemed to give up hope and concentrate on making software blind people can actually use. And that happened, like, a decade ago.
Imagine how long it would take to load a page of HN search results, or the table of contents of an online book, or a page with a lot of dead links, or a page with links to a whole bunch of non-textual content that it has to figure out is non-textual.
While that would work in many situations, I think the number of edge cases would be too great to make it reliable as a primary mode for communicating meaning in an accessible interface. As an alternative assistive feature? Sure. Something to rely on? I'll believe it when I hear it.
What I have learned after years of working with accessibility experts is that screen readers are largely incapable pieces of junk that need to be lead around manually.
They don't try to be helpful, they only do exactly what they are told.
Frankly I think there's rear space for interruption here, particularly with AI.
The hilarious part is that we somehow wound up in a situation where the screen readers are useless pieces of crap but instead of fixing those every developer making a website is held responsible instead.
It's not adding roles/alt tags/etc. that's the issue. It's finding out that a screen reader doesn't support the ARIA markup (from the ARIA spec) that you are trying to use [1]. -- For example, using aria-describedby on an img doesn't work on most browser + screen reader combinations [2].
If you serve your UI as out-of-order HTML content abusing tables for browser layout, if you merge broken fragments of mismatched XHTML from a content management system to cobble a page together on the fly, if you hide items behind burger menus, if you make interactivity from CSS and minified Javascript to visually look like input boxes and buttons instead of using standard buttons, if you add overlays and blocks to stop people selecting or copying text, if you care nothing about tab order and keyboard shortcuts and image alt text, if you reflow text around images, if you name CSS identifiers with no semantic meaning, if you mix in arbitrary advertising and tracking and framework session state, why is a screenreader "a piece of crap" for not being able to magically infer a human interpretation of the page?
Why is it embarrassing to need to code against standardised accessibility interfaces so that other tools using those interfaces can function? Is it embarrassing to have to code against a database or filesystem interface to persist data, or a graphics interface to show pictures?
The sad reality is that screen readers have a very small market. There isn't a lot of money to be made so not much innovation happens. Maybe with LLMs there will be a new approach. It's something they might actually be good for.
Right, and the insane part is that instead of this small market improving itself the burder is instead shifted to everyone else, even mandated by laws.
> They don't try to be helpful, they only do exactly what they are told.
This is how software should work. Attempting to be "helpful" usually makes things worse. Doing exactly what it's told makes it predictable and usable.
Just look at how much of the HTML 5 spec is a nightmare of parsing rules for handling malformed SGML. Look at how it got there - all the invocations of Postel's law justifying attempting to handle malformed input in "helpful" ways, until things were eventually such a compatibility nightmare that a new spec was created to give precise rules for parsing every single input the same way. "Helpful" was specified away, because it was so broken.
Now if only screen readers provided consistency in following rules, too. They're not in a great state, but your attempted solution is worse.
