LLMs are blind.
Large language models don’t “see” interfaces, buttons, or navigate visually. They live and die by language, and that fact arguably makes LLMs one of the most consequential accessibility developments in the history of computing, not because they were designed for it, but because they can’t help it.
For decades, the blind and low-vision community has relied on screen readers to navigate a world built for sighted people. Screen readers are churning tools: they process content linearly, exhaustively, and without judgment. Every heading, navigation element or paragraph gets equal weight, and the user bears the full cognitive burden of deciding what matters. As one blind IT professional put it on a recent call with the American Council of the Blind: “It’s all linear. Line by line, character by character.”
The closest I’ve come to that experience myself was listening to The Andromeda Strain on audiobook recently. The book contains long passages of fictional computer output – columns of data, line after line – and the narrator read every entry, character by character, exactly as a screen reader would. After about ninety seconds I wanted to skip the entire chapter. That experience, brief and trivial as it was, is the default mode of operation for screen reader users every day.
LLMs invert this entirely. They enable intent-driven, contextual, conversational discovery. “What’s on this page that matters to me?” is a question a screen reader literally cannot answer, but an AI can. Most importantly, it answers in the same modality that the blind and low-vision community already operates in: spoken language. The playing field isn’t being leveled by accommodation, it’s leveled by design.
Real-world impact is already profound.
One BITS (Blind Information Technology Solutions) member describes his morning commute: he has a rolling conversation with an AI, refining ideas and drafting documents. By the time he arrives at work, he has a ready-to-use document built entirely through dialogue. For a sighted person, that’s a productivity hack – but for someone who previously fought a word processor through a screen reader, it’s an order-of-magnitude quality-of-life gain.
The use cases go far beyond screens. On a recent call with ACB leadership and blind technologists, one person described asking AI to walk them through assembling a product by telling them exactly where to put their hands (the kind of thing sighted people do by glancing at pictures on a box), identify kitchen items, navigate unfamiliar businesses, or describe what’s physically around them in real time.
That same person wanted to use AI to read her husband’s medication labels because he doesn’t receive accessible prescriptions, and the bottles pile up. She was blocked by safety guardrails. The irony is hard to overstate: the actual safety risk isn’t the AI reading a pill bottle. It’s the AI refusing to.
But the technology is not perfect.
Hallucinations remain a real concern, from the annoying to the genuinely serious: Zoom shortcuts returned when asked for Microsoft Teams, fabricated video descriptions, walking navigation advice that may be genuinely unsafe. The problem isn’t only the wrong answers, it’s the missing ones. A blind developer built an accessibility tool entirely through AI-assisted coding, giving real-time feedback at every step. When he demoed it for GitHub, a sighted colleague told him the bottom half of the letters were cut off on screen. The AI had access to that visual information the entire time, but it never mentioned it. That’s not a hallucination, it’s an omission, and it’s a design problem the developer community can actually solve.
Everyone on the call agreed that AI is a sea change in accessibility tooling. But the friction points and trust gaps are real, and getting the tooling layer right is the path forward.
The emerging MCP ecosystem is the critical frontier.
The Model Context Protocol (MCP) is creating a new standardized interface layer between AI agents and digital services, including visual presentation layers (formerly known as MCPUI, now MCP Apps). If accessibility is not deliberately designed into the specification now, we risk rebuilding the exact visual-first barriers that left the blind and low-vision community a generation behind during the GUI revolution, the web, and mobile.
As Dan Spoone, former president of the American Council of the Blind, put it: “We’re always adding the accessibility layer in after the fact, and we never catch up. Is there an opportunity here to be equal or ahead of the curve rather than fighting to catch up?”
The answer is yes… but the developer community must act on it now. There is already an open issue on the MCP Apps repository (#431) focused on accessibility. The community organizations are ready: ACB’s BITS working group is just one example, and includes blind software engineers, accessibility managers, and researchers who do not want to be consulted after the fact. They’re already building tools, filing issues, and presenting at conferences; they don’t just need a seat at the table, they need the table to be built accessibly from day one.
Cost remains the most immediate barrier.
Usage-based pricing models, capacity constraints, and subscription tiers risk gating behind an economic wall one of the most impactful tools this community has adopted. During our call, several people noted recent shifts (such as GitHub Copilot moving to usage-based billing) that are already making the tools feel less financially accessible, even as some providers expand free-tier access in response to demand. If AI is effectively assistive technology – and for this community it unambiguously is – then accessibility includes affordability.
Here’s what acting now looks like.
The first concrete need is a co-developed set of use cases that distinguishes two blind constituencies: technologists already building with AI, and end-users who will consume AI-mediated information, often without knowing AI is involved. These groups have different needs, and the field has a precedent worth learning from. Screen readers ended up convoluted in part because they were designed by developers, for developers, with non-technical end users consulted late or not at all. The MCP community has a chance to invert that order.
For MCP spec contributors and App developers: issue #431 on the ext-apps repository is open and active. Treat accessibility as a design constraint for MCP Apps, not a workstream queued behind the v1 launch. But the test is no longer “does the screen reader handle this correctly” – that’s the churning paradigm. The test is whether an MCP App makes its full functionality available through conversational, intent-driven interaction. Screen readers remain a valid output channel where they’re appropriate, but they’re not the benchmark.
For AI providers: recalibrate safety guardrails so they fail toward usefulness rather than reflexive refusal for legitimate accessibility use cases. And recognize that for this community, affordability isn’t a separate conversation from accessibility, it’s part of the same one.
For the Linux Foundation and conference programs: host a working session at an upcoming event that brings four groups into the same room: spec maintainers, AI providers, blind technologists, and blind end-users. The last group is the one most likely to be missing if convenings are organized through developer channels alone, which is exactly the problem worth solving.
The window is narrow because MCP is being defined right now, by a relatively small community that is unusually open to input. That won’t be true for long.
The case for acting now isn’t only about what’s coming, it’s about what’s already been given.
The foundation of what makes AI work was built, in no small part, by accessibility itself. Alt text, captions, semantic HTML, audio descriptions – all of that structured, labeled content became the training data that made large language models possible. The accessible web paid forward a semantic dividend it never anticipated. The question now is whether we will honor that debt by building the next layer with the same care – but this time building alongside them.
Phillip Lamb is a Senior Solutions Architect at ClickHereLabs and CEO of Live Oak Digital, an AI enablement consulting practice. Through Live Oak he has been working with the American Council of the Blind on accessibility-focused AI integrations, including modernizing their Audio Description Project and developing a grant-funded MCP server implementation. He attended the recent MCP Dev Summit in New York City, where conversations about accessibility in AI tooling led to this article.