作为在有无障碍意识的团队中工作的有无障碍意识的开发人员，我们努力设计和建立包容性的应用程序，为所有用户带来愉快的体验。然而，尽管我们做出了最大的努力，我们可能会犯错误，以次优的方式实现功能，或者更糟的是，发现一些用户根本无法使用这些功能。幸运的是，近年来，浏览器已经推出了一些工具，帮助调试其中的一些问题。在这里，我们将重点讨论内置的可访问性检查器，它允许开发人员浏览浏览器呈现给辅助技术的可访问性树。
可访问性树
由于辅助技术（AT）被期望在多个桌面应用程序中提供统一的体验，它不直接与浏览器互动，而是通过位于AT和浏览器之间的可及性API进行互动。因此，当浏览器读取一个页面的HTML时，它不仅会生成DOM树，而且如果AT正在运行，浏览器也会生成一个可访问性树，代表DOM结构的计算可访问性属性。然后，AT读取（也许是转换）这个可及性树来生成他们自己的用户体验。
虽然大部分的DOM结构会以某种形式存在于可及性树中，但浏览器可以通过移除隐藏的元素或那些它认为对用户没有任何意义的元素（例如，纯演示的包装节点）来优化可及性树。此外，可访问性树的确切结构是具体实施的；例如，浏览器可能对相同的节点使用不同的节点名称，用其他浏览器不使用的属性来装饰节点，或试图纠正结构不良的标记。然而，为了与底层的可访问性API兼容，有一些共性是必须的，包括一个元素的。
- 角色，这有助于告知用户如何与该元素进行交互。例如，如果一个元素的角色被列为 "复选框 "或 "复选按钮"（取决于浏览器），用户就知道该元素可以接受焦点并被选择或取消选择。
- 可选的名称或标签，这有助于定义该元素的目的。例如，如果该元素是一个按钮，其文本内容将被用作其名称。或者，如果它包含一个aria-label属性，它的名字将是该属性的值；如果它包含一个aria-labelledby属性，那么它的名字将是具有aria-labelledby指定的ID的元素的计算名称。
- 各种状态，如元素是否可被聚焦、禁用、选中等。
可访问性检查器
现在我们对浏览器如何向辅助技术表示文档结构有了更好的理解，我们可以讨论浏览器为开发者提供的工具，以与这些结构进行交互，并确定任何给定DOM节点的计算可访问性属性。目前，无障碍检查器以某种形式由以下机构提供。
- 火狐
- Chrome、Chromium Edge和Brave
- 浏览器
在下面的章节中，我们将使用下面的HTML示例面包屑的实现，依次考察每个可用性检查器。请注意，没有应用任何样式，而且列表中的HTML是故意弄错的，以便展示它如何影响每个浏览器中的可访问性树。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Accessibility Inspector Demo</title>
</head>
<body>
<nav aria-label="breadcrumb">
<ol>
<div>
<li><a href="/step-one">Step One</a></li>
<li><a aria-current="step" href="/step-two">Step Two</a></li>
<li><a href="/step-three">Step Three</a></li>
</div>
</ol>
</nav>
</body>
</html>
火狐浏览器
在所列的浏览器平台中，只有Firefox允许开发者像浏览DOM树一样浏览整个可访问性树。火狐的检查器可以在其开发者工具的 "可及性 "标签中找到。这个选项卡应该被显示出来，但如果没有，则需要手动启用。要做到这一点，请打开 "自定义开发工具和获取帮助 "菜单（显示为主开发工具工具栏中 "关闭 "按钮旁边的省略号按钮），然后导航到 "设置"。可以通过勾选 "默认开发工具 "部分的 "可访问性 "复选框来启用可访问性标签。
为了优化性能，除非需要，否则浏览器不会生成可访问性树。因此，一旦 "可及性 "选项卡被启用并显示，就需要通过 "开启可及性功能 "按钮来启用可及性功能，除非已经在运行一项辅助技术。启用无障碍功能后，无障碍树显示在标签内容中，任何节点的无障碍属性都可以通过以下方式显示：1）单独展开树中的节点；2）使用 "从页面中挑选无障碍对象 "按钮（"无障碍 "标签被选中时，工具栏中的第一个按钮）；3）右键单击页面上的任何元素，从右键菜单中选择 "检查无障碍属性"。
回到上面的面包屑例子，Firefox生成了以下的可访问性树。
即使是我们这个小例子，也有很多东西可以探索。主标签内容区显示每个节点的角色和名称，但也有一个 "属性 "手风琴窗格，包含额外的信息，如节点的各种状态（例如，"可聚焦 "和 "启用"）。为了理解这如何帮助我们改善用户体验，注意到面包屑列表的结构出现了错误。具体来说，在list 节点之后，我们希望面包屑中的三个项目都有listitem 节点。相反，这里有一个单一的部分，后面是三个文本容器节点。这是由于包裹三个<li> 标签的<div> ，由此产生的无障碍树结构表明，辅助技术可能不会以我们期望的方式向用户展示这一点。事实上，macOS上的VoiceOver并没有把这个例子当作三个项目的列表，而是当作一个项目的列表，因此，在列表中导航的结果是如下的阅读。
list one item
link, Step One
link, Step Two
link, Step Three
为了纠正这一点，我们需要删除三个列表项周围的<div> ，以恢复列表和其单个项目之间的预期关系。
在移除<div> ，无障碍树显示面包屑项目为预期的listitem 节点，VoiceOver现在显示我们的列表有三个项目，并读取每个步骤的编号。
list three items
text, 1 of 3
link, Step One
text, 2 of 3
link, Step Two
text, 3 of 3
link, Step Third
Chrome和Chromium浏览器
Chrome浏览器的开发工具没有提供一个单独的、顶层的标签来查看可访问性树，而是在顶层的 "元素 "标签上增加了一个子 "可访问性 "标签。虽然不能自由浏览整个可及性树，但Chrome的工具仍然提供了大量有用的信息。
在上图中，包裹着面包屑的列表项的<div> ，它的可及性属性被选中并得到显示。在火狐浏览器中，这个节点被包含在可访问性树中，降低了用户体验。然而，在Chrome浏览器中，这个相同节点的 "计算属性 "报告说："可访问性节点没有暴露。元素对可访问性不感兴趣"。如果我们再突出面包屑中的一个链接，我们可以在 "可及性树 "的手风琴窗格中看到，列表和列表项之间的关系被保留下来。Chrome认识到，<div> ，不应该在列表项周围添加，因此忽略了它。
当然，在我们自己测试之前，我们不能确定AT会向用户读出什么。在启用VoiceOver的情况下浏览我们的页面，可以验证我们对计算出的可访问性的解释是正确的。
list 3 items
1
link, Step One
2
link, Step Two
3
link, Step Third
请注意，这个简单的例子是特意选择的，以展示浏览器在生成可访问性树时如何修改DOM树。由于不能保证这种行为在未来的版本中会被保留，也不能保证所有写得不好的标记都会被优化，我们仍然必须修正我们的代码。在这样做之后，VoiceOver验证了所有的东西都是按照预期来阅读的。
列出3个项目
1
链接，第一步
2
链接，第二步
3
链接，第三步
浏览器
与Chrome一样，Safari在顶层的 "元素 "选项卡中包含了节点的可访问性属性。然而，与Firefox或Chrome提供的信息相比，可用的信息是最少的。要查看一个节点的可访问性属性，请在开发者工具的 "元素 "标签中检查该节点，在相邻的子窗格中选择 "节点 "子标签，然后展开 "可访问性 "手风琴窗格。
Safari的检查器只报告了每个节点的少量属性：它的角色、名称（它称之为 "标签"）、父、子、ARIA属性和基本状态，如节点是否被禁用或被聚焦。正如前面的图片所示，包裹着列表项的
aria-current 属性）。
list 3 items
1
link, Step One
2
current step, link, Step Two
3
link, Step Three
结论
虽然无法替代使用NVDA或VoiceOver等辅助技术对我们的应用程序进行测试，但开发人员可用的工具套件越来越多，这提高了我们的网站和应用程序包容所有用户的可能性。目前，火狐是唯一一个可以浏览和查看整个可及性树的浏览器，尽管其他浏览器至少提供了一些有用的信息来调试使用辅助技术测试时遇到的问题。
你是否需要帮助改善你的应用程序的可及性？请联系我们，讨论我们如何帮助你改进你的应用程序，为所有用户提供优秀的体验。
