How working with a blind client revealed invisible accessibility gaps • Hacker News Board

Re: How working with a blind client revealed invisible accessibility gaps

#81

Post by Tepix » Sat, Jul 04, 2026, 2:53 AM UTC

zersiax wrote: post #47

Tepix wrote: post #5

While the content was interesting, the AI-slop-stench was repelling. Talking about AI (sorry!), perhaps an AI assisted screen reader could remove repetitive elements ( it appends "(read only)" to every. single. field. ) in a smart fashion? Does this already exist? We're seeing AI being used to improve a11y in quite a few places: (Live) transcripts for video conferences, image to text (VQA, visual question answering)…

No. There are certainly AI-generated accessibility solutions for single, existing applications, games and websites but no outright AI-powered screen reader. I'd think the token cost alone would make such a project prohibitively expensive, although one-off AI features are starting to sneak into JAWS and NVDA as we spaek, so who knows.

A relatively small and fast LLM (30b MoE) would probably suffice. It‘s something you can run locally with a nice GPU.

Re: How working with a blind client revealed invisible accessibility gaps

#82

Post by analog31 » Sat, Jul 04, 2026, 3:27 AM UTC

shermantanktop wrote: post #78

analog31 wrote: post #73

Earlier quoted context omitted.

The statistics still point towards being more concerned about cars.

Statistics don’t lie, but my experience doesn’t lie either. 90% of the assholes I encounter on the road are on bicycles. FWIW, I live in Seattle, a famously bike-friendly city. Stop signs, red lights, pedestrians and even one-way street signs don’t seem to exist in the visual field of many cyclists here. Obviously there are reasonable law-abiding bicyclists out there. Certainly all the cyclists online say they obey a…

What I've noticed is that the crimes of motorists, cyclists, and even pedestrians, are crimes of opportunity and convenience. In each case it's a matter of what's possible, offset by the chance of enforcement.

Motorists exceed the speed limit, roll through stop signs, and are looking at their phones while driving.

Cyclists blow through stop signs, and take advantage of shortcuts.

Pedestrians "jaywalk." There's not much else they can do.

Re: How working with a blind client revealed invisible accessibility gaps

#83

Post by troglodytetrain » Sat, Jul 04, 2026, 11:06 AM UTC

So, at this point any company that doesn’t want ai agents navigating on their webpages have to kill the accessibility.

And they do and will. Blind users are a tiny tiny part of users. But hurting usability for the disabled is bad PR. So of course they do it “accidentally”.

Re: How working with a blind client revealed invisible accessibility gaps

#84

Post by lproven » Sat, Jul 04, 2026, 11:35 AM UTC

asadotzler wrote: post #70

8bitsrule wrote: post #44

Revealing that, after 30 years of Internet, someone's actually confronting this situation for the first time. So's the word 'gaps' ... as if the English Channel is a 'gap' for swimmers. Equally revealing is the audio quality of most CPU screen-readers (regardless of platform). Usually, not far from the crappy first attempts of 30 years ago. But then, hey, it's a small market, right?

Most people who depend on screen readers prefer the synthetic voices for their consistency which can allow them "read" at far faster speeds. I've been working for a couple of years to reach the speed one of my friend regularly works at, about 900 WPM. I topped out around 550 WPM with the human-sounding voices and then almost immediately got to 650 moving to a synthetic voices. Still a long way to go to hit 900, but I…

I've been occasionally helping a blind friend of mine with his PC since 2005. His screenreader talks at about 600wpm or more and after 20 years of practice I can't understand it.

I speedread and can read text faster than his computer's voice -- but not by much. It is very impressive, and very hard to use.

But I am the only sighted person he's met who can use his PC. I navigate Windows mostly by keyboard, and he has no mouse. It slows me down slightly but I can still use it.

(He does have a screen on his family computer, so sighted family and friends can watch films with him. His work one has no screen.)

Re: How working with a blind client revealed invisible accessibility gaps

#85

Post by zersiax » Sat, Jul 04, 2026, 11:38 AM UTC

neverartful wrote: post #60

zersiax wrote: post #49

Honestly the fact that this article still needs to be written in 2026 is the designated real-big-sad imho. Screen readers almost entirely ignore the visual layer of any UI, and are entirely dependent on the layer that most developers ignore because it's not the visual layer. It's a perfect storm. It stands to reason that someone who's actually used to using a screen reader should be brought in to verify what you've b…

I'd like to connect with you offline for further conversation. I didn't see any contact information in your profile (and there's none currently in mine either).

I'm not a hard person to find. My hackernews handle into a search engine gets you myriad ways to contact me (Mastodon, LinkedIn, etc.) but I'm at florianbeijers [at] google's mail service if email is your preferred mode of communication. I have a website at florianbeijers.xyz with a contact form, its just very much a placeholder and not really currently meant for public consumption until I revamp it

Re: How working with a blind client revealed invisible accessibility gaps

#86

Post by zersiax » Sat, Jul 04, 2026, 11:43 AM UTC

ryandrake wrote: post #57

zersiax wrote: post #45

Earlier quoted context omitted.

The solution, that accessibility advocates have been clamoring for for decades now, is to s"shift left". If you know you're going to add accessibility, which ... we have had WCAG since 2005, not knowing that at this point is negligence imho, just make sure you work with frameworks and libraries that won't require overhauling all the things when the PO or management finally get sued into letting devs actually implemen…

We should stop thinking about accessibility as if it's some kind of feature that you "add" into the product later in development. This "add it later" mentality doesn't work for security, and it definitely doesn't work for accessibility. Like security, accessibility should be baked into the product's design from the very beginning. It should be part of the product's basic requirements.

Doesn't work for security, not for accessibility, not usually for localization and internationalization, it doesn't work for bandwidth optimization... yet we all keep making UIs that really only work on 300 inch Apple Studio displays and screw anyone who isn't Murrican, rich, in a place with good internet, able-bodied and preferably willing to fork over all their personal data, voluntarily or involuntarily. There's a reason people burn out doing accessibility work, it's incredibly draining to have to swim against the current as much as we do, and actually HAVING a disability compounds that problem. We know how to do it best because we live this life, yes, but we also take the brunt when someone up top decides forking out a 3000000 dollar bonus to the CEO is more important than actually enabling users to use the product.

Re: How working with a blind client revealed invisible accessibility gaps

#87

Post by zersiax » Sat, Jul 04, 2026, 11:46 AM UTC

TimByte wrote: post #35

miki123211 wrote: post #27

The annoying and counterintuitive part of accessibility work is that there are some architectural decisions that are very hard to undo, don't seem that significant, but will absolutely bite you when you need to implement accessibility. If you decide on a GUI framework which doesn't communicate semantics to the underlying APIs properly, you have no good options. Either you rewrite your entire project in a different fr…

The web has its own problems, but at least bad HTML is often still visible enough to repair. A custom canvas-like desktop UI can be basically a black box to assistive tech

Very true :)

I had this exact issue with the Elgato StreamDeck user interface, which renders the macro buttons as one big canvas only drag-and-drop interacts with.

It's rare that I outright cannot figure out a way to make a UI accessible, but that one managed to break everything I tossed at it. I eventually switched my effforts to an open-source third party client which had a web UI, which is now accessible to screen reader users.

As for repairing HTML, my last few engagements have clearly shown me that while HTML CAN be repaired, many devs these days wouldn't know where to even begin to do that. The amount of hand-holding I've had to do has made me suggest, several times, to just give me git access as it'd be faster if I just fix it myself.

Re: How working with a blind client revealed invisible accessibility gaps

#88

Post by hulitu » Sun, Jul 05, 2026, 1:42 PM UTC

estebank wrote: post #51

TimByte wrote: post #31

Earlier quoted context omitted.

Sidewalks have to be usable by people who can't hear, people moving slowly, kids, older people etc. If a cyclist is on a sidewalk and can't safely pass without the pedestrian reacting instantly, they're the one creating the problem

We can't individual responsibility our way out of systemic problems. Cyclists on sidewalks generally signals terrible bike infrastructure. There are people on bikes that ride like an asshole. There are people on cars that drive like an asshole. Both cause (different levels of) risk for pedestrians. There's only so much we can do about assholes, social ostracism works only so far and social change is much harder to ac…

> Cyclists on sidewalks generally signals terrible bike infrastructure.

No. It signals cyclists not giving a fuck about the law. In at least some EU countries, it is illegal to cycle on sidewalks, except with children.