I'm a teacher and I've had blind students, so I am aware of the barriers. But: do an honest evaluation of the costs of full, correct accessibility vs. the number of people who benefit. A cold-blooded calculation for a company putting out a project.

It honestly is not worth it. Huge costs, and you sell...maybe an additional license or two. So no one does it.

It is revealing how people with disabilities are treated, just to walk on sidewalk as a deaf person. Most cyclicts assume they have a priority on sidewalks, and will ring bell to enforce it. If you do not jump out of their way in 2 seconds, you get rammed.

Cyclists know I can not hear them (I am wearing big noise cancelling headphones). Yet they still insist on their imaginary priority on sidewalks. I was forced to remove my noise cancelling headphones, just to hear their slurs!

Cyclists on bike have no priority, they are not allowed to cycle on sidewalks! They should be using roads! I am allowed to wear my noise cancelling headphones on sidewalk! I looked it up!

> Where I had control, I made changes. Unnecessary labels removed. Accurate alt text added — not filed-in-for-compliance alt text, actually descriptive alt text. The heading structure was cleaned up where I could reach it. For this project's SharePoint tracking page, I rerouted entirely: instead of asking users to fight through the noise, the system now sends an email update at every stage of the approval.

seems to be the only bit of text that actually details anything that was done. I would liked to have read about the actual changes and steps taken to improve accessibility instead of some kind of low key rant about MS

My company has a team of accessibility impacted testers who will assess any web/device work we do. It is invaluable and they can always find things that were missed regardless of how many tools we use to help in development.

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 built actually works well for that target audience.

I'm a fully blind accessibility auditor, remediator and trainer myself, but I wouldn't dare to assume to know how a mobility-impaired user using eyegaze tech fares on a website I've audited.

My eyes don't gaze, so I don't have the context to make those calls.

On that note: I'm looking for work, anyone need me to tell them how their UI is bad for accessibility and fix it for them so they don't get sued later? :P

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 framework just to deliver one feature, dive deep into framework guts to fix the issue (which may be written in an entirely different language and outside your area of expertise), or do some ugly hack on top to sort-of make it work.

A lot of accessibility issues, especially historically, essentially boiled down to "developer chose the wrong approach and didn't know how to get themselves out of the situation later."

It's better now because we went from desktop frameworks drawing their own pixels on screen to web frameworks creating div soup, and div soup is much easier to fix than having pixels instead of native OS controls, but it still happens occasionally. The most recent one I personally ran into was WindScribe, who made a desktop GUI framework of their own for no good reason, and now they can't fix accessibility without a whole lot of work.

> revealed invisible

Interesting that the language of sight is so prevalent that it appears in this very title twice.

Echoing other comments, this would be a stronger article if it went into more specifics, but the AI voice precludes that meaningfully.

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?

The "read only" example is such a good illustration of how accessibility problems often aren't one big broken thing, but a bunch of tiny reasonable-seeming decisions stacked together

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

Note the irony in the title.

> It took 18 hours of work.

So a couple of days plus a few hours. Seems reasonable.

[flagged]

In general you WANNA see any people using your app.

Read an "accessibility" spec or a requirement or a UX "good practice" is not a substitute for see how people use it!

One of my anecdotes from back in the day: The secretary of a school that use the app I help develop call about problems reading data, that comes in CD. We can't do much by phone so I travel to the town to try to debug on site (bring dev tools in the day where that means diskettes and cds, we were transitioning from FoxPro 2.6 DOS to Visual Fox Windows 95).

Eventually after some time the secretary put the coffee cup in the CD tray.

Go figure!