需覆盖主流组合而非单一环境
别名: 兼容性矩阵 · 主流组合 · 测试覆盖
概念解释
只在设计师的 Mac 上开 VoiceOver，测到的是一个环境，不是用户群。兼容性测试要覆盖主流组合：Windows 上的 NVDA 与 JAWS、Safari 上的 VoiceOver、Android 上的 TalkBack，而不是把单一通过当成全面通过。选哪些组合，看的是使用者实际在用什么，不是实验室里哪台机器好开。
机制
单一环境会系统性漏掉映射差异。团队的设备分布通常偏 Mac 或偏 Chrome，用户的阅读器分布偏 Windows。用自己的机器当全集，等于用自己的那对组合去代表别人的运行时。覆盖面的单位是组合，不是「测过阅读器」这个动作——测十遍同一对，覆盖仍是一对。
主流不等于全部。Windows+NVDA、Windows+JAWS、macOS+VoiceOver、iOS+VoiceOver、Android+TalkBack 已经能抓住大多数公开产品的用户；再往外加冷门引擎，边际收益下降。缺的若是占有率最高的那一对，测再多冷门也补不上。矩阵要按用户数据来排优先级，缺数据时至少不要只留团队已经最熟的那一台。
怎么研究
列出目标市场里阅读器与浏览器的使用份额（WebAIM 调查、产品自己的辅助技术反馈），做成最小矩阵，再拿同一套任务脚本在矩阵上跑。记录哪一对从未被测过、哪一对只在某次演示里亮过。
自变量：矩阵里包含的组合、是否含 Windows、是否含移动端。 因变量：首次在第二对组合上发现的缺陷数、只在单一环境通过的任务比例。
WCAG-EM 抽样解决「测哪些页」；矩阵解决「在哪些运行时上测这些页」。两件事要分开记账。
边界
内网工具若合同限定浏览器和阅读器，矩阵可以按合同收窄，并在声明里写清。嵌入式或机顶盒只有一对系统阅读器，谈不上组合覆盖。份额会变：几年前 JAWS 主导的市场现在 NVDA 更大，矩阵要随调查更新，不能刻成实验室墙上的那五台。用虚拟机「有过」某阅读器但从未走完主任务，不算覆盖。
怎么落地
- 写一份最小矩阵：至少一对 Windows 阅读器+浏览器，一对 Apple 阅读器+浏览器；面向移动还要加上 TalkBack 或 iOS VoiceOver。
- 主任务脚本在矩阵每一格都跑，不要只在开发者本机回归。
- 验证：对照矩阵打勾。只有一格有记录，覆盖就是单一环境。缺的那一格用同一脚本补跑，新出现的失败就是单一环境漏掉的部分。