如何防止屏幕阅读器焦点（不是指键盘焦点）离开预定义区域（例如模态）

Question

我一直在试图找出如何将屏幕阅读器焦点限制在某个区域内。当我说屏幕阅读器焦点时，我并不是指可以通过 Tab 键/Shift-Tab 键移动的默认浏览器焦点。我主要在 Mac 上使用 Voiceover 时实现辅助功能，当您打开它时，页面上会出现一个新的焦点框，并读出它“突出显示”的信息。

此时，如果您要按 Tab 键，浏览器和屏幕阅读器焦点会同时移动。除了按 Tab 键切换到不同的可聚焦元素之外，您还可以按住 cmd + opt 并左右按键将屏幕阅读器焦点从一个元素移动到另一个元素，无论是否可以按 Tab 键切换到某个元素。这就是我试图控制的焦点。

当焦点位于我想要聚焦的最后一个元素上时，我尝试阻止按下 cmd、opt 和箭头键，但浏览器似乎无法识别屏幕阅读器焦点。而且我相信键盘禁用无论如何都不适用于屏幕阅读器，因为它似乎独立于浏览器工作。

我还尝试在模式出现时向页面上的所有其他元素动态添加 tabindex: -1 和 aria-hidden: true 。当您在事后打开 Voiceover 时，此功能有效；屏幕阅读器焦点实际上确实被困住了。但是，如果屏幕阅读器首先打开（在大多数用户实例中可能会出现这种情况），则屏幕阅读器不会考虑动态更改。这就像屏幕阅读器在页面加载时拍摄可访问性状态的“快照”，并且不考虑对 DOM 的新更改。

有人有主意吗？

Answer 1

您无法阻止使用屏幕阅读器的快捷键。他们优先于其他一切。它们甚至不会被脚本中的 keydown/up/press 处理程序捕获。幸运的是，对于我们作为屏幕阅读器用户来说，这不是一种可接受的方法。

正如您所观察到的，浏览光标实际上完全独立于系统焦点。可访问性树确定使用屏幕阅读器的浏览光标时可以访问的内容。

要暂时限制浏览光标看到的元素，必须使用 aria-modal 属性。将其放在应该可访问的根元素上。里面的一切都将保持可及性。只要该属性保留在元素上，外部的所有其他内容都将不再可访问。

不要使用 aria-hidden 来产生相同的效果。某些屏幕阅读器对具有 aria-hidden 属性的嵌套元素存在问题。例如，如果外部元素的 aria-hidden=true 而内部元素的 aria-hidden=false，Jaws 将不会显示内部元素。

使用 aria-modal 限制浏览光标，以及使用 aria-hidden 隐藏元素，并不自动意味着它们无法通过常规系统焦点（Tab/Shift+Tab）获得焦点。因此，您通常会使用焦点陷阱将咏叹调模态限制加倍，以防止系统焦点转到意外的地方。如果不这样做，可能会给屏幕阅读器用户带来麻烦（如果焦点当前位于辅助功能树中隐藏的元素上，屏幕阅读器应该做什么？）。这是一个经常性的疏忽。

制作焦点陷阱最安全的方法是在最后一个允许的元素上捕获 tab，在第一个元素上捕获 shift+tab，然后再捕获。将焦点带回第一个或最后一个允许的元素。这比将所有可聚焦元素设置为 tabindex=-1 然后返回 tabindex=0 要容易得多，而且据我测试，它几乎在任何地方都有效。