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

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.

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.

I'm embarrassed for the screen reader software for needing so much help.

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?

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.

Oh look, personal attacks. Good argument!

Oh look, a person who has been commenting low-effort, trolling, lying, rude, one-liners is suddenly super concerned about high quality internet argument rules when it suits them.

Are you going to address how your claims about the abilities of search engines are lies? How your comparison with "my eyes" is bad-faith and irrelevant? Or any of the other relevant points I made over multiple comments?

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.

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

[1] https://www.powermapper.com/tests/screen-readers/aria/

[2] https://www.powermapper.com/tests/screen-readers/labelling/i...

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

Most blind people don't even use a Mac, they use JAWS or NVDA on Windows.

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

I think the AI argument is muddying the waters. I don't think I'm being arrogant in saying it's not that complicated a problem.

Simply either read the surrounding text (possibly by additional instruction) or the URL. I can't fathom how that's a difficult task.

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.

Because you can't trust people to do extra work themselves.