我们审计过的几乎每个无障碍项目都反映同一个数字：九成以上的前端开发者自称”用屏幕阅读器测试过”。请他们演示，演示过程通常只有同样的三个按键——打开、Tab 浏览页面、关闭。那不是测试，那是在打钩。

这种情况的根源是结构性的，而非懒惰。屏幕阅读器不是一种像新的 linter 那样可以随手拿起的工具。它是一种有着自己模态状态、自己快捷键语法，以及只有在真实使用数小时后才能理解的约定的不同交互模型。在跨越那道门槛之前，这个工具几乎什么也告诉不了你——更糟的是，它会告诉你一些错误的东西，因为你听到的播报取决于阅读器的模式、浏览器的无障碍树，以及平台的输入法层（IME），而这些从外部看并不直观。

就我们的目的而言，“流利”是指：当同事递来一个有问题的组件时，你能接过键盘，在屏幕阅读器运行的情况下复现该 bug——不看屏幕，不查备忘单，也不会让播报比真实使用时更糟。“熟悉”是指你听过屏幕阅读器发出的声音。两者之间的差距大约是三十至三十五小时的刻意练习。

桌面端 Web 有三款重要的屏幕阅读器：Windows 上的 NVDA、macOS 和 iOS 上的 VoiceOver，以及 Windows 上的 JAWS。每款都有足够多的真实用户，忽视任何一款都意味着一次真实的赌注，而且每款对相同标记的播报方式都略有不同。一个流利的开发者至少能驾驭其中两款。

在观察了数十位开发者跨越流利门槛之后，我们的建议明确无误：从 Windows 上的 NVDA 和 macOS 上的 VoiceOver 入手。两款都是免费的。两款都预装（VoiceOver）或可在五分钟内安装完毕（NVDA）。两款的真实用户量都足够大——NVDA 在最新 WebAIM 调查中占据约 65% 的 Windows 屏幕阅读器市场份额，VoiceOver 主导移动端并占据相当一部分 macOS 份额——因此你学到的内容可以立即转化为能发布修复的 bug。JAWS 是第三个工具，而非第一个，尽管它仍是企业安装量最大的屏幕阅读器。原因有三。

将 JAWS 放到后期的三个理由是教学层面的，而非政治层面的。第一，JAWS 和 NVDA 共享同一心智模型——Windows 浏览模式与焦点模式、相同的 Insert 前缀命令、相同的虚拟缓冲区——因此一旦你能驾驭 NVDA，你真正需要的九成 JAWS 命令只是一次词汇表查询的距离。第二，JAWS 积累了数十年的”智能”推断：它会在用户听到之前尝试修复错误的标记，这意味着 JAWS 掩盖的 bug 依然会影响 NVDA 用户。NVDA 刻意保守的行为使其成为学习哪里出了问题时更好的参考阅读器。第三，JAWS 的许可摩擦——激活、每次重启都会弹出的四十分钟试用模式——是你在足够自信之前不需要承担的学习成本。

VoiceOver 与 NVDA 配对而非竞争，是因为两款阅读器代表了两种主流交互模型。NVDA（和 JAWS）使用”PC 光标”模型：一个将页面布局为线性文档的虚拟缓冲区，以及一个跟随 Tab 顺序的独立焦点。VoiceOver 使用单一的 VoiceOver 光标，叠加在焦点之上，通过转盘和 VO+方向键进行导航。只熟悉一种模型的开发者写出的代码会在自己的阅读器里播报良好，在另一款里播报糟糕。同时学习两种模型，是感受两者差异的唯一可靠方式。

第一周的计划有一条规则：关闭显示器。不是调暗，不是最小化，不是”我会闭上眼睛”——而是物理关闭，或者如果房间里只有这一台显示器，用一张卡纸遮住它。目的是消除作弊的可能。视力正常的开发者的本能，在屏幕阅读器说出令人困惑的话时，是瞥一眼屏幕用视觉消除歧义。正是这种本能，是”我用屏幕阅读器测试过”无法发现真实 bug 的最大原因。

第一周计划安排三次约九十分钟的练习，每次之间至少间隔一天，让肌肉记忆有时间巩固。每次练习各有一个任务。第一次建立基本命令语法。第二次强制进行真实交互。第三次在轻微压力下测试记忆保留情况。

第二至第四周的练习总量应达到约二十小时——每周两次九十分钟练习，加上日常工作中少量的随机使用。这段时间的目标是将最容易让屏幕阅读器新用户困惑的两件事内化：浏览模式与焦点模式的区别，以及转盘所见与 Tab 顺序所见之间的差异。

第二周最常见的困惑，是开发者按方向键，期望虚拟缓冲区移动，却听到已聚焦的下拉框打开了选项列表。这是浏览模式自动切换到焦点模式，因为焦点落在了 NVDA 归类为”应用程序”组件的元素上。新开发者会觉得阅读器出问题了。并非如此——阅读器正在严格按照规范执行。听过十到十五次之后你就不会再惊讶；在那之前，大约每隔一次练习就会让你惊讶一次。

第三周的模式是表单。搭建一个私有测试页面，包含八至十个控件：一个带内联错误的必填文本输入框、一个日期选择器、一个多选框、一个自定义样式的复选框、一个从禁用变为启用的按钮、一个”显示密码”切换、一个带国家代码选择器的电话号码字段，以及一个触发服务端验证摘要的提交按钮。关闭显示器，分五次浏览——先用 NVDA 浏览模式，再用 NVDA 焦点模式，再用开启了详细播报（Insert+Z）的 NVDA，然后用带转盘的 VoiceOver，最后用不带转盘的 VoiceOver。同一个表单会产生五种截然不同的声音。这就是流利从内部感受起来的样子：注意到同样的标记讲述了五个不同的故事，并能提前预测哪一个会被播出。

第四周是导航。找一个真实的复杂网站——一个文档门户、一个工作仪表盘、一个电商分类页面——并尝试只用屏幕阅读器快捷键找到特定信息。用 H 跳转标题，用 D（NVDA）或 VO+U 再选”Landmarks”（VoiceOver）跳转地标，用 1 至 6 跳转到特定级别的标题。到第四周结束时，导航快捷键应该成为反射而非选择，就像 Tab 和 Shift+Tab 早已如此一样。

一旦用户模式命令成为反射，下一个跃升是进入每款阅读器面向开发者的界面。这些模式和快捷键被手册埋在深处——部分原因是它们面向开发者，部分原因是它们产生的噪音让日常用户不会想打开它们。以下三个值得立即了解。

还有两个习惯比任何单个快捷键节省的时间都更多。第一，在开发时将 NVDA 语音查看器固定在第二台显示器上（或一台显示器的角落）。每条播报的逐字日志对屏幕阅读器工作的意义，相当于开发工具控制台对 JavaScript 的意义：是猜测与确知之间的差距。第二，学会在浏览器开发工具中阅读无障碍树——Chrome 的 Accessibility 面板、Firefox 的无障碍检查器、Safari 的 Audit 标签。阅读器播报的是无障碍树包含的内容，而非 DOM 包含的内容，两者的差异足够频繁，使得在不直接阅读无障碍树的情况下，你无法调试实时区域（live region）、ARIA 或 Shadow DOM。

现在要指出一个在第二、三周会耗费大量时间的混淆：阅读模式与焦点模式，并不是”页面是交互式的”与”页面是文档”这个轴线。当焦点落在带有 role=“application” 的控件上，或落在 contenteditable 上，或落在阅读器启发式归类为交互式的某些自定义组件上时，NVDA 会自动切换为焦点模式——无论页面本身是否主要是静态的。相反，一个大量交互的单页应用，若其根元素是 main 地标且组件是标记规范的原生按钮，在用户的整个会话中几乎都会保持浏览模式。模式是已聚焦元素的属性，而非页面的属性。

以下数据来自三年企业工作坊和一对一辅导中约八十位开发者——前端工程师、QA 负责人、在培无障碍专员——的非正式追踪记录。这不是研究报告，但足以用于计划。两个前提：刻意练习（关闭显示器，真实任务，而非”我在编码时让 NVDA 在后台运行”），以及固定的阅读器配对（Windows 上的 NVDA 与 macOS 上的 VoiceOver）。

”半流利”是大多数视力正常开发者的现实目标，就实际而言，这也是成为无障碍产品良好贡献者所需的全部。真正的流利——达到可以在可用性评审中合理替代日常屏幕阅读器用户的水平——大约需要一百五十小时和一年的随机练习，大多数在职开发者并不需要这个层次。以半流利为目标，规划好四十小时，并接受超出这个范围的部分，来自于在运行阅读器的情况下做日常工作，以及放慢脚步的意愿。

最后一个诚实设定预期的基准：根据我们的经验，陷入瓶颈的开发者，几乎都在十至二十小时区间遭遇瓶颈。原因几乎总是相同的——他们不再关闭显示器了。他们告诉自己，现在已经”足够好”，可以在开着显示器、运行着屏幕阅读器的情况下测试，并在音频模糊时通过视觉确认。他们并没有足够好。从”有用”到”舒适”之间的十六小时需要关闭显示器，因为那是阅读器的播报从噪音变为信息的过程。没有这种压力，大脑就会退回到视觉，而阅读器的声音就会淡化为背景音。如果你发现自己在放缓，几乎可以确定问题出在显示器上。

”用屏幕阅读器测试”在行业内产生如此微弱结果的原因，不是工具难以学习——四十小时真的不算多——而是学习过程在特定方式上令人不舒服。关闭显示器会让视力正常的开发者感到一种在我们职业中罕见的无能感。我们习惯于成为能搞清楚一切的人；屏幕阅读器让我们——在短短数小时内——再次成为初学者。这种不适，而非按键本身，才是真正的障碍。

穿越这种不适的路径就是上文描述的那条：NVDA 和 VoiceOver，第一周三次关闭显示器的练习，第二至四周攻克表单和模式，用户模式快捷键成为反射后立即学习开发者模式快捷键，总计四十小时后才能承担一次认真的发布前扫描。这些都不新鲜。行业尚未做到的工作，是将其视为工作——规划这些小时，抵御其他事项的占用，接受前十小时感觉毫无用处，直到它们突然有用起来。

如果你在做前端工作，走过那四十小时之后的你，是一位在无障碍工作方式上远比起步时更优秀的工程师，这种优势不仅体现在无障碍工作中，也体现在你对焦点顺序、渐进增强，以及浏览器在底层实际做了什么的理解上。屏幕阅读器是所有 Web 开发者能获得的最廉价的分布式系统课程。代价是关闭显示器，加上几个周末。