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'.

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.

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.

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.

Anyone have any ideas?

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'.

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.

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.

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.

Anyone have any ideas?

• javascript
• accessibility
• wai-aria

Share Improve this question Follow asked Oct 17, 2019 at 13:12 Michael RMichael R 9111 silver badge33 bronze badges

Add a ment  | 

1 Answer 1

Sorted by: Reset to default 3

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 pletely independant from the system focus. The accessibility tree determines what is reachable when using the screen reader's browse cursor.

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.

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.

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.

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.