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.
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.
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.
> See our latest news, request a catalog. The latest board minutes. Product documentation. If you have any comments about our web site, email us, or call. If you were confused by this, let us know it met your expectations. See how many people have visited our internet web site.
Which imho is not any better, and arguably worse.
See our latest news
request a catalog
Read the latest board minutes
Product documentation
email us with questions about our website
Call us
So a little indicator that these are links without "click here" and now the link text is very informative. But this would look like a menu.
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.
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 would suggest that "click here" is more concise, meaningful, and well understood than "follow this link" or alternatives.
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.
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.
If you need to disambiguate or further clarify links, well, you should also set the title attributes too. That ought to help.
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.
- 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.
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.)
https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-...
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.
I would still include more of the action, i.e., ”Get Amaya“ instead of ”Amaya“ as in the article.
Crucially: screen reader navigation is NOT the same as keyboard navigation.
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.
Click here for screen reader accessible version
It’s like… ‘click here. No, here. Left a bit. Almost. Come on, you can get it. What are you, blind or something?’
You can use something like macOS VoiceOver right now to see how it behaves.
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.
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.
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...
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.
Sure, sure, we need to accommodate people with disabilities. First step to get there is to make sure the accessibility software isn't trash.
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.
And, I benefit greatly from accommodations around accessibility. Both in the physical world and online.
Is this how you want these discussions to go?
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.
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?
Yes, or it can summarize the text and explain what the link is to.
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.
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.
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'.
Simply either read the surrounding text (possibly by additional instruction) or the URL. I can't fathom how that's a difficult task.