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.
The Problem
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.
What We Did About It
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.
Want to Talk More?
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:
- Fundamentals of accessibility — W3C Web Accessibility Initiative
- WCAG Quick Reference — WCAG 2.0 guidelines
- Mobile accessibility considerations — W3C mobile mapping
- The Accessibility Project — community-driven resource
- Pa11y — automated accessibility testing
- WAVE — web accessibility evaluation tool
- Manual testing guide — Harvard accessibility testing