如果你像我一样是一个无障碍的书呆子，或者只是对辅助技术感到好奇，你会喜欢Auto-VO。Auto-VO是一个节点模块和CLI，用于在macOS上使用VoiceOver屏幕阅读器对网页内容进行自动测试。
我创建Auto VO的目的是为了让开发人员、项目管理人员和QA更容易使用真正的辅助技术更快速地进行可重复的自动化测试，而不需要学习如何使用屏幕阅读器的恐吓因素。
让我们开始吧!
首先，让我们看看它的运行情况，然后我将更详细地介绍它的工作原理。下面是在smashingmagazine.com上运行auto-vo CLI，获得所有VoiceOver输出的文本。
$ auto-vo --url https://smashingmagazine.com --limit 200 > output.txt
$ cat output.txt
link Jump to all topics
link Jump to list of all articles
link image Smashing Magazine
list 6 items
link Articles
link Guides 2 of 6
link Books 3 of 6
link Workshops 4 of 6
link Membership 5 of 6
More menu pop up collapsed button 6 of 6
end of list
end of navigation
...(truncated)
看起来是一个合理的页面结构：我们有跳过的导航链接，结构良好的列表，以及语义导航。伟大的工作!不过，让我们再深入挖掘一下。标题的结构如何？
$ cat output.txt | grep heading
heading level 2 link A Complete Guide To Accessibility Tooling
heading level 2 link Spinning Up Multiple WordPress Sites Locally With DevKinsta
heading level 2 link Smashing Podcast Episode 39 With Addy Osmani: Image Optimization
heading level 2 2 items A SMASHING GUIDE TO Accessible Front-End Components
heading level 2 2 items A SMASHING GUIDE TO CSS Generators & Tools
heading level 2 2 items A SMASHING GUIDE TO Front-End Performance 2021
heading level 4 LATEST POSTS
heading level 1 link When CSS Isn’t Enough: JavaScript Requirements For Accessible Components
heading level 1 link Web Design Done Well: Making Use Of Audio
heading level 1 link Useful Front-End Boilerplates And Starter Kits
heading level 1 link Three Front-End Auditing Tools I Discovered Recently
heading level 1 link Meet :has, A Native CSS Parent Selector (And More)
heading level 1 link From AVIF to WebP: A New Smashing Book By Addy Osmani
呒！呒！呒！呒！呒！呒！呒！呒！呒！呒！呒！呒我们的标题层次结构有点不正常。我们应该看到一个纲要，第一层有一个标题，然后是一个有序的层次结构。相反，我们看到的是第一级、第二级和一个错误的第四级的混杂。这一点需要注意，因为它影响了屏幕阅读器用户浏览页面的体验。
将屏幕阅读器的输出作为文本是非常好的，因为这种分析变得更加容易。
一些背景
VoiceOver是MacOS上的屏幕阅读器。屏幕阅读器让人们大声阅读应用程序的内容，也可以与内容互动。这意味着低视力的人或盲人在理论上可以访问内容，包括网络内容。但在实践中，网络上98%的登陆页面都有明显的错误，可以通过自动测试和审查来捕捉。
现在有许多自动化测试和审查工具，包括用于自动化代码审查的AccessLint.com（披露：我建立了AccessLint），以及Axe，一个常用的自动化工具。这些工具很重要也很有用，但它们只是其中的一部分。人工测试同样重要，甚至更重要，但它也更耗时，而且可能令人生畏。
你可能听说过这样的指导："只要打开你的读屏器，听一听"，让你感受到盲人的体验。我认为这是个误导。屏幕阅读器是复杂的应用程序，可能需要几个月或几年的时间才能掌握，而且一开始会让人不知所措。胡乱地使用它来模拟盲人的体验，可能会导致你为盲人感到遗憾，或者更糟的是，试图用错误的方式来 "修复 "这种体验。
我见过有人在启用VoiceOver时惊慌失措，不知道如何将其关闭。Auto-VO为你管理着屏幕阅读器的生命周期。它能自动启动、控制和关闭VoiceOver，所以你不必这样做。你不需要尝试去听和跟上，而是以文本的形式返回输出，然后你可以阅读、评估和捕捉，以便以后作为bug中的参考或用于自动快照。
使用方法
注意事项
目前，由于要求为VoiceOver启用AppleScript，这可能需要对CI构建机进行自定义配置才能运行。
场景1：QA和验收
假设我（开发者）有一个带有蓝线注释的设计--设计者在其中添加了诸如可访问名称和角色的描述。一旦我建立了这个功能并在Chrome或Firefox开发工具中审查了标记，我想把结果输出到一个文本文件中，这样当我把这个功能标记为完成时，我的PM可以把屏幕阅读器的输出与设计规格进行比较。我可以使用auto-vo CLI并将结果输出到一个文件或终端。我们在文章的前面看到过这样的例子。
$ auto-vo --url https://smashingmagazine.com --limit 100
情景2：测试驱动开发
在这里，我再次作为开发者，用蓝线注释的设计来构建我的功能。我想对内容进行测试，这样我就不必在事后重构标记来匹配设计。我可以使用导入到我的首选测试运行器（如Mocha）中的auto-vo节点模块来实现这一目标。
$ npm install --save-dev auto-vo
import { run } from 'auto-vo';
import { expect } from 'chai';
describe('loading example.com', async () => {
it('returns announcements', async () => {
const options = { url: 'https://www.example.com', limit: 10, until: 'Example' };
const announcements = await run(options);
expect(announcements).to.include.members(['Example Domain web content']);
}).timeout(5000);
});
在外壳下
Auto-VO使用shell脚本和AppleScript的组合来驱动VoiceOver。在研究VoiceOver应用程序时，我发现了一个CLI，它支持从命令行启动VoiceOver。
/System/Library/CoreServices/VoiceOver.app/Contents/MacOS/VoiceOverStarter
然后，一系列的JavaScript可执行文件管理AppleScript指令，以导航和捕捉VoiceOver的公告。例如，这个脚本从屏幕阅读器的公告中获取最后一句话。
function run() {
const voiceOver = Application('VoiceOver');
return voiceOver.lastPhrase.content();
}
结束语
我很想听听你使用auto-vo 的经验，并欢迎在GitHub上投稿。试试吧，让我知道它的效果如何
