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!
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
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
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?
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.
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.
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!
Accomodations are for people who need them not a shield for hyper-selfishness.
I cycle and I either don't wear any headphones or I use the open ones where I can still hear my surroundings. I assume every driver is eitehr an oblivious idiot or is out to kill me. I assume it's every pedestrian's first day on Earth because that's how it seems. The level of entitlement I see on a daily basis is insane. Runners who refuse to get out of dedicated bike lanes, people who park in dedicated bike lanes, people who get annoyed that I go onto the road when I'm allowed to, people that get annoyed that I go onto the sidewalk or road because I have to (often because the bike path is blocked), people who walk 5 abreast on a shared pedestrian bike path, etc etc etc.
But what really gets me is people who have elevated their own hyper-selfishness into some kind of virtue. "I'm going to block out all noise in a public space because that's what deaf people have to deal with" is a new one for me.
Oh and as an aside, people who are deaf often aren't completely deaf. Deafness (and blindness) is a spectrum.
Well, it appears once in "invisible", and once in "blind"... but I don't see why "blind" is a surprise when talking about someone blind.
There is no reference to sight in "reveal".
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 implement it properly. If that kind of functionality takes a backseat to "stunning" and "beaituful" designs that a bunch of people can't use, we take the user out of user interface.
I've been at this long enough that yes I know that just getting something out the door so we can make money is important.
But this just creates another kind of technical debt that comes back to bite you.
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.
So a couple of days plus a few hours. Seems reasonable.
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 accomplish than modifying our built environment to reduce or eliminate conflict points.
As an aside, I've noticed people get startled when I'm on my bike stopped but balancing on my bike while I wait for then to cross. I think some people intuitively model bikes on the same category as cars, so being anywhere close causes them to react as if a car hard crept close.
It is legal in some places, illegal in as many others, and has caveats almost everywhere (children are almost always allowed, in other places it is based on speed, etc.).
Realistically though I think it leads to the same state of play as everywhere else where pedestrians don't much fancy being hit by a faster moving and taller (if not larger) object so dodge out of the way even if they aren't necessarily obligated to.
(Not all cyclists do this. But the rude ones are common enough that "cyclists" have gotten this reputation.)
People act as people do regardless of their method of conveyance. A polite way of encountering a group walking where they should (and another should not ride) is to dismount the bicycle, say "excuse me" and walk through, then to remount and continue on the bike. In the case you mentioned, calling out in advance "excuse me, coming through" should just do it. If not, step up to bell ringing.
You should see what cyclists from Austin do on the Texas backroads, with their stopping in the middle of the lane at the top of a hill, doing the same on a tight curve, riding abreast... But again, people are people; they don't seem to realize road signs have a setback for a very good reason.
Only motorbikes is tough because people dont like them going past them in traffic jams :/ the last bastion of decency in our traffic xD... (lets forget about people who own racing bikes they dont count)
You're not to blame at all when a cyclist runs you down on the pavement (that they shouldn't be on). Yes, you might have heard the bell without the headphones, but they're the one acting recklessly, and they're the one responsible for ensuring that they don't harm people acting normally.
There are all sorts of situations that it's possible to anticipate, but there's no moral fault ascribed for not acting defensively against every possible form of attack.
GP simply pointed out cyclists are apparently super unfriendly to deaf people, inferred from the experience where GP made himself temporarily deaf.
It doesn't matter whether GP takes responsibility or not. The issue is the social phenomenon where cyclists create danger for themselves and deaf pedestrians.
> I cycle
I know it's bad to stereotype people but you're not helping it.
Listening to music on a walk is a perfectly acceptable thing to do. It’s very slightly less safe for them, but they aren’t risking other people so that’s fine.
You have an affirmative responsibility to act in a reasonable fashion to mitigate risks for yourself and others.
[1]: https://naqvilaw.com/las-vegas-impaired-driving-attorney/lou...
This is the point I am making.
Cyclists do stupid and dangerous things too. Believe me I am aware. I have to anticipate those too.
But, in my experience, nobody acts with more carelessness and selfishness than pedestrians. And I say that as one of them too.
There is no requirement to mitigate all potential harms caused to unexpected hostile sources by the direct actions of unexpected hostile sources.
But if you did want to run a full size model deepseek v4 flash is so cheap that I doubt even many hours of web browsing would have a noticeable cost.
We recently had a client with detailed accessibility requirements written into the contract; something specific to them, not our usual engagement. They have blind and deaf employees who would be using what we built, and they wanted that taken seriously. I respected that going in, but I also figured it would mean a review session, maybe two, a few tweaks, and we'd be good. A couple hours tops.
It took 18 hours of work.
The project was to build a purchasing approval workflow in Microsoft's Power Automate. Their in-house accessibility specialist, who is blind herself and would be one of the actual users of this new workflow, led the review. My plan was to have her log into my account in the browser and do a run-through so we could see where things stood.
That didn't work. According to the accessibility specialist, Microsoft's browser apps aren't great for screen readers, and she couldn't navigate them the way she needed to. Not a big deal. I took a step back, set up a separate set of permissions so she could test from her own account in her desktop apps, and had her go from there.
We hadn't even looked at the workflow yet and the platform was already getting in the way.
Once we were up and running, we'd meet over Zoom (not a random platform choice — we had run calls originally in Microsoft Teams and Google Meet, but she considers Zoom to be the most accessible video conferencing option available). In our test sessions, she'd share her screen and move through the workflow as a real user would. I'd watch and listen along with her, hearing her screen reader narrate the page out loud. This allowed me to hear how she listened, oriented herself, and decided where to go next. This is when it stopped being an abstract problem and became a real one.
At some point during those calls it hit me that the internet I know — the one I navigate by glancing, skimming, clicking — is almost a completely different place for someone experiencing it through a screen reader. Same web, totally different world.
Here's where the title comes from. I'd built a page in SharePoint where users could go to see if their requests had been approved, if they were still pending, and general information about their request. It was nothing fancy, but it did the job. The page had to be shared in read-only mode to ensure no one could accidentally adjust anything in the approval process. This is a relatively standard requirement, but when SharePoint shares a page in read-only mode, it appends "(read only)" to every. single. field. This is fine if you're able to read it, but if you're listening to it, you're hearing that phrase on every line, over and over, for the entire page. Imagine watching a film where after every line of dialogue, a voice reads out "(spoken aloud)." You'd lose the plot pretty quickly. That's how users felt when they navigated this page with a screen reader. And for users with braille readers it's not just tedious — it's physically taking up space on the device. Every redundant character crowds out the actually useful content.
I spent a long time looking for a solution: a way to hide the tags, an alternate way to share progress with requestors, anything. Ultimately, I came to the conclusion that I couldn't fix it. That's just how SharePoint works.
That kept happening. We'd find something, I'd dig in, and the answer would be: the issue is the platform, not the implementation. Power Automate's native approvals app in Teams wasn't recognized by screen readers at all. JAWS (one of the most widely used screen readers) had compatibility issues reading the approval emails in Outlook. SharePoint would generate multiple H1 headings on a single page, which breaks how screen reader users navigate. Headings aren't a visual choice for someone who can't see — they're critical to how you move around a page, the same way a sighted person skims bold text to find their place. Two H1s on the same page creates a false landmark. It was disorienting in a way I wouldn't have considered before this.
I don't say any of this to pile on Microsoft specifically. This is what happens across the software industry when accessibility gets treated as someone else's problem, or a box to check after the fact. It just happens that Microsoft makes the tools a lot of us build on top of, so their gaps become our gaps.
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. Four or five emails per request. A little much for some users, probably. For the users who needed it, it meant they never had to touch the inaccessible page.
Where I couldn't fix things, we worked around them. We built out training materials together — documentation specific to their setup, their screen readers, the quirks they'd encounter. We wrote an honest version of that documentation: here's what we couldn't change, and here's how to get through it anyway. Not a satisfying thing to write, but a necessary one.
I used a screen reader myself at various points during this process, to better understand the experience. The thing that surprised me most wasn't any specific bug or broken interaction — it was the noise. The sheer volume of labels, status indicators, repeated phrases, and structural clutter that a sighted user filters out completely without realizing it. When you're listening to a page instead of looking at it, all of that is just in your way. Every extra word is something you have to sit through before you get to the thing you actually came for.
Most software is built by people who can see and hear, tested by people who can see and hear. That's not an accusation — it's just an honest description of how our industry has operated for a long time, and it means that the gaps tend to stay invisible until someone who actually lives with them shows up and walks you through it. I was lucky that this client had someone like that, and that they cared enough to build real time into the contract for this kind of work.
Not every project will have that. Most won't. But that doesn't mean there's nothing to be done.
If you're a developer, accessibility standards exist and are worth building into your work from the start rather than auditing for at the end. If you're in a position to advocate for tools and processes at your company, it's worth asking whether the software your team uses every day actually works for everyone on that team. And if you're a user who runs into something broken — a label that repeats itself forty times, an approval popup a screen reader can't find — reporting it to the company that built it matters. The more people flag the "(read only)" problem to Microsoft, the harder it becomes to leave it on the backlog.
None of this requires a client with specific contractual requirements to get started. It just requires caring enough and deciding that it's worth paying attention to.
We've been building software for clients for over 25 years. If you're curious about how to make your software more usable and accessible for your team or your next project, get in touch — we'd be happy to walk through it with you.
Interested in learning more about accessibility in software? Here are a few resources to get you started: