How working with a blind client revealed invisible accessibility gaps
A developer's project with a blind client uncovered profound, invisible accessibility gaps within widely used platforms like Microsoft's SharePoint and Power Automate. This experience reveals how the internet is a fundamentally different and often frustrating place for screen reader users, due to systemic design oversights. The story powerfully advocates for proactive accessibility integration, emphasizing that these crucial considerations should be built-in, not bolted-on.
The Lowdown
The author recounts a project where a client's contractual accessibility requirements, intended for their blind and deaf employees, initially seemed like a minor review, but quickly escalated into an 18-hour deep dive into systemic flaws.
- Platform Roadblocks: The accessibility specialist, who is blind and would be a user, immediately encountered issues with Microsoft's browser apps, forcing a switch to desktop versions before even testing the workflow itself.
- The 'Read Only' Tedium: A major discovery was SharePoint's habit of appending "(read only)" to every field on read-only pages, creating an overwhelmingly repetitive and disorienting experience for screen reader users, akin to hearing "(spoken aloud)" after every line of movie dialogue.
- Deep-Seated Platform Issues: Beyond minor implementation tweaks, many problems stemmed from the platforms themselves: Power Automate's native approvals app was invisible to screen readers, JAWS struggled with Outlook approval emails, and SharePoint generated multiple H1 headings, disrupting critical navigation for blind users.
- The 'Noise' Revelation: The author's personal experience with a screen reader highlighted the immense "noise"—labels, status indicators, and repeated phrases—that sighted users subconsciously filter out, but which overwhelm and slow down a listener.
- Workarounds and Advocacy: Where direct fixes weren't possible due to platform limitations, the team implemented workarounds like email updates and created honest training materials for users. The author stresses that accessibility isn't just about compliance but about genuinely understanding diverse user experiences, urging developers to integrate standards from the start and users to report persistent issues.
The experience served as a powerful reminder that most software is built and tested by sighted individuals, rendering crucial accessibility gaps invisible until someone directly affected illuminates them. It underscores the vital need for intentional design and development that prioritizes inclusivity from inception, rather than treating accessibility as a post-launch afterthought.