Native Speakers: Why AI's Most Powerful Users Are Blind

* Phillip Lamb Solutions architect and writer working across AI, infrastructure, and accessibility * Liad Yosef AI Lead | Co-Creator MCP Apps | Co-founder of Ora ---------------------------------------- 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 participant 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 the pictures on a box), identify kitchen items, navigate unfamiliar businesses, or describe what’s physically around them in real time. That same participant 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 MCP-UI, 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 – and this isn’t hypothetical anymore. The mechanism that makes it real has already merged. MCP Apps can now register their own tools, so an app exposes its state and operations as structured, callable functions rather than as pixels in an iframe. The specification names accessibility as an explicit use case – structured state and operations are more accessible than visual rendering – and goes further: because the host has no guaranteed view into a sandboxed app, the tool surface is the only reliable way to introspect it at all. In other words, the most robust interface to an MCP App is already the non-visual one. Accessibility isn’t being retrofitted here; it falls out of the architecture – if we require that tool surface to be complete. And this is bigger than one specification. The same pattern is emerging across the agentic web. WebMCP – a browser standard from Google and Microsoft, now in early preview in Chrome – lets any website declare its capabilities as structured tools an agent can call, instead of forcing the agent to read and click through a visual interface. Two efforts, arriving independently at the same primitive: a declared, language-native surface as the real contract between agents and software. That convergence is the opportunity. If accessibility requirements are written into that surface now – while both standards are still being defined – the agentic web could be born accessible, instead of spending a decade catching up. If they aren’t, we fork: an accessible path and an inaccessible one, the GUI mistake all over again. 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. AGENT-READINESS AND ACCESSIBILITY ARE THE SAME PROBLEM. This reframes what “accessible” even means for an agent-driven interface. The test is no longer only whether a screen reader handles the rendered view correctly – that’s the churning paradigm. The rendered view must still be keyboard- and screen-reader accessible, and that conformance is real work that doesn’t go away. But it’s no longer the only channel. An MCP App now exposes a second, equally first-class surface: a semantic tool layer the agent can query and operate directly, without ever traversing the visual rendering. Accessibility means both channels are complete. A flawlessly conformant interface is still a dead end for an agent-mediated user if the operations aren’t in the tool surface – and a rich tool surface doesn’t excuse an inaccessible view for someone using a screen reader the traditional way. Underneath that is a deeper equivalence.. An agent and a screen-reader user are in the same position: neither can see the interface, and both need the software to declare – in language – what it is and what it can do. Every step that makes a site legible to an agent is a step that makes it legible to someone who can’t see it. Agent-readiness and accessibility are not cousins; they are largely the same engineering problem approached from two directions. Google has said as much outright: its own guidance for building agent-friendly websites points developers to the accessibility tree – the semantic layer assistive technology has always used – and describes it, for an AI agent, as a “high-fidelity map” of the page’s interactive elements that strips away the visual noise of CSS. The same artifact built for blind users is the one the world’s largest browser vendor now tells developers to expose for agents. That’s what makes this moment different from every prior accessibility push. For thirty years, accessibility competed for budget as a compliance line item. Now the entire industry is pouring resources into making software agent-operable – and that work is accessibility work, whether the people doing it know it or not. The only question is whether we’ll be deliberate enough to capture the accessibility that’s already being built. The equivalence isn’t total. An agent tirelessly parses any structured surface you give it, while a human still needs the human-specific part: pace, plain language, cognitive load – things an agent never needs but a person does. Agent-readiness gets you most of the way to accessibility, not all of it. But “most of the way, paid for by someone else” is a position the accessibility community has never once been in. COST REMAINS THE MOST IMMEDIATE BARRIER. Usage-based pricing models, capacity constraints, and subscription tiers risk gating one of the most impactful tools this community has adopted behind an economic wall. During our call, several participants 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: treat accessibility as a design constraint for MCP Apps, not a workstream queued behind the v1 launch. The benchmark is whether an MCP App makes its full functionality available through conversational, intent-driven interaction – every operation a sighted user can perform should be reachable through the tool surface, not locked behind a click only a visual user can make. Screen-reader conformance of the rendered view remains necessary; tool-surface completeness is its equal partner. Build for both. For AI providers: recalibrate safety guardrails so that legitimate accessibility use – reading a label, describing a photo, identifying an object – isn’t caught by guardrails built for a different threat. The failure mode to design against isn’t the model reading a pill bottle; it’s the model refusing to. Treat “this is an accessibility need” as a first-class signal, not an edge case the safety stack never modeled. 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 these standards are being defined right now, by relatively small communities that are 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 part of 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 solutions architect with two decades of experience building large-scale software and infrastructure systems. He has been assisting 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. Liad Yosef is a co-creator of MCP Apps (formerly MCP-UI), a co-author of the MCP Apps specification, and co-leads the MCP Apps working group. He has spent recent years working on solving human-agentic interfaces, previously leading agentic commerce at Shopify. Liad is currently co-founder of Ora – a research lab focused on bringing the human-agentic web to life by making the entire web agent-accessible.