Functional users list overlays

[echappen]

Blocked by PR #476

Changes proposed in this pull request:

• Converts roles functionality in users list to overlays

Per engineering sync discussion, some additional acceptance criteria:

• When opening the dialog, we'll keep focus on the close button and allow users to tab through the rest of the content.
• Opening the dialog should also announce a title specific to the functionality being presented in the dialog.
• When closing the dialog, we'll keep the default behavior of returning focus to the last point of regard.
• When closing the dialog, we'll have SR's announce any success messages (while keeping default focus).
• While dialog is open, we agreed that a user should be able to click outside of it to close it. Since this is not default behavior for dialogs, we're going to spike on this and see what we come up with.

How to test

1. Log into the CloudFoundry dev environment through the CLI: cf login -a [url] --sso
2. Start up a dev server with a refreshed CF token: npm run dev-cf
3. Navigate to the users list: /orgs/[orgId]
4. For the org roles form, click any link under the "organization roles" column
5. For the space roles form, click any link under the "access permissions" column

Forms should operate the same as when they were on pages, with the only difference being that the overlay closes on form submission success.

Related issues

Closes #468

Submitter checklist

• Added logging is not capturing sensitive data and is set to an appropriate level (DEBUG vs INFO etc)
• Updated relevant documentation (README, ADRs, explainers, diagrams)

Security considerations

None, UI changes only

[echappen]

@beepdotgov @cannandev @hursey013 The only criteria I'm still having trouble with is announcing the success message—can't get it to announce. I'll keep working on that, but otherwise, I think this is ready for eyes!

[echappen]

I'm going to make dynamic url params a separate GH issue—I might get to it depending on how much I need to update with this PR, but I don't want it to block the rest of the work.

[beepdotgov]

@echappen Seriously, this is looking fantastic so far. I’ve left a few design suggestions/requests, and a couple non-blocking comments. Please let me know if anything’s unclear, or if you’d like to discuss anything further!

[echappen]

I’ve been working on getting aria-live regions to be more consistently read by VoiceOver. The lack of consistency still perplexes me.

I know that in order for aria-live regions to be read, two things need to be true (this article is a good summary):

1. aria-live regions need to be present in the DOM on initial page load, and
2. Screen readers will only read updates to these regions (it won’t read text already present on page load)

I suspect the inconsistency is coming down to the timing between a react component re-rendering (thus re-loading that part of the DOM) and a message updating. I think the reason that the success message wasn’t being read was because these things were happening at the same time.

Putting a 1/2 second delay on the message update solved this issue. But I’ve also been looking into alternatives, and I’m intrigued by this approach, which is now an npm package. This approach uses the React Context API, which I haven’t used at all, so I’m less comfortable with it. @cannandev @hursey013 Any thoughts on this approach and if we should try it?