把它叫「WebView」掩盖了它辜负的是谁。依赖辅助技术的人——VoiceOver、TalkBack、开关控制、大字体、高对比度——恰恰是 WebView 屏悄悄落下的人。页面渲染出来了，明眼用户能点按钮；但盲人用户赖以导航的那棵无障碍树是不完整的，而这份失败，对所有不用读屏器的人来说都不可见。

同一份标记，不同的结果

移动端 Safari 里的网页，和 WKWebView 里同一份网页，共享同一个 DOM、同一套 WebKit——但播报却不一样。无障碍工程师在 2026 年的记录里说得很直白：iOS 的 WKWebView 不会像 Safari 那样尊重 aria-live 的紧急级别——在 Safari 标签页里会打断当前朗读的 assertive 区域，进了 WKWebView 会被降级成延迟的 polite 消息。用户听到「连接断开——正在重试」时，已经把字打进了那块坏掉的表单里。唯一可靠的跨平台修法是把播报从 DOM 里抽出来、经 JavaScript 桥送到宿主 App，再由 iOS 的 UIAccessibility.post 或 Android 的 announceForAccessibility() 回送。WebView 里的读屏用户，没法相信页面会好好对他说话。

页面无视的那些设置

宿主原生 App 花了很多年去尊重系统的无障碍设置——Dynamic Type 字体放大、粗体、增强对比度、减弱动态效果、深色模式。WebView 内的网页内容，默认一个都不继承。prefers-color-scheme 只有网页自己监听才生效；宿主 App 的深色主题和 WebView 的浅色页面并排出现。操作系统对原生标签做的字体放大，到不了网页文字上。当宿主在 WebView 之上叠了自己的工具栏或悬浮按钮，朗读顺序在不同 iOS 版本上变得不确定。一份混合开发的指南说得很直白：就算 alt 写得再全，用户也可能点不到按钮、听不到状态变化、甚至滚不动页面。

焦点从裂缝里漏掉

读屏焦点管理在原生边界处断裂。在 WebView 内，document.activeElement 常常返回 body 或 null——尤其在键盘弹出之后——于是焦点追踪代码乱套。手动用 element.focus() 移焦点，可能触发 iOS WKWebView 的强制滚动，把输入框顶到键盘后面藏起来。结果就是一张盲人用户填不完的表单，出现在一个视觉 QA 早已通过、却从未用 VoiceOver 测过的屏幕上。

不只是一个体验缺口，还是法律缺口

这过去只是声誉风险，现在是合规风险。欧盟无障碍法案（Directive (EU) 2019/882）自 2025 年 6 月 28 日起已在全部 27 个成员国可执行，并与 EN 301 549 对齐——后者把 WCAG 2.1 AA 级作为移动 App 的基线。它覆盖电商、银行、交通、票务类 App，监管方能把不合规的 App 从分发渠道下架。2026 年 6 月，法国卡昂法院判令家乐福在六个月内让网站和移动 App 都达到无障碍，否则每天罚 500 欧元——这是首个明确覆盖 App 的 EAA 转化法判决。美国这边，Domino's 诉 Robles 一系列判例早已确立 App 在 ADA 下必须可访问。对一个目录里是数百个商家页、而每个商家页都是别人 HTML 的流量 App 来说，这些页面全都在监管范围内。

runtime 的解法

宿主自有 runtime 不会把商家的 HTML 丢上去、然后指望平台无障碍服务自己搞定。它桥接那棵无障碍树：它暴露一条受许的桥，让紧急播报在每种引擎上都能可靠抵达操作系统辅助栈；它把宿主 App 的字体放大与深色模式设置映射进网页上下文，让页面真正尊重它们；它在原生/WebView 边界上强制一个单一、确定的焦点与朗读顺序。无障碍变成 runtime 担保的属性，用真实的 VoiceOver 和 TalkBack 实测来验证，而不是每个商家页各凭运气。

维度WebView宿主自有 runtime
实时区域播报WKWebView 把紧急降级为礼貌经桥可靠送达操作系统辅助栈
系统设置字体放大 / 深色模式 / 对比度全无视映射进网页上下文
焦点与朗读顺序在原生边界丢失、不确定强制单一确定顺序
合规各页面自理，暴露 EAA/ADA 风险按程序审计、实测
谁测它视觉 QA 通过，读屏未测VoiceOver + TalkBack 进 CI

本系列的贯穿主线是控制权。WebView 让商家的页面上了你的 App，却把它的无障碍——如今还有法律合规——交给运气。runtime 让你自己掌握它。对于一个目录里全是别人页面的平台，这份掌握，就是包容的 App 与一纸诉讼之间的那条线。

参考来源