screen-reader-testing

screen-reader-testing 技能概览

screen-reader-testing 技能的作用

screen-reader-testing 是一份偏实战的测试指南，用来检查 Web 应用在真实屏幕阅读器中的实际表现，而不只是依赖自动化无障碍扫描工具。它适用于 UX 审核、无障碍 QA、ARIA 验证、表单测试，以及那些“视觉上看起来没问题、但辅助技术用户用起来会出错”的排查场景。

谁适合安装

这个 screen-reader-testing 技能尤其适合：

• 需要可重复人工无障碍测试流程的 UX 审核人员
• 正在排查键盘操作和播报问题的前端工程师
• 希望在发布前验证交互模式的设计师
• 想把辅助技术检查纳入验收测试的 QA 团队
• 正在准备 WCAG 相关评审、且明白自动化检查不够用的团队

它真正解决的工作问题

大多数用户并不需要一份泛泛而谈的无障碍科普。他们真正需要的是一套方法，来回答这些问题：

• 应该优先测试哪些屏幕阅读器和浏览器组合？
• 如何更贴近真实使用情境地测试表单、对话框、菜单和动态更新？
• 在导航过程中，应该重点听哪些内容？
• 怎么把一句模糊的“检查一下无障碍”变成有范围、有重点的 UX 审核？

screen-reader-testing 技能的价值就在于把这类人工测试工作组织起来。

为什么它比通用提示词更有用

通用提示词往往只能列出一些无障碍最佳实践。而这个技能更适合需要“可执行”的 screen-reader-testing 指南的场景，因为它提供了：

• 明确的平台覆盖优先级
• 对 VoiceOver、NVDA、JAWS、TalkBack、Narrator 等主流屏幕阅读器的区分
• 将测试重点拆分为阅读模式与交互模式
• 面向真实问题的测试场景，例如表单、ARIA 行为、动态播报和导航

采用前最需要看清的一点

它的核心价值在于辅助决策和梳理测试流程，而不是自动化本身。这个技能不能替代你在目标平台上实际运行屏幕阅读器。若你希望获得更清晰的测试规划、更高质量的 agent 提示词，以及在屏幕阅读器兼容性评审中减少盲区，那么它值得安装。

如何使用 screen-reader-testing 技能

screen-reader-testing 的安装上下文

从 wshobson/agents 仓库将该技能安装到支持 skills 的环境中：

npx skills add https://github.com/wshobson/agents --skill screen-reader-testing

如果你的 agent 环境使用的是别的 skill loader，就按对应工具调整安装步骤。关键点是从仓库中的 plugins/accessibility-compliance/skills/screen-reader-testing 路径拉取 screen-reader-testing 技能。

先看这个文件

先从这里开始：

• SKILL.md

这个仓库切片目前只暴露了 SKILL.md，因此是否采用，主要取决于其中的测试框架是否符合你的工作流。这里没有附带 helper scripts 或参考文件，所以你需要自行提供应用上下文、目标流程和平台限制。

想让技能发挥效果，需要提供哪些输入

如果你提供以下信息，screen-reader-testing 技能的表现会明显更好：

• 产品类型：marketing site、SaaS app、dashboard、checkout、form-heavy workflow
• 目标用户流程：sign in、search、checkout、create record、submit form
• 目标平台：Windows、macOS、iOS、Android
• 浏览器限制：Safari、Firefox、Chrome、Edge
• 涉及的组件类型：modal、tabs、menu button、combobox、live region、data table
• 已知问题或怀疑点：missing labels、broken tab order、duplicate announcements、silent updates

较弱的输入：

• “Test my site for screen readers.”

更强的输入：

• “Use the screen-reader-testing skill to review our signup flow for NVDA + Firefox and VoiceOver + Safari. Focus on field labels, error announcements, password requirements, focus movement after validation, and whether success feedback is announced.”

优先选择平台覆盖，而不是一开始全测

这个技能给出了一套很实用的优先级模型。实际操作里，建议先从下面几组开始：

1. NVDA + Firefox on Windows
2. VoiceOver + Safari on macOS
3. VoiceOver + Safari on iOS

只有当产品风险、用户群体或合规要求确实需要更广覆盖时，再扩展到 JAWS + Chrome、TalkBack + Chrome 和 Narrator + Edge。这样更省时间，也能让 UX 审核保持现实可执行。

把模糊目标改写成更好的提示词

一个好的 screen-reader-testing usage 提示词，应该明确写出：

• 流程
• 辅助技术组合
• 交互类型
• 期望的输出格式

例如：

“Use the screen-reader-testing skill for a UX audit of our checkout flow. Prioritize NVDA + Firefox and VoiceOver + Safari. Test browse reading, form entry, validation errors, shipping method radio groups, promo code updates, and payment confirmation announcements. Return findings by severity, reproduction steps, expected screen reader behavior, and likely markup causes.”

这个提示词更好，是因为它把范围、覆盖面和报告结构都说清楚了。

把技能用在对的问题上

这个 screen-reader-testing 指南尤其适合以下场景：

• ARIA 实现验证
• 表单标签与错误提示行为检查
• 动态内容播报检查
• 焦点管理评审
• 导航与 landmark 可用性检查
• 验证自定义组件是否像原生控件一样可用

但如果你把它当作独立工具来处理 color contrast、视觉布局评审，或完整的法律/规范合规映射，它就没那么合适了，除非你同时结合其他无障碍检查方法。

用于 UX 审核的 screen-reader-testing 实操流程

一套更稳妥的工作流通常是：

1. 先识别最重要的用户旅程。
2. 选定最小必要的屏幕阅读器覆盖范围。
3. 先测阅读顺序和页面结构。
4. 再测交互控件。
5. 触发所有校验和动态更新状态。
6. 记录哪些内容被播报、被跳过、重复出现或让人困惑。
7. 把观察结果转成面向代码整改的说明。

这个顺序很重要，因为很多团队会一上来就钻进组件细节，却没有先检查 heading、landmark、page title 和整体阅读流。

测试时应该重点听什么

如果你在测试中主动捕捉这些内容，这个技能会更有效：

• headings 是否形成有意义的大纲
• landmarks 是否帮助用户建立方位感
• links 和 buttons 是否有清晰且彼此可区分的名称
• 表单字段是否暴露了 labels、instructions 和 errors
• 状态变化是否被播报出来
• 打开对话框、提交表单或切换视图后，焦点是否落在用户预期的位置

和简单的通过/失败清单相比，这类观察更容易产出可执行的问题结论。

测试组件前，先理解屏幕阅读器模式

源材料特别区分了阅读模式和交互模式。这一点很关键，因为很多组件在“读内容”时看上去没问题，但一到真实操作就出错。让 agent 同时测试这两种情况：

• 在 browse 或 virtual mode 下发现内容
• 在 focus 或 forms mode 下直接交互

这对 menus、comboboxes、modal dialogs、date pickers 和自定义 dropdowns 尤其重要。

怎样把输出更好地交给工程师处理

建议要求输出采用工程团队可直接消费的格式：

• 问题摘要
• 受影响的屏幕阅读器和浏览器
• 精确复现路径
• 实际播报或实际行为
• 期望行为
• 可能的技术原因，例如 missing name、wrong role、broken focus management 或 absent live region

这样一来，screen-reader-testing skill 就不只是泛泛的指导，而会变成真正能辅助排障的工具。

screen-reader-testing 技能常见问题

screen-reader-testing 足够完成无障碍测试吗？

不够。screen-reader-testing 技能覆盖的是一层很重要的人工测试，但它应该与 keyboard testing、semantic HTML review、automated checks 和设计层面的无障碍评审一起使用。当你特别关注辅助技术用户体验时，它很有价值。

这个技能对新手友好吗？

友好，但有边界。它能提供有用的测试优先级和核心概念，但前提是你能在相关平台上接触或模拟真实测试。新手可以用它来搭建评审框架，但如果想高效操作 NVDA、VoiceOver 或 JAWS，通常还需要额外的上手指导。

什么情况下 screen-reader-testing 不太适合？

如果你的需求主要是下面这些，就不建议把它作为首选：

• automated linting
• code scanning
• 非 Web 产品的无障碍
• 纯视觉 UX 评审
• 完整的 WCAG conformance matrix

在这些场景里，screen-reader-testing 可以辅助流程，但不应该是唯一方法。

它和普通的 accessibility 提示词有什么区别？

普通提示词通常只会产出宽泛建议。只有当你需要一套可复用的测试框架，并且重点围绕真实屏幕阅读器行为、覆盖优先级和实际审核流程时，screen-reader-testing install 才真正值得考虑。它能减少“先测什么、哪些组合最重要”这类判断上的猜测。

可以把 screen-reader-testing 用于设计评审吗？

可以，但更多是间接使用。它最适合已经实现的界面，或者足够真实的原型，因为这时才能评估导航顺序、标签、播报和状态变化。对于偏早期的设计评审，可以用它来提前检验交互模式是否站得住脚，再进入开发。

如何改进 screen-reader-testing 技能的使用效果

缩小 screen-reader-testing 的范围，结果会更好

提升 screen-reader-testing 输出质量最快的方法，就是减少模糊性。一次只让它审一个流程、一组平台和一类问题。“Audit our app” 范围太大；而“Test our account recovery flow for VoiceOver + Safari focusing on heading structure, field instructions, error messaging, and confirmation announcements” 就强得多。

不只描述当前 UI，也要给出期望行为

如果你明确告诉 agent“用户本应能做到什么”，结论会更锐利。可以加入这类预期：

• 打开 modal 后，focus 应进入对话框内部
• submit 之后，error summary 应被播报
• loading 完成后，应能感知到完成状态，而不需要强制重新导航

这能帮助 screen-reader-testing 指南分辨哪些是实现缺陷，哪些只是无害的差异。

提供组件清单和自定义控件细节

自定义 UI 控件往往是屏幕阅读器问题最集中的地方。如果你的页面使用了：

• custom select menus
• tab systems
• expandable sections
• drag-and-drop alternatives
• live-updating dashboards

请明确写出来。这样技能就能把重点放在高风险模式上，而不是把时间花在低风险的静态内容上。

主动要求覆盖失败路径和边界状态

不要只测 happy path。为了让 screen-reader-testing usage 更有价值，应该要求它检查：

• empty results
• invalid input
• session timeout warnings
• disabled controls
• async updates
• 单页应用中的 route changes

这些状态经常会暴露出标准演示流程里看不到的“静默失败”。

拿到第一轮结果后继续追问

首轮输出之后，可以继续问这类问题：

• “Which findings are most likely caused by incorrect accessible names?”
• “Which issues are specific to VoiceOver versus cross-screen-reader?”
• “What should we retest after fixing focus management?”
• “Which findings block task completion versus just causing confusion?”

这样可以把一次性审计，变成有优先级的持续整改流程。

把 screen-reader-testing 与证据记录配合起来

对团队协作来说，最有效的提升方式之一是把这些信息记录下来：

• 精确页面 URL 或构建版本
• 屏幕阅读器和浏览器版本
• 导航路径
• 使用的按键或手势
• 实际听到的播报文本

即便这个技能本身是纯文本的，只要你要求按这种结构输出，结果也会更容易核验和移交。

依赖它之前，先了解最大的限制

最大的约束是，screen-reader-testing 技能“重指导、轻仓库内容”。这个技能目录里没有附带 scripts、参考资料或自动化 helper。它的价值有多大，很大程度上取决于你提供上下文的质量，以及你执行人工测试计划时是否足够严谨。

把你的提示词从泛泛请求升级为可审计输入

一个高质量的最终提示词，通常会包含：

• 产品和流程
• 目标 screen reader/browser 组合
• 优先组件
• 要测试的状态
• 输出格式
• 严重级别模型

例如：

“Use the screen-reader-testing skill to perform a UX audit of our billing settings flow. Prioritize NVDA + Firefox and VoiceOver + Safari. Test heading navigation, landmark clarity, form labels, inline validation, success and error announcements, dialog focus trapping, and dynamic plan-price updates. Return a table with issue, severity, affected AT/browser, reproduction steps, observed behavior, expected behavior, and likely code-level cause.”

只有达到这种具体程度，这个技能才会比一个泛泛的 accessibility 请求明显更有实际价值。