aria-hidden-focus (6cfa84): as it applied to modal content (keyboard trap and aria-modal)

[mfairchild365]

Consider the following situation:

A modal dialog is displayed and is wrapped in a keyboard trap. All content behind the modal has aria-hidden="true" applied to it, but interactive elements are left in the tab order. Additionally, the modal dialog has aria-modal="true" set. However,

• Because of aria-hidden="true", it is not possible to navigate to the parent content in reading mode.
• Because of the keyboard trap that limits tab and shift+tab to modal content, it is not possible to navigate to interactive content outside of the modal.
• aria-modal="true" limits navigation to the modal content in most screen readers
• Only content in the modal appears in the screen reader's element list when the modal is open

I can't share an actual example of this (firewalls and whatnot), so here is some pseudo code:

<!-- parent content -->
<div aria-hidden="true">
   <p>we have the best stuff</p>
   <button>apply now</button>
</div>

<!-- open modal wrapped in a keyboard trap -->
<div class="keyboard-trap" tabindex="0"></div>
<div role="dialog" aria-hidden="true" aria-labelledby="dialog-title">
  <h2 id="dialog-title">Are you sure?</h2>
  <p>Please make sure that you are sure!</p>
  <button>Close</button>
</div>
<div class="keyboard-trap" tabindex="0"></div>

In this example, the "Apply now" button is in the tab order and would fail this rule as currently written, however, to my knowledge, it is impossible to actually navigate to it.

Should this rule still fail?

Referenced rule: https://act-rules.github.io/rules/6cfa84

Update: I found a pattern that is implemented like this in the wild, https://material.angular.io/components/dialog/examples

I tested with I tested with VO/iOS, VO/MacOS, Jaws, and NVDA, and none were able to access content outside of the modal (readig mode, tab or shift+tab, or via the elements list).

[timbomckay]

I referenced this issue in an axe-core issue as well.

Seems like there's a bit of discussion on this at axe-core. Not sure if this pertains more to ACT Rules or Axe-Core.

[carlosapaduarte]

I've tried this out with VO on Safari.

If I move the VO cursor out of the web content area (e.g. to the browser toolbar) and then back again to the web content area, the focus will no longer be trapped inside the modal. This means I'm able to tab through all the elements behind the modal until I eventually reach the modal and the keyboard focus is trapped again. All those elements have no accessible name and therefore are not announced by VO. Apparently, sequential focus navigation works by checking the blur event on stuff in the modal, instead of the focus event on stuff outside.

Closing this issue, as the rule looks to be producing true positives.

[mfairchild365]

Good catch @carlosapaduarte - I'm glad that you tested that.

It is technically possible to redirect keyboard focus to the modal when an element behind the modal receives keyboard focus. You can do this by attaching a focusin event listener to the document and inspecting the event target. I put together a super quick proof of concept. I believe that this proof of concept technically fails this rule because elements are still part of sequential focus navigation but to end-users, it is not possible to focus background content.