fix: safari focus

[jadutter]

Description

• Improve accessibility
  • adjusted how focus is handled when the modal opens and closes
  • added some aria attributes to increase accessibility
  • Updated the prerender modal close button to receive focus when opened
• Updated the prerender modal
  • close button to look identical to the modal close button
  • cleaned up some lint issues
• Removed unused code useAutoFocus
• Improve debugging
  • added debug levels to control logging verbosity
  • added debug messages and listeners to view events and their order
  • split into a separate PR

Screenshots

Testing instructions

[Seavenly]

Is there an event we should be looking for like the document DOMContentLoaded or window load event? If so would we be able to leverage these either of these helpers? https://github.com/paypal/paypal-messaging-components/blob/develop/src/utils/events.js#L11-L21. If we aren't waiting for a specific DOM event and just need to ensure the browser has had a render cycle, could we use requestAnimationFrame instead? The primary concern with setTimeout is it is an arbitrary time that may or may not fire the same based on device performance.

[jadutter]

While manually testing in Safari, I found that

1. The the close button for the modal needed the autofocus attribute
2. The iframe for the modal in the parent page needed to receive focus
3. The close button for the modal needed to receive focus

The events appeared to be happening in the correct order, but from what I could tell, the iframe was going to be given focus, but had not yet received focus (I found something similar happening with the tabTrap).

I thought about setting up listeners to ensure the button focused happened after the iframe, but I realized I would need

1. on the parent page, I would need to listen for when the iframe received focus, then pass the info onto
2. the zoid event emitter in the parent page, the pass the info onto
3. a listener in the child iframe, that would finally add focus to the button

I thought about it some more, and I figured the direct pipeline I would setup would be unideal. We are already using MODAL_EVENT.MODAL_SHOW to communicate almost the same thing. Creating a pipelline for MODAL_EVENT.FOCUS seemed like a lot of extra code to add onto messaging just to focus the close button.

I found that bumping it to a different place in the event cycle was enough for it to behave correctly though, not necessarily needing to wait literally 10ms.

I'll change it to requestAnimationFrame since it appears to work too.

[jadutter]

After further testing, I've realized my PR only partially fixed the issue:

• modal open
• modal close
• message has focus
• modal open
• modal close
• modal still has focus

Going to keep working on it

[jadutter]

I've gotten it to a decent state, I think. The two caveats I'm thinking of are:

1. We'll need to revisit making sure the prerender modal is accessible. I tried to clean it up a bit, but
   1. I couldn't get its close button to receive focus after opening, closing, and opening again.
   2. I wasn't at all certain how to effectively communicate via accessibility tags to a non-visual user "you are on a modal that is currently loading content" or announce "the modal has failed to load"
2. The modal button receives focus in Chrome, but only the modal receives focus in Safari. Apparently, Apple intends this as a "feature"; the user must directly interact with the iframe before any elements in the iframe can be given focus. After the user interacts with the elements within the iframe for the modal, then we can call focus() on the close button. Since the modal can still be navigated after the iframe for the modal receives focus, I was going to let this one go

[github-actions]

🎉 This PR is included in version 1.49.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀