有时会要求我对现有页面进行审核，以便我们可以对其进行补救。其他时候，我会要求审核一项功能，以在发布之前检查可访问性问题。最常见的是，我要求提供可访问性代码审查反馈，作为拉的请求过程的一部分。
无论情况如何，我执行可访问性审核的方式大致相同。我认为在这里概述我的过程会很有帮助，以便其他对可访问性世界的新手有一些模板可以遵循。
审计的主要领域
我通常通过一系列通过页面或功能进行审核：
-
使用仅键盘导航的手动测试
-
使用屏幕读取器导航的手动测试
-
使用AX DevTools浏览器扩展程序和其他可访问性工具
自动测试
让我们检查这些阶段的每个阶段。
仅键盘导航
第一次通过页面或功能，我尝试操作控件并仅使用键盘导航。
这有助于我检查是否可以通过键盘达到所有交互式内容，并且页面上的标签顺序是有道理的。有时，我会发现开发人员创建了一个可以轻松与鼠标一起使用的接口，但可以与键盘一起使用。或者，它可能主要是可以访问键盘的，但是有些作品无法通过键盘进行修复。
在此阶段，我还检查各种控件是否响应适当的按键。例如，按钮应响应Enter和Space键。应使用Enter密钥激活链接。菜单项应使用上下箭头键可导航。
在使用键盘导航时，我检查聚焦项目是否具有可见的焦点指示器，并具有适当的颜色对比度。有时，设计人员或开发人员会故意隐藏焦点轮廓，因为他们不喜欢它的外观，但这对仅限键盘用户来说是不友善的，因为它在尝试识别当前活动的项目是什么时会造成混乱。无论您还是要设置焦点指标，但请确保它们的存在并可以很容易地看到。
当我使用该应用程序时，我还确保将焦点与模式或下拉菜单（下拉菜单）互动时将焦点发送到正确的位置。例如，模态应在模态打开时在模态内发送的焦点，应在模态打开时被困在模态内，并且在模态关闭时应将焦点发送回触发按钮。同样，在下拉菜单中与菜单项进行交互时，如果用户按下逃生键，则应关闭菜单，重点应返回下拉菜单触发按钮。
最后，仅使用键盘时，我检查了任何无意的焦点陷阱。我们不希望用户能够导航到他们无法导航的区域。
屏幕阅读器导航
接下来，我使用屏幕读取器进行第二次通过或功能。我主要使用Mac，因此我选择的屏幕阅读器是Voiceover，是iOS设备的内置屏幕读取器。
当我使用屏幕读取器时，我检查以确保页面上的信息清楚地传达给用户。例如，非注册图像应具有描述图像的Alt文本。否则，屏幕读取器可以简单地读取图像或文件名，它们通常都是无用的。同样，只有图标按钮，就像删除按钮一样仅显示垃圾桶可以图标，而没有任何文本，都需要具有aria-label属性，以便屏幕读取器用户知道该按钮的内容。
。我还检查是否将正确的ARIA角色传达给屏幕读取器。例如，有时开发人员在真正使用按钮元素时会使用链接元素。在这种情况下，href属性被覆盖，并提供了一个onclick处理程序，以便在按下按钮时，采取了操作，但不会发生导航。对于视力鼠标用户而言，这很好且花花公子，但是当屏幕读取器用户遇到元素时，它将被读取为“链接”，而不是button，这对用户误导了。
在审核的这一部分期间，这里的关键在于，所有内容都需要清晰，正确地传达其是和做什么。这通常是使用语义HTML元素以及偶尔的ARIA属性来实现的。
如果使用屏幕读取器时有什么令人困惑或误导，那可能是一个可用性问题。
自动测试工具
正如您可能已经指出的那样，我审核的前两个阶段是非常手动的。使用自动测试工具很不错，但现实是这些自动化测试工具在它们可以找到的各种问题上受到限制。
目前，实际上无法替代良好的手动可访问性测试。重要的是要对我们的用户表示同情，并确保内容实际上适用于人类。
说，自动化可访问性测试工具仍然是审计的重要组成部分。我喜欢使用的一种免费工具是Deque创建的AX DevTools浏览器扩展程序。使用此扩展程序，您只需导航到要审核的页面，单击扫描按钮，然后查看结果。
斧头DevTools扩展使用引擎盖下方的轴核规则。这些规则非常适合查找不正确的ARIA属性用法，重复的元素ID，颜色不良和排序标题级别。
此输出的发现可以帮助我发现我在键盘和屏幕读取器测试期间已经确定的最后一个问题。
结论
就是这样！可访问性审核的细节可能会根据功能或审核的目标而改变，但基本面始终相同。
如果内容可以与键盘和屏幕读取器一起使用，并且自动化可访问性工具是报道问题，那么您可以很好地创建更可访问的内容。
感谢您的阅读，并感谢您成为可访问性的Ally！