在最需要它时失灵的无障碍
发出一个 H5 页面，无障碍就是每个团队记起来才加的东西：这里一个 alt，那里一个标签，模态框一开焦点顺序就散。在 WebView 里缺口更大——读屏器报不出有用信息，点按目标缩小，桌面端达标的对比度在小屏上失败。包容变成逐页的抽奖。
小程序运行时翻转了默认。它出厂的组件在构造上就是语义化、可读屏的，带着一致的焦点顺序、标签与角色，随程序走到每个宿主。
运行时级无障碍究竟是什么
运行时提供一套通用的无障碍原语：按钮、列表、表单、媒体，都以相同方式在每台设备上向辅助技术暴露角色、状态与标签。因为运行时掌握渲染表面，它能强制一条最低线——可读对比度、足够的点按目标、合乎逻辑的焦点遍历——而不是指望每个页面主动选择。标准本身写得很明确：WCAG 设定门槛；运行时让达标成为阻力最小的路径。
这不是样式加分项。它是一个人人可用、与每次发布都悄悄排斥一部分用户的程序之间的区别。
差距在哪里显现
| 关切点 | WebView 里的 H5 | 小程序运行时（无障碍原语） |
|---|---|---|
| 读屏标签 | 逐页面零散 | 内建于组件 |
| 焦点顺序 | 模态/SPA 下断裂 | 一致遍历 |
| 点按目标 | 常过小 | 强制最小值 |
| 对比度 | 桌面达标、移动失败 | 在表面处检查 |
| 包容性 | 逐页抽奖 | 跨宿主默认 |
回报是触达面：基于无障碍原语构建的程序，对低视力、运动受限或使用辅助技术的用户始终可用，无需在每个宿主上单独审计。
为什么默认胜过奢望
运行时级的无障碍门槛意味着开发者在已用组件上免费获得包容，而不是等用户投诉后再补标签与焦点。它也意味着同一程序在每个宿主都达同一标准，而不是在发布最弱页面的那个宿主上退步。
Cross Mini App 如何落地
Cross Mini App 为程序提供带无障碍原语的运行时——语义化组件在每個宿主以相同方式向辅助技术暴露角色、状态与标签。你用组件构建；运行时把包容带到每台设备。你不再逐页拿包容下注，而是默认就发布它。
这就是一个因疏忽而排斥用户的程序，与一个为包容而设计的程序之间的区别。
