如何防止屏幕阅读器焦点（不涉及键盘焦点）离开预定义区域（例如模式） [英] How to prevent screen reader focus (not referring to keyboard focus) from leaving predefined area (e.g., modal)

问题描述

我一直试图弄清楚如何将屏幕阅读器焦点包含在特定区域内。当我说屏幕阅读器焦点时，我并不是说可以通过按Tab / Shift-Tab键移动的默认浏览器焦点。在Mac上使用Voiceover时，我主要实现了可访问性，当您打开它时，页面上会出现一个新的焦点框，并读出突出显示的信息。

I've been trying to figure out how to contain the screen reader focus within a certain area. When I say screen reader focus, I don't mean the default browser focus that one can move with tabbing/shift-tabbing. I predominantly implement accessibility while using Voiceover on Mac, and when you turn that on, a new focus box appears on the page and reads out the information that it is 'highlighting'.

这时，如果要制表，浏览器和屏幕阅读器的焦点将同时移动。除了制表符以外，您还可以按住cmd + opt和左右键来将屏幕阅读器的焦点从一个元素移到另一个元素，无论是否可以将其切换到该元素。这就是我要包含的焦点。

At that point if you were to tab, both the browser and the screenreader focus move concurrently. Aside from tabbing to different focusable elements, you can also hold cmd + opt and keypress left and right to move the screen reader focus from element to element, regardless if one can tab to it. That's the focus that I'm trying to contain.

当焦点位于我最后一个元素上时，我尝试防止按cmd，opt和arrow键希望可聚焦，但浏览器似乎无法识别屏幕阅读器的焦点。而且我认为禁用键盘无论如何都不能与屏幕阅读器一起使用，因为它似乎独立于浏览器工作。

I've tried preventing cmd, opt, and arrow key key presses when the focus is on the last element that I want focusable, but the browser doesn't seem to recognize the screen reader focus. And I believe that the keyboard disabling wouldn't work with the screen reader anyways, as it seems to work independently of the browser.

我还尝试了动态添加tabindex ：-1和aria-hidden：模式出现时，对页面上的所有其他元素均为true。事后打开画外音时，此功能有效；屏幕阅读器的焦点实际上确实被困住了。但是，如果首先打开屏幕阅读器（在大多数用户实例中可能是这种情况），则屏幕阅读器将不遵守动态更改。就像屏幕阅读器在页面加载时获取可访问性状态的快照一样，并且它不尊重DOM的新更改。

I've also tried dynamically adding tabindex: -1 and aria-hidden: true to all other elements on the page when a modal appears. This works when you turn on Voiceover after the fact; the screen reader focus does in fact get trapped. However if the screen reader is on first, which likely will be the case in most user instances, the screen reader doesn't respect the dynamic change. It's like the screen reader takes a 'snapshot' of the accessibility state as the page loads, and it doesn't respect new changes to the DOM.

任何人都有任何想法？

推荐答案

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

You can't prevent key shortcuts of the screen reader from being used. They have priority over everything else. They aren't even caught by a keydown/up/press handler within your script. Fortunately for us as screen reader users, this isn't an acceptable way to go.

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

As you also have observed, the browse cursor is effectively completely independant from the system focus. The accessibility tree determines what is reachable when using the screen reader's browse cursor.

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

To temporarily restrict the elements seen by the browse cursor, you must use the aria-modal attribute. Put it on the root element that should be reachable. Everything inside will stay reachable. Everything else outside will no longer be reachable as long as the attribute stays on the element.

不要与aria隐藏游戏一起使用，以产生相同的效果。一些屏幕阅读器会遇到具有aria-hidden属性的嵌套元素的问题。
例如，如果外部元素具有aria-hidden = true，内部元素具有aria-hidden = false，则下颌将不会显示内部元素。

Don't play with aria-hidden to produce the same effect. Some screen readers have issues with nested elements having an aria-hidden attribute. For example, if an outer element has aria-hidden=true and an inner element has aria-hidden=false, Jaws won't show the inner element.

用aria-modal限制浏览光标，以及用aria-hidden来隐藏元素，并不自动暗示它们不能以常规系统焦点（Tab / Shift + Tab）进行聚焦。
因此，通常您会使用焦点陷阱将aria模态限制加倍，以防止系统焦点移到预期之外的地方。
如果不这样做，可能会给屏幕阅读器用户带来麻烦（如果焦点当前位于可访问性树中隐藏的元素上，屏幕阅读器应该怎么办？）。
这是一个经常性的疏忽。

Restricting the browse cursor with aria-modal, as well as hidding elements with aria-hidden by the way, doesn't automatically imply that they can't be focused with the regular system focus (Tab/Shift+Tab). You will therefore usually double the aria-modal restriction with a focus trap to prevent the system focus from going to a place where it isn't expected. If you don't do it, you may create troubles for screen reader users (what should the screen reader do if the focus is currently on an element hidden from the accessibility tree ?). This is a recurrent oversight.

最安全的焦点陷阱是在最后一个允许的元素上捕获tab，在第一个允许的元素上进行shift + tab，然后分别将焦点返回到允许的第一个或最后一个元素。
比将所有可聚焦元素设置为tabindex = -1然后再返回tabindex = 0容易得多，据我测试，它几乎可以在任何地方使用。

The safest to make a focus trap is to catch tab on the last allowed element and shift+tab on the first, and resp. bring the focus back to the first or last allowed element. It's much easier than setting all focusable elements to tabindex=-1 and then back to tabindex=0, and as far as I have tested, it works almost everywhere.

这篇关于如何防止屏幕阅读器焦点（不涉及键盘焦点）离开预定义区域（例如模式）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！