Accessibility Espresso #5
Recommending Podcast '13 Letters': Mike Shebanek tells how he got Apple to ship the screen reader now known as VoiceOver. Bogdan Cerovac on WebMCP: 'not a replacement for accessibility.' Russ Weakley explains the click to screen-reader announcement.
⭐ Topic of the week
Podcast Recommendation with a Story of VoiceOver's Origin
13 Letters is the accessibility podcast from Be My Eyes - the name nods to the number of letters in 'accessibility'. The show interviews industry practitioners on universal design, ADA compliance, inclusivity, and digital a11y best practices,. The two-part 2020 episode 'Who Invented VoiceOver?' with Mike Shebanek is a standout. Part 1 walks through his journey at Apple - product manager on the original iMac and the first-ever iPad - and how he pushed the then-struggling company to ship VoiceOver as a free built-in screen reader for what was considered a niche community of blind students. Part 2 covers Apple from 2004 to 2013 and his later work at Yahoo/Verizon, where he built an accessibility-department model that has been recreated all over Silicon Valley.
📋 The Bigger Picture
The Accessibility D.E.N.N.I.S. System
Jared Cunha maps the D.E.N.N.I.S. System from 'It's Always Sunny in Philadelphia' onto corporate accessibility theatre: Demonstrate Value (bold claims), Engage Physically (sales follow-through that never comes), Nurturing Dependence (SaaS lock-in), Neglect Emotionally (issues unfixed for years), Inspire Hope (pledges without results), Separate Entirely (users dropping products or losing jobs). His case study: the National Design Studio's 'Accessibility Matters' article alongside their portfolio with significant defects. Core argument: there is no fast-tracking the skills this work requires.
Beware of 'AI' Accessibility Audits
Karl Groves dismantles the new wave of 'AI-powered' audit vendors. His technical case: LLMs cannot reach the live DOM, focus movement, computed accessible names, dynamic ARIA changes or shadow-DOM behaviour. What they produce instead is plausibly worded issue descriptions and recommendations identical to the failing code they replace. ChatGPT itself admits: 'They are not doing a deep inspection of anything, much less the code.' Groves calls the six-figure 'MCP server' audit offerings counterfeit expertise. His warning: 'If the evidence is synthetic, then the audit is no longer anchored in reality.'
WebMCP and the Future of the Agentic Web - Do Not Leave Accessibility Behind
Bogdan Cerovac examines WebMCP - the Chrome Labs-backed proposal that would let websites expose predefined tools to AI agents via the Model Context Protocol. His central concern: WebMCP could become an excuse for inaccessible webpages if companies offer accessible AI interfaces while neglecting underlying site accessibility - creating a two-tier web where only AI users get inclusion. He walks through concrete scenarios and lays out four recommendations. Core line: 'WebMCP is not a replacement for accessibility.'
⚙️ In Practice
Testing Mobile Apps - What Differs from Web Testing (Part 1)
Detlev Fischer opens a mobile-accessibility series with the question testers keep stumbling on: why don't web techniques translate cleanly to native apps? Three structural differences shape the rest. First, source-code inspection: native app source is typically unavailable. Second, the user agent's role: the browser handles text resize and reflow on the web; on native apps the OS takes that role. Third, governing standards: when conflicts arise, EN 301 549 Clause 11 (Non-web Software) takes precedence over Clause 9.
Die Realität hinter dem KI-Hype - Ein Barrierefreiheitsscanner zwischen Claude Code und Lovable
Mario Gregor tested an accessibility scanner: Claude Code on the back end, Lovable on the front, auditing websites against WCAG using axe-core. Initial promise: three specialised AI agents produced functional user stories and a backend structure within hours. Time spent: roughly four hours for initial architecture, three-plus weeks debugging. His verdict: 'The two-AI approach isn't viable in its current form for serious product development.'
End-to-End Browser and Accessibility Event Architecture
Russ Weakley maps the full path a user event takes from input to assistive technology output. The article includes a structured layer-by-layer breakdown with caveats on browser implementation variations. A reference for understanding why a focus change announces oddly, or why a live region fires in one browser and not another.