Medallia intercept modal: can't interact with Medallia when it's stacked over another modal

[wesrowe]

What happened?

On mobile and desktop, when the Medallia intercept modal appeared on top of the Find-a-form PDF Download Instructions modal, my taps/clicks interact with the FaF modal underneath instead of the Medallia modal that is visible. So for instance, I am able to interact with the "download adobe reader" link as if the Medallia modal wasn't there at all (but I can't see it).

Modals where this occurs

• Find-a-form – the "download pdf" modal (see steps below)
• Sign-in modal (tested on Find-a-form page)

Screenshot of PDF Download modal:

Screenshot of Medallia modal: NOTE: the light blue highlight that appears here is misaligned because it's actually highlighting the PDF modal content.

Video Loom video

Specs:

• Device: iPhone 11 Pro; macbook
• Browser: Firefox (mobile), Firefox (macos), Chrome (macos)
• Test User (if applicable): N/A

Steps to Reproduce

• URL: on Staging (where Medallia modal is turned up to 100%) Find-a-form
• Test User (if applicable): NA

1. Go to Find-a-form and search for a form using e.g. "disability" on a mobile device
2. Click any "Download PDF" link among the search results
3. See PDF Download Instructions modal
4. Wait 15 seconds for the Medallia intercept modal to appear
5. Notice that you can't interact with the Medallia buttons and can't close it
6. Tap within the Medallia modal and see that you can
   • open the PDF (in a new tab)
   • Navigate to the Adobe Reader website (in a new tab)
   • Close both(?) modals at once by clicking the upper-right corner

Desired behavior

I should be able to interact with the modals separately – i.e., dismiss the Medallia intercept and be back to the PDF modal.

Acceptance Criteria

• [ ] Interact with Medallia modal when it appears over a VAgov modal.

How to configure this issue

• [ ] Attached to a Milestone (when will this be completed?)
• [ ] Attached to Epic (what body of work is this a part of? possibly Ongoing Maintenance)
• [x] Labeled with Team (product support, analytics-insights, operations, triage, tools-improvements)
• [x] Labeled with Practice Area (backend, frontend, devops, design, research, product, ia, qa, analytics, contact center, research, accessibility, content)
• [x] Labeled with Bug

[wesrowe]

@ianMcCullough-ob @aubreyarcangel, I updated the defect ticket to include desktop.

[wesrowe]

Oh good grief, it also happened to me on the sign-in modal. I'm surprised no one has complained about that before? Seems to me to be a high-impact issue. The only thing that makes that a tiny bit better is you can see the underlying modal's "x" to close it. One interaction worked: Escape key allows me to close the Medallia modal.

Screenshot below. Note that I highlighted the text in the sign-in modal after the Medallia modal appeared over it.

Screenshot

[laflannery]

Just some notes as I wanted to test this as well from an accessibility standpoint:

• The behavior is actually working properly for keyboard users:
  • When the Medallia modal is covering either of the other 2 modals I can user the keyboard to access Medallia content and only Medallia content
• However, mouse and touch users are unable to access Medallia. They should have the same experience as keyboard provides.
• Using Voiceover on mobile has the same experience as well - whereas the Medallia modal is on top however content is not being announced correctly. And it the user happens to be a sighted SR user, this would be very confusing for them.

[jamigibbs]

I'm investigating this issue from the DST side since it was brought to our attention via vfs-platform-support.

@wesrowe @aubreyarcangel @ianMcCullough-ob Ideally we would want the va-modal to take precedence over the Medallia modal. The feedback modal shouldn't be blocking anyone from important actions like signing in or finding a form. With that said, how much flexibility do we have with the Medallia modal? When I inspect the page, I'm seeing that it's adding a massive inline z-index:

z-index: 99999999 !important;

Changing that z-index to something more reasonable like 100 seems to resolve it:

[aubreyarcangel]

I am unsuccessful in overriding the inline z-index in my local devtools

#kampyleInviteContainer[style] {
  z-index: 100 !important;
}

#kampyleInviteModal[style] {
  z-index: 100 !important;
}

I have PR open to add the above custom CSS in the CSS file Medallia uses for all our customization, including overriding other inline styles, but like @jamigibbs, I am doubtful this will work.

If this solution does not work, we may need to adjust the z-index of the va-modal to be higher than Medallia intercept modal.

[jamigibbs]

@aubreyarcangel Thanks for giving that a try.

Is it possible to only trigger Medallia when there isn't an active va-modal on the screen?

Another things I noticed is that there is an existing z-index override already in a shame.css stylesheet. Increasing that higher than the Medallia modal works as well. Could that type of override be added into individual app stylesheets where the Medallia modal is active?

[aubreyarcangel]

@jamigibbs unfortunately no. Medallia does not have the ability to detect if there are other modals present.

[humancompanion-usds]

All - We can't fix this on our end given Medallia's aggressive code. I would suggest we file a bug with Medallia and inform them that their poor choice is breaking our pages. We will increase the z-index of our modal but we don't want to set the value to the egregious value that Medallia has chosen.

[wesrowe]

A backup idea was floated: keeping the Medallia modal off of specific pages/URLs. Has anyone here had the conversation with Medallia owners to ask whether they could prevent collisions that way? (I got an early No from Ian, but thought I should ask again...)

[ryguyk]

It seems that a solution to this problem has one of two paths:

1. Get our modal above (in front) of the Medallia modal.
2. Make the Medallia modal interactive so it can at least be dismissed.

Most of the conversation above falls into the first path. I think it's worth considering the second path as well. I'm adding some commentary around that path here.

First, the problem

Using react-focus-on, when a modal is opened, data-focus-on-hidden is added to essentially all of the elements on the page other than the modal itself. This attribute prevents interaction with the element on which it is applied. When the Medallia popup is added, it's added inside this wrapper that already exists on the page:

<span id="MDigitalInvitationWrapper">

When a modal is opened, the wrapper gets data-focus-on-hidden added:

<span id="MDigitalInvitationWrapper" aria-hidden="true" data-focus-on-hidden="true">

When the Medallia popup is then added inside this wrapper, it is disabled for interaction due to the data attribute already being present. It doesn't matter that it's got a higher z-index. It's appearing in front, but the user will never be able to interact with it.

A possible solution

If we could remove the data-focus-on-hidden from the wrapper (or prevent it from ever being added), it would become interactive. Those two options:

1. Remove it
   • In the code that opens a modal (design system), we look for #MDigitalInvitationWrapper and remove the data and aria attributes (possibly even conditionally based on whether the wrapper contains the actual Medallia content).
2. Prevent it from being added in the first place
   • We'd have to examine whether the npm module allows any exceptions to its adding the data attributes. Perhaps there's a way to tell it to ignore '#MDigitalInvitationWrapper`.

Neither of these approaches feels entirely clean, but this is clearly a problem that is going to require some level of workaround. This path offers a potential solution that is entirely within our control.