LG-13363: Fix Screenreader Focus Jumping During Selfie Capture

[charleyf]

🎫 Ticket

Link to the relevant ticket:
https://cm-jira.usa.gov/browse/LG-13363

🛠 Summary of changes

Fix a problem where when using a screenreader focus would jump away from the capture button in selfie capture. Slack thread here.

📜 Testing Plan

• Make sure you can reproduce the problem

  • Check out main
  • Log in
  • Get to front/back/selfie page
  • Turn on screenreader (iOS/chrome)
  • Open the selfie capture
  • Dismiss the camera permissions prompt (or allow)
  • Tap near or on the red capture button
  • Instead of focusing that button the focus of the screenreader jumps to the hidden close button in the top right.

• Check that the problem is fixed by this PR

  • Check out this branch.
  • Do the above steps again.
  • When you click the near the red button, focus will jump to to the red button. Clicking on the red button will also focus it correctly.

[charleyf]

Look for the camera container to see if Acuant has actually loaded their stuff onto the screen. Obviously inelegant, but does the job.

[aduth]

How does this update if Acuant becomes loaded? Are we expecting it to?

[charleyf]

Here's what I think is happening:

1. <AcuantSelfieCamera> is created, and Acuant is "started", but crucially the capture window doesn't appear anywhere yet.
2. <FullScreen> activates a focus trap around <AcuantSelfieCaptureCanvas>.
3. At this moment there's nothing inside that focus trap except a button and a div because Acuant hasn't actually attached to the div with acuantCaptureContainerId.
4. Then, Acuant attaches to the div with acuantCaptureContainerId and hydrates in their Shadow DOM.

The problem that this PR solves is that it lets me show the button on Step 3, and hide it on Step 4. Practically, what happens if you try to fully remove the button is you get an error about the FocusTrap always needing a tabbable element (which makes sense).

• So that close button needs to be present until the moment that Acuant's Shadow DOM gets attached.
• Having that button seems to be the cause of some odd behavior when using a screenreader so it's worthwhile to remove it.

[aduth]

The primary concern I have here is that I don't see where we predictably expect React to re-render this component after the changes you describe.

[charleyf]

A good point, the re-render isn't necessarily tied to this code in the way I want. We do re-render the AcuantSelfieCaptureCanvas every time the help text changes (frequently) so this value does get updated.

[amirbey]

LGTM 👍🏿

Thanks @charleyf

[aduth]

Can we add test coverage?

[charleyf]

RE: Test coverage @aduth. Unfortunately, we still do not have a way to actually get the Acuant SDK to start under any sort of testing conditions. It's a hole we've been aware of for a while, but it's pretty difficult to address.

[aduth]

I only see code which expects a DOM element with a particular ID, and a state updater. I don't know that we need a full Acuant installation loaded to be able to test against that.

[charleyf]

Added a test, which I think does a fairly good job showing how this functionality works.