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