Mobile navigation dialog does not make background content inert

[aduth]

Description

When the mobile navigation menu drawer is activated, it appears to behave like a dialog, where focus is trapped and background content is dimmed and seemingly intended to be unreachable as long as the drawer is visible. However, the content is still present in the accessibility tree, and is still otherwise reachable by focus means not handled currently by the focus trap behaviors. Users who use screen reader tools to navigate page contents (e.g. VoiceOver Web Item rotor) can still access contents outside the dialog.

Steps to reproduce the issue

1. Navigate to Basic Header demo
2. Shrink the page, or zoom in to the point where the mobile navigation styling is activated
3. Tab to and activate the menu button using Space
4. Press Cmd+L (Ctrl+L) to move focus to the address bar
5. Press Tab to re-enter the page contents

Expected behavior: Because focus has moved outside the drawer, it may make sense that the drawer be dismissed. This follows behavior of clicking the overlay to dismiss the navigation drawer, which is another means of moving focus outside the navigation contents.
Actual behavior: The navigation drawer remains open while focus moves around the page.

Alternatively, using macOS VoiceOver Rotor:

1. Navigate to Basic Header demo
2. Shrink the page, or zoom in to the point where the mobile navigation styling is activated
3. Tab to and activate the menu button using Space
4. Activate VoiceOver using Cmd+F5
5. Activate VoiceOver Rotor using Option+Control+U

Expected behavior: Only the contents of the dialog are presented in the rotor.
Actual behavior: All page contents are presented in the rotor. Navigating to said page contents will not dismiss the visible drawer.

Additional information

While the sample codes do not assign the dialog role, it does appear to inherit many of the behaviors associated with the role:

1. Focus is transitioned into the dialog

   • Authors SHOULD focus an element in the modal dialog when it is displayed

2. Focus is managed such that it cannot escape the dialog by Tab

   • authors SHOULD manage focus of modal dialogs

3. The dialog appears on top of the background content, which is dimmed

   • Dialogs are generally placed on top of the rest of the page content using an overlay.

4. Escape dismisses the dialog

   • Escape: Closes the dialog

(Aside: It might be a separate issue to consider if the role should be explicitly assigned)

While it is possible to prevent keyboard users from moving focus to elements outside of the dialog, screen reader users may still be able to navigate to that content using their screen reader's virtual cursor. It is important for developers to ensure that content outside of the modal dialog is inaccessible to all users while the modal dialog is active.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/dialog_role#Notes

(Emphasis mine)

Notes on aria-modal and aria-hidden:

1. The aria-modal property was introduced in ARIA 1.1. As a new property, screen reader users may experience varying degrees of support for it.
2. Applying the aria-modal property to the dialog element replaces the technique of using aria-hidden on the background for informing assistive technologies that content outside a dialog is inert.
3. In legacy dialog implementations where aria-hidden is used to make content outside a dialog inert for assistive technology users, it is important that:
   a. aria-hidden is set to true on each element containing a portion of the inert layer.
   b. The dialog element is not a descendant of any element that has aria-hidden set to true.

https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/dialog.html

(Emphasis mine)

For example, when a modal dialog is displayed, it is expected that the user's interaction is limited to the contents of the dialog, until the modal dialog loses focus or is no longer displayed.

https://www.w3.org/TR/wai-aria-1.1/#aria-modal

For instance, a user should be able to leave the current document to access the browser’s chrome (e.g. via use of the F6 key to move focus to the browser’s address bar). When this user attempts to re-enter the document, inert and aria-hidden="true" will prevent their focus from landing on elements obscured by the modal dialog, and ensure the only place for the user’s focus to go, would be to the contents of the dialog.

Adding aria-hidden="true" to elements outside of the active modal dialog ensures that elements not within the active modal dialog will not be surfaced if a user opens a screen reader’s list of elements (headings, form controls, landmarks, etc.) in the document. This would be something that aria-modal="true" would take care of, pending its current issues with VoiceOver get resolved.

https://developer.paciellogroup.com/blog/2018/06/the-current-state-of-modal-dialog-accessibility/

Note: This last article has a lot of important guidance around "gotchas" of dialog behaviors and incompatibilities of various implementations.

Relevant JavaScript code: https://github.com/uswds/uswds/blob/develop/src/js/components/navigation.js

Earlier related issue: #2031 (initial focus trapping added in #2347)

[thisisdano]

@jaredcunha I'm sorry, this issue slipped through the cracks for me. Does it have any relevance to your work on modal — or, can any of your work on modal be applied to header to address this issue? To be clear, I'm not asking you to do this, only if we in Core can apply your work to this?

[jaredcunha]

@thisisdano Modals address this by applying aria-hidden="true" to all content except for what's within the modal when it is open. The modal JS moves the modal windows to the bottom of the DOM so it's easier for the JS to distinguish them from background content. You can see all the aria-hidden attributes when the modal is open here:

Those are removed when the modal closes.

I have noticed that the mobile navigation does not render background content inert, so using Voice Over, it's still possible to exit the menu and interact with other content on the page either by dragging a finger around the page on a mobile device or by pulling up the rotor menu.

[amyleadem]

Confirmed. Users are able to access page content while menu nav is open. This happens when:

• On desktop, tab focus moves from the browser chrome onto the page

• On iOS, voiceOver is activated it is possible to interact with the exposed page content through touch.

This happened on all browsers tested: Safari 15.1, Firefox 89.0, Chrome, iOS Safari.