Focus should not leave OMB Component Modal

[jeana-adhoc]

Bug Report

• I’ve searched for any related issues and avoided creating a duplicate issue.

What happened

In the 508 audit on form 21-10210, received this note from the 508 office regarding the OMB component.

Focusable components in the content do not receive focus in an order that preserves meaning and operability. The following is an example:
On the 21-10210 Lay/Witness Statement | Veterans Affairs screen, the focus is not moved to a place that preserves meaning and operability. After activating View Privacy Act Statement Button, when focus is on the Close Privacy Act Statement modal Button the focus can be moved outside the modal when navigating with shift + tab.

WCAG 2.4.3 - Focus Order

I was able to recreate this in storybook. It never happens when you just tab. But when you shift+tab (reverse tab) the focus leaves the modal. If you try this on the regular modal component, the focus never leaves the modal itself.

What I expected to happen

The focus to never leave the modal

Reproducing

• Formation version:
• Device: (e.g. iPhone 8, Macbook)
• Browser: (e.g. Firefox, IE 11)

Steps to reproduce:

1. Open https://design.va.gov/storybook/iframe.html?id=components-va-omb-info--default&viewMode=story
2. tab with the keyboard to the "Privacy Act Statement" button
3. Hit enter on the keyboard
4. See the modal load
5. Press shift+tab on the keyboard
6. Observe that the original "view privacy act" button gets the focus. (If you press space or enter while the button is activated, it will close the modal")
7. While within the modal, if you click the close button, the focus does not show itself around the privacy act button, and the <title> is read, and then it just starts reading down the page.

Urgency

How urgent is this request? Please select the approriate option below and/or provide details

• This bug is blocking work currently in progress
• This bug is affecting work currently in progress but we have a workaround
• This bug is blocking work planned within the next few sprints
• This bug is not blocking any work - It is not blocking work because it's already in production.
• Other

Details

[caw310]

Hey team! Please add your planning poker estimate with Zenhub @Andrew565 @ataker @harshil1793 @it-harrison @jamigibbs @micahchiang @nickjg231 @powellkerry @rmessina1010 @rsmithadhoc

[jeana-adhoc]

Since opening this ticket, I discovered another issue with the modal. When the modal is closed, focus is lost. The keyboard seems to be below the button, but when you press tab, the phone number in the footer gets the focus indicator. However, if you just close the modal, the screen reader announces the Page <title>. When the modal closes, focus should return to the "Privacy act" button, and the privacy act button should be announced. The correct behavior is displaying properly in the modal in storybook, but not in the omb component in storybook.

Here is a video

OMB-component.mov

[caw310]

cross referencing as could be similar to this issue. 2255

[Andrew565]

The Problem with Modal Focus Trapping

Currently modals use a "focusin" listener to detect when focus leaves the modal and enters the main body of a document. The Shadow DOM messes up the "focusin" listener, such that it doesn’t fire for anything inside of a Shadow DOM.

document.querySelector(“:focus”) doesn’t track inside of the shadow DOM, making it difficult to programmatically detect which element is currently focused. Workaround has been to use event.composedPath() and compare with a list of "focusableChidren", which 'double counts' the va-telephone element and its enclosed a tag. This has been used with the keydown event, which works inside of Shadow DOM, but sequential focusing (using the tab key) prevents the .focus() method from working properly, so the focus ends up getting ‘stuck’ on the close button.

This article suggests using <dialog> could work better, but:

• it ‘leaks’ focus to the browser address bar (some call this a feature, others call it a bug)
• would require a rewrite of the modal component
• Doesn’t support Safari < 15.4

Options

• Best option is to get rid of shadow dom and rely on the existing “focusin” listener.
• Second best option would be to add a 'focusin' listener to the OMB-info and CLM "modal triggering buttons" which would redirect focus back to the modal, but may still momentarily read out their contents to screen readers in the process.
• Third best option is to use a dialog with the known caveats.
• Fourth best option is to keep things as they are, with a faulty focus trap for OMB-info and Crisis Line Modal (other modals unaffected).

(This was also posted to Slack, will update here when any decisions are made.)

[Andrew565]

The solution decided on was to attach 'focus' listeners to the modal-triggering buttons for the OMB Info and Crisis Line Modal components, which appears to work well enough for our needs.

[Andrew565]

After receiving more feedback from Ryan, the following work still needs to be done:

• Need to apply 'button focus hack' to the minimal header VA logo
• Need to reconfigure 'button focus hack' and 'initial modal open' behaviors to focus on the 'role="dialog"' element rather than on the close button
• Need to reconfigure 'button focus hack' to focus on the last element rather than the first element when the modal is shift+tabbed into (this may not be feasible without some significant refactoring of the modal, as the button hack doesn't know about the modal's focusable elements beyond the 'role="dialog"' main element and the close button, and those it only knows about because they're hardcoded into the hack)
• Firefox doesn't read anything in the modal, a problem which is better addressed by va-modal and va-crisis-line-modal Accessibility Bugs (Readers and Focus) #2255

Because of these additional requirements, I adjusted the point estimate for this ticket from 3 to 5, and expect that it will carry over. CC @humancompanion-usds , @caw310, @micahchiang