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

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.

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.

It's a travesty how much "Freedom" Scientific charges for a developer JAWS licence

>By reading surrounding text

Yes, or it can summarize the text and explain what the link is to.

LLMs attempt that, but their success is mixed - sometimes the summary is very bad.

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.

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.

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.

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

One would hope those work the same in every browser + screen reader + language combination, but alas, it is not so.

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.

So maybe those user agents (the browsers and screen readers) should fix their shit instead. Crazy idea, I know.

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.

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.

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.

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.

And yet we close our tags anyway, so even if screen readers are better, we wouldn't change our behavior. So I still don't get it.

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.

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.

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

It's less reliable than the author just telling you what it is. And more expensive too.