When calling the user to action, use brief but meaningful link text that: provides some information when read out of context explains what the link offers doesn't talk about mechanics is not a verb…
When calling the user to action, use brief but meaningful link text that:
- provides some information when read out of context
- explains what the link offers
- doesn't talk about mechanics
- is not a verb phrase
An example
For instance, avoid the following sentence on your page:
To download W3C's editor/browser Amaya, click here.
or:
To download Amaya, go to the Amaya Website and get the necessary software.
Both of these sentences divulge too much of the mechanics of getting the Amaya software. If you want to call your reader to action, use something like:
Get Amaya!
Note that "get" is left out of the hypertext; we do not recommend putting verb phrases in link text. Thus, rather than:
Tell me more about Amaya.
You should write:
Tell me more about Amaya: W3C's free editor/browser that lets you create HTML, SVG, and MathML documents.
Further Reading
About the "QA Tips"
The W3C QA Tips are short documents explaining useful bits of knowledge for Web developers or designers, hosted and produced by the Quality Assurance Interest Group at W3C.
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.
Learn more about the Tips, how to submit your own pearls of wisdom, and find all the other QA tips in the Tips Index.
Read the original article
Comments
By crazygringo 2025-07-0214:1511 reply I couldn't disagree more. Their "bad" example:
> To download W3C's editor/browser Amaya, _click here_.
Is extraordinarily clear. I'll click the link and it will either download directly, or it will be a download page.
In contrast:
> Get _Amaya_!
That suggests a link to the Amaya website, not a download page. That's not effective for a download.
Similarly:
> Tell me more about _Amaya_: W3C's free editor/browser that lets you create _HTML_, _SVG_, and _MathML_ documents.
This is terrible. It's not about downloading, and "tell me more" is the command, but not linked! For all I know, the "Amaya" link goes to a corporate landing page, not the "tell me more" information I actually need.
The conventional uses on the web are totally fine:
> To download W3C's editor/browser Amaya, _click here_.
> _Download Amaya_, the W3C's editor/browser.
The idea that links shouldn't be verbs seems very silly to me. Links should absolutely be verbs, when they involve an action like downloading or finding out more. Obviously that's different from "reference" links like in Wikipedia, where you're finding more about a topic.
And "click here" makes it exceptionally clear that a link isn't merely a reference link, but an action link. When I see:
> Get _Amaya_!
That... doesn't tell me how to get Amaya. That tells me "Amaya" is a reference link, not a download link.
Use a screen reader. Tab through the links. All you hear is, "click here." That's not helpful.
Build a search engine. What information does "click here" offer your index?
I agree with you that verbs don't seem all that problematic. Except when the verb is click and the object is here. I can stomach a link whose text is "Click Here to download Amaya," but if the link is literally just the two words, "click here," it is indistinguishable from others in many different contexts.
By danillonunes 2025-07-0216:121 reply 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.
By burningChrome 2025-07-0216:541 reply 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.
By danlitt 2025-07-0219:16 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.
There are techniques to solve that, however:
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.
By layer8 2025-07-0218:28 It's a hack either way. Screen readers really should support the title attribute like they do for image links; or maybe HTML should have had an alt attribute for <a href> as well.
When using a mouse pointer, you also want that information as a tooltip.
At one point does accessibility decrease accessibility? I'm all for making improvements in the name of accessibility, but not so much about making things worse to support the least common denominator of screen readers. If people are going to need to change their behavior, wouldn't it be better to suggest some aria annotation instead?
By CoffeeOnWrite 2025-07-0215:253 reply Links are for clicking. Click here is superfluous noise.
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.
By mitchdoogle 2025-07-0218:211 reply 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
By danlitt 2025-07-0219:18 Note that all of these would fail the criteria in TFA - either as verb phrases, or not clearly describing the link target.
> 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.
By wvenable 2025-07-0219:00 I'm not specifically talking about "click here". I'd say it has it's place sometimes but it's rare. But I lot of developers have issues with redundancy or explicitly spelling things out for users for things that are "obvious".
With enough experience you learn that what is obvious is a less obvious than it appears.
By mat_b 2025-07-0218:34 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.
By Dylan16807 2025-07-0218:16 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.
By madeofpalk 2025-07-0216:52 > accessibility decrease accessibility
accessibility is usability. build products that are usable by people. that's all.
By hombre_fatal 2025-07-0214:561 reply Aria tags are something you think might have more developer compliance than better anchor text?
Most of us never wrote an aria attribute in our life.
But I haven't used "click here" as anchor text in 20 years because it sucks for these reasons.
I think the links just need to be longer vs a couple of words.
We are used to small areas, but the problem is that you end up with 'click here', like in the example. But if you linked the whole text, it's basically the same thing as adding aria.
IMO, most cases that I see using aria seem like a fix after the fact vs doing it the right way.
There are use cases for it, but in the case of the example, making the whole sentence a link would be good.
Regarding screen readers, you can have it read all links, which is why the 'click here' is an issue. So you want a balance. Change "for x, <a href=...>click here</a>" "<a href=...>for x, click here</a>"... ta-da?
You need to optimize for people using accessibility tools, but also for the people looking at the site...
> Regarding screen readers, you can have it read all links, which is why the 'click here' is an issue. So you want a balance. Change "for x, <a href=...>click here</a>" "<a href=...>for x, click here</a>"... ta-da?
No, you want the verb to be whatever "x" does or is for, not the action taken to get there. The action taken to get there is the same for all links regardless of what they're for. So this is a bad example simply because we don't know what "x" is so we don't know what a better verb would be.
By rovr138 2025-07-0218:21 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.
By crazygringo 2025-07-0218:313 reply 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.
By theteapot 2025-07-0218:55 In contrast, using descriptive link text does seem extraordinarily easy.
By cube00 2025-07-0218:47 > 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.
By 01HNNWZ0MV43FF 2025-07-0218:53 Do you use `aria-label`, then?
I'm sorry, should we design websites around SEO, or should search engines just use context properly?
Search engines and websites are going to be subsumed by LLMs, so it's not like this argument matters anymore.
The general consensus is that the dislike of AI is so strong, that a large chunk of the population will disregard something if they even think it is generated by AI. Also, the LLMs need a continuous feed of new, original material to ingest or they'll be all thumbs.
While the long-running trend of SEO stuffing from low-value content farms has polluted search results for years now, Google didn't really care about fixing that problem because there's a perverse incentive to generate more ad revenue by making the first page results usesless. Who cares about doing the right thing? Daddy's got to get his quarterly numbers up. I should also note that those content farms were also early adopters of genAI as we know it today.
Infinite growth isn't a thing. Every cancer eventually kills its host.
Are you sure that’s the general consensus about AI? HN has a very intense relationship with this stuff, because we have hardcore boosters and hardcore skeptics. Among people I meet offline the feelings seem a lot weaker in either direction.
By bigbuppo 2025-07-0217:21 As best I can tell, your typical person here doesn't tend to hang out with normies, which definitely skews things.
By echelon 2025-07-0218:23 > 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.
By c22 2025-07-0216:25 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.
By tgsovlerkhgsel 2025-07-0218:371 reply 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.
By cube00 2025-07-0218:51 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.
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.
By jkestner 2025-07-0216:40 Scannability is one of the reasons my formula is to link a complete descriptive phrase, like “Read more about hrefs,” or “take a survey on meeting times.” Links can be long, and probably doesn’t hurt SEO.
I often want a second source to first check if that is trustworthy: copy paste amaya while having to not accidentally click it is annoying, since often linebreaks and multiword names or company+product splits occur. Selecting and reading text should be easy. Navigating HTML should be wanted, not accidental.
Therefore, the ``click here'' works best for me.
PS
- "_Get Amaya_" should start a file transfer.
- "Get _amaya_ over there!"
sounds like "okay next site will be info dump before actual download", which is acceptable to gather trust like brand or imprint recognition over there instead of googling now.Ideally browsers would have a shortcut to enter a text selection mode - this would also fix the annoyance of sites disabling text selection on certain elements.
The Newpipe app on Android has such a mode for Youtube descriptions.
By nayuki 2025-07-0216:05 > 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.
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.
By Diggsey 2025-07-0219:20 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.
By quietbritishjim 2025-07-0214:40 > > 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.
By sgustard 2025-07-0216:00 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].
By 1-more 2025-07-0216:57 "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.
By layer8 2025-07-0215:03 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.
By anotheryou 2025-07-0217:09 Agreed.
I'd suggest:
_Download Amaya here_, W3C's editor/browser
or
W3C's editor/browser: _Download Amaya here_
By 1317 2025-07-0216:37 I like "_To download W3C's editor/browser Amaya, click here_."
By turboponyy 2025-07-0215:00 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.
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).
By iLoveOncall 2025-07-0217:50 Yes and we all know that websites are not built to be consumed by humans, so this argument makes perfect sense.
By robin_reala 2025-07-0212:2410 reply If you think about this from an accessibility point of view, screen readers for blind users present a linear view of a page. To escape from the linear view, they also typically allow users to access lists of elements like headers and links, out of context of their original position. If every link is labelled “click here” then you’re effectively removing non-linear access from those users.
And if every link is just "Amaya" without verbs you can't tell what's what. So I think "get Amaya" and "go to the Amaya website" are rather fine.
Also poor form is to have your download button on github.io pulling an executable from malware sites like sourceforge. I'm looking at you wxMaxima.
By jchw 2025-07-0213:48 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.
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.
I don't think it's suggesting "Amaya website" is an incorrect or bad phrase in and of itself, I think it's just using the different passages to show how they'd prefer you style links in hypertext.
These days I don't think you'd find many people following this style guide, but I think I understand what they're going for. They seem to be making the prose neutral to the technical details; after all, if you're keyboard navigating, maybe you're not "clicking" per-se. Maybe the pages are printed onto paper, etc.
I do agree "Click Here" is bad because you need to read the context to know what "Here" is, and for the accessibility reason my GP mentioned.
By jchw 2025-07-0214:02 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.
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.
By bornfreddy 2025-07-0214:16 I can assure that there were good and bad pages then, the same as there are good and awful pages today.
By oneeyedpigeon 2025-07-0214:01 > 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.
Describing bundled adware as "fostering a sustainable ecosystem" while portraying Chrome as "forced malware" is a hell of a take.
Of course I exaggerated it on purpose, but think about it:
Remember, in ~2010, it was a trend to add toolbars to Internet Explorer (it was called BHO I think?)
These toolbars were changing the search engine for Bing, Yahoo, etc. This is why they were called "Yahoo toolbar".
But then, came Chrome, which was bundled among other in:
- Adobe Flash Player updates
- Java Runtime Environment (via Oracle)
- CCleaner
- Avast and AVG installers
- Many download portals (e.g., Softonic, CNET Download.com, SourceForge)
So, the objective of Chrome, instead of replacing the search engine with a toolbar, it was to do it by installing a new app, but this is exactly the same goal. At the end, the goal of Google was not the save the web, it was to replace the search engine and display ads on these pages (+ make sure that the targeting + rendering is under their control).
By ceejayoz 2025-07-0213:54 The toolbars were bad, too.
By StableAlkyne 2025-07-0213:56 If an ecosystem can't be maintained without bundling malware (adware is by definition malware), then maybe that ecosystem shouldn't exist.
By wussboy 2025-07-0213:52 I feel like negative opinions are facts.
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.)
By cluckindan 2025-07-0213:301 reply For a more up-to-date version, see WCAG 2.2:
https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-...
By layer8 2025-07-0213:40 Thanks, I updated the links.
By bevr1337 2025-07-0215:44 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.
By amenghra 2025-07-0213:52 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
By joelanman 2025-07-0215:59 it's true, but these are more fragile than simply having clear link text, especially over time as a site is maintained
By MangoToupe 2025-07-0213:292 reply 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.
By hombre_fatal 2025-07-0215:09 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.
By nodar86 2025-07-0213:58 This sounds like a great idea, does anyone know a tool like that?
That’s a good argument.
I would still include more of the action, i.e., ”Get Amaya“ instead of ”Amaya“ as in the article.
By mattl 2025-07-0215:32 But you’re not getting anything. You’re just surfing to the Amaya website.
By cluckindan 2025-07-0213:20 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.
By bmacho 2025-07-0214:04 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.
By Vegenoid 2025-07-0217:16 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.
By rerdavies 2025-07-0213:34 Sure. but who labels every link in there header as "click here"? A completely different use-case from inline hyperlinks.
By stogot 2025-07-0212:42 That’s amsomething I had not considered that changes my mind on this
By charcircuit 2025-07-0212:273 reply A screen reader should be smart enough to read out what the link is for.
By hombre_fatal 2025-07-0212:293 reply How do you imagine that working? By reading surrounding text or by reading the URL? Those are worse experiences than descriptive anchor text.
You can use something like macOS VoiceOver right now to see how it behaves.
By crazygringo 2025-07-0214:201 reply > 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.
By account42 2025-07-0215:53 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.
By charcircuit 2025-07-0212:452 reply >By reading surrounding text
Yes, or it can summarize the text and explain what the link is to.
By bluGill 2025-07-0213:16 LLMs attempt that, but their success is mixed - sometimes the summary is very bad.
By DrewADesign 2025-07-0213:341 reply 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.
By charcircuit 2025-07-0215:31 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.
By AlienRobot 2025-07-0212:591 reply 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...
By cluckindan 2025-07-0213:222 reply One would hope those work the same in every browser + screen reader + language combination, but alas, it is not so.
By ndriscoll 2025-07-0214:29 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.
By snickerdoodle12 2025-07-0213:322 reply So maybe those user agents (the browsers and screen readers) should fix their shit instead. Crazy idea, I know.
By cluckindan 2025-07-0213:381 reply 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.
By snickerdoodle12 2025-07-0213:391 reply 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.
By cluckindan 2025-07-0213:441 reply 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.
By snickerdoodle12 2025-07-0214:061 reply Yes, and it's an embarrassment and a failure to legislate the right thing.
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.
By snickerdoodle12 2025-07-0214:371 reply Yes sir, thank you sir, I will never complain about stupid laws again, sir.
Is this how you want these discussions to go?
> complain
I guess at some point this button gets a bit worn out and I start wondering what pushing the "do something about it" button will do.
By snickerdoodle12 2025-07-0215:20 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.
By DrewADesign 2025-07-0213:39 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.
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.
By snickerdoodle12 2025-07-0213:331 reply 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.
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.
By snickerdoodle12 2025-07-0214:051 reply I'm embarrassed for the screen reader software for needing so much help.
By jodrellblank 2025-07-0215:281 reply 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?
By snickerdoodle12 2025-07-0215:422 reply 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.
By SoftTalker 2025-07-0216:291 reply 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.
By snickerdoodle12 2025-07-0216:37 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.
By jodrellblank 2025-07-0216:261 reply [flagged]
By snickerdoodle12 2025-07-0216:38 Oh look, personal attacks. Good argument!
By rpd9803 2025-07-0213:48 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'.
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.
By charcircuit 2025-07-0215:29 Because you can't trust people to do extra work themselves.
By scary-size 2025-07-0212:242 reply The UK's Government Digital Services make a similar recommendation [1] in their accessibility guidelines.
We frequently reference this website / guideline for a reference of maximally accessible components / web design, it's really good. Not the prettiest (thick black / yellow borders on form components and the like), but accessibility trumps design.
By dkdbejwi383 2025-07-0212:423 reply > accessibility trumps design
Good design is accessible by nature. Otherwise it’s just sparkling wank.
By bigDinosaur 2025-07-0213:32 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.
By rpd9803 2025-07-0213:52 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.
By SilasX 2025-07-0214:53 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.
Their recommendation is very different.
W3c says:
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.*Get Amaya* *Read more about Amaya*Personally, I think both are confounding two different use cases. Links are often used inline in text. The use case that W3c and the Home Office are addressing are use cases that would be better address by out-of-line buttons:
But both seem broken when the use case is hyperlinks in inline text.[Download] [Documentation]To use a concrete example, how should one rewrite the following?
I get the objection. But the fix seems unacceptable:PiPedal is a guitar effects pedal that runs on Raspberry Pi. To download PiPedal, *click here*. To read the documentation, *click here*.
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. Get Pipedal. Read 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"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*.
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.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.And in the very first example given, the text is from a lede in a web page where concision matters.
Is that really an accessibility issue? particularly when there's are buttons right above it that sayTo download PiPedal, click *here*.
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.[ Download ] [ Documentation ]To download PiPedal, visit the *Download Page*.By manarth 2025-07-0213:32 PiPedal is a guitar effects pedal that runs on Raspberry Pi. You can *download PiPedal*, and learn more in the *PiPedal documentation*.By stavros 2025-07-0213:00 I can't believe you verbified "noun".
By LocalPCGuy 2025-07-0213:26 > ...accessibility issue? particularly when there's are buttons right above it that say...
Yes, those buttons may not be "in context" when the page is not being viewed in a visual medium.
> To download PiPedal, click here.
Another appropriate link in this case could be simply:
Or like your last example, just link it slightly differently to emphasize the action:*Download PiPedal* now!To *download PiPedal*, visit the Download Page.By hapidjus 2025-07-0213:23 PiPedal is a guitar effects pedal that runs on Raspberry Pi. *To download PiPedal, click here*. *To read the documentation, click here*.
