How working with a blind client revealed invisible accessibility gaps
Uncovering the Invisible: Lessons in Accessibility from a Power Automate Project
By Sharni Zaugg | June 3, 2026 | ⏱️ 6 min read
Recently, I embarked on a project where accessibility wasn't just a "nice-to-have"—it was a contractual mandate. The client employed individuals who were blind and deaf, and they required a system that genuinely respected those needs.
Initially, I approached this with a standard mindset: I figured a couple of review sessions and some minor adjustments would suffice. The goal was to develop a purchasing approval workflow utilizing Microsoft Power Automate.
The Reality Check
The review process was spearheaded by the client's internal accessibility expert, who is blind and would be a primary user of the tool. My first instinct was to have her log into my account via a browser for a walkthrough. However, she immediately pointed out a critical flaw: Microsoft's browser-based applications are poorly optimized for screen readers, making navigation nearly impossible for her.
I had to pivot quickly:
- I established a unique set of permissions.
- I enabled her to test the system via her own account.
- I shifted the environment to desktop applications.
Before we even touched the actual workflow, the platform itself had already created a barrier.
Tooling for Inclusion
Interestingly, our choice of communication tool was deliberate. While we tried Microsoft Teams and Google Meet, we settled on Zoom, as the specialist found it to be the most accessible video conferencing software available.
A Different Version of the Internet
As I watched her share her screen and listened to her screen reader narrate the interface, I had a profound realization. The internet I navigate—characterized by glancing, skimming, and clicking—is a fundamentally different place for someone using a screen reader.
The "Read-Only" Noise
I had designed a SharePoint page where users could track the status of their requests. To prevent accidental edits, the page was set to read-only mode. While this seems like a standard security measure, the platform's implementation was disastrous for accessibility.
SharePoint appends the phrase (read only) to every single element.
The Experience: Imagine watching a movie where, after every single line of dialogue, a narrator says, "(spoken aloud)."
For a sighted user, this is a minor visual detail. For a screen reader user, it is an endless loop of redundancy. For those using Braille readers, it's even worse—the extra characters physically crowd out the meaningful content.
// How a screen reader perceives the SharePoint page:
"Request ID 123 (read only)"
"Status: Pending (read only)"
"Amount: $500 (read only)"
"Approver: Jane Doe (read only)"
The Platform Gap
I spent hours searching for a workaround—trying to hide tags or find alternative sharing methods—only to realize that the problem wasn't my implementation; it was the platform architecture.
| Platform Component | Accessibility Failure | Impact |
|---|---|---|
| Teams Approvals App | Not recognized by screen readers | Total loss of functionality |
| Outlook Emails | Compatibility issues with JAWS | Difficulty reading approval notices |
| SharePoint Pages | Multiple H1 headings | Breaks structural navigation |
For a blind user, headings aren't about aesthetics; they are the primary map for navigating a page. When a platform generates multiple H1 tags, that map is destroyed.
Shifting the Approach
I don't believe this is unique to Microsoft. This is the result of an industry culture where accessibility is treated as a priority a checkbox to be ticked at the end of development. Because we build on these platforms, their inherent flaws become our flaws.
To solve these "invisible" gaps, we took the following actions:
- Enhanced Alt Text: Moved beyond compliance-based descriptions to truly descriptive, useful alt text.
- Workflow Rerouting: Since the SharePoint page was too noisy, I bypassed it entirely. The system now triggers an email update at every approval stage.
- Honest Documentation: We co-created training materials that didn't sugarcoat the experience. We documented exactly what couldn't be fixed and provided strategies to navigate those hurdles.
- Empathy Testing: I began using a screen reader myself to experience the interface.
Final Reflections: The Cost of Noise
The most shocking discovery wasn't a specific bug, but the sheer volume of "noise." Sighted users subconsciously filter out labels, status icons, and structural clutter. For a screen reader user, every redundant word is a hurdle.
We can quantify the cognitive load like this:
Most software is designed and tested by people who can see and hear. This isn't an accusation, but a description of the status quo. The gaps remain invisible until someone who lives with them walks you through their world. I was lucky enough to have that guide.