Modal Dialog does not conform to WAI-ARIA accessibility guidelines

[jmahurin]

Bug Report

Description

ACCESSIBILITY ISSUE WITH MODAL DIALOG

The modal focus should wrap focusable elements when the user presses the tab key. A modal should give the first element focus and as the user tabs through the elements, each succeeding element in the logical flow should receive focus. When the last element is reached, pressing the tab key should wrap the focus to the first element.

The Terra ModalManager does not behave in the way as specified by the W3C WAI-ARIA guidelines and recommendations. For more information on modal practices see: https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal

The above link has a demo on how the modal dialog box is expected to work to make it more accessible. This is a somewhat of a barrier for keyboard-only and sight challenged users. For example, a non-sighted user will not know when he/she has reached the last button. Hitting tab will throw them off of the page and they have to find their way back to where they were.

Steps to Reproduce

1. Open the link: https://engineering.cerner.com/terra-ui/components/terra-modal-manager/modal-manager/about
2. Click on the Disclose (default) button
3. Use the tab key to move the focus to the various elements
4. At this time, the last focusable element is a text field. Hit tab again and the focus jumps out off the page and to the browser's address bar

Additional Context / Screenshots

From the following link, click on the Add Delivery Address button for the W3C example of how a modal dialog box should work.
https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal

Expected Behavior

The focus should wrap when a user reaches the last focusable element and move to the first when the tab key is pressed.

Possible Solution

Remediate the modal dialog box to comply with W3C recommendations.

Environment

• Component Name and Version:
• Browser Name and Version:
• Node/npm Version: [e.g. Node 8/npm 5]
• Webpack Version:
• Operating System and version (desktop or mobile):

@ Mentions

[tbiethman]

We have different modal components that are used for functionally different workflows. The ModalManager is intended to be used for the disclosure of additional page content. It's always easily dismiss-able, with both Escape key press and an explicit Close button both resulting in the dismissal of the modal.

Conversely, the NotificationDialog is presented modally but is intended to be used for situations requiring explicit user input before dismissal (think your typical OK/Cancel options). This modal does not close on Escape key presses, and no explicit Close button is rendered. The modal is only closed upon selection of an action.

So with that context, this issue was logged in regards to the ModalManager not featuring a focus trap and allowing focus to leave the modal. While the other application content is inerted and inaccessible, the user can still tab through browser elements (tabs, bookmarks, etc.) before getting back into the modal content.

This is in contrast with the NotificationDialog, which does include a focus trap and keeps focus trapped within the modal until it is dismissed.

I reached out to @scottwilmarth to verify the expected behavior. Scott indicated that for modals that do not require explicit user action (e.g. the ModalManager), the current behavior without trapped focus is expected. So I don't believe that there are any changes to be made at this time.

[scottwilmarth]

My apologies @tbiethman. Emily and I were not on the same page when discussing the issue. This issue should remain and be worked. Neither Notification Dialog or Modal Manager should allow users to key to the URL bar. User focus should be trapped to the modal window for both.

[tbiethman]

Thanks @scottwilmarth. Then we'll need to investigate the addition of the focus trap back into the ModalManager or another mitigation. The addition of the focus trap back into the ModalManager will cause conflicts with other focus trapping elements like Popup and NotificationDialog.

[scottwilmarth]

One other quick comment that while we are trapping focus on the modal itself, the user could still use the keyboard and switch to a different browser tab via standard browser keyboard shortcuts. (I don't think that blocking the user from switching tabs was even part of the conversation, I just wanted to make sure it was clear.)

[tbiethman]

We met with @scottwilmarth yesterday for further discussion of this issue.

We know we need to get this updated to align with ARIA recommendations. However, updating the existing ModalManager to include a focus trap would have downstream impacts to other focus-trap reliant components, like the popup, datepicker, and notification dialog, that can present on top of modals.

Given that impact, and given that this issue is not viewed as a critical impact to user functionality, we proposed to leave the ModalManager implementation as-is and fix this implementation with our major terra-application work due at the end of the year. That'll give us the time and leeway to make solid changes.

[jmahurin]

@tbiethman

Thank you for the update and consideration.