When closing an overlay drawer, the success message isn’t announced [Safari/VoiceOver]

[beepdotgov]

After successfully completing a task in an overlay drawer, the drawer closes, and focus returns to the table. (#496) Unfortunately, the success message isn’t announced by VoiceOver, so there’s no indication that the transaction successfully completed.

Here’s a screen recording of this behavior:

overlay.close.mov

(No audio, sorry; couldn’t find a way to do that on macOS.)

Can this task be done in one increment?

Unknown; marking as research.

Acceptance Criteria

• The drawer closes successfully
• The message is announced by VoiceOver

[echappen]

Consider trying out this approach (now an NPM package) - original thread

[echappen]

Here are my findings from taking a few days to research this issue:

In most cases, our live regions are USWDS Alerts. Since the app updates success messages dynamically (like with other alerts), we want them to be read with the same level of urgency. Upgrading success alerts to role="alert" instead of role="status" made them read more consistently.

You can see how all types of alerts are read on any page form:

• /orgs/:org_id/users/:user_id for space roles form
• /orgs/:org_id/users/:user_id/org-roles for org roles form

This can also be observed with pending and error alerts in form overlays:

• /orgs/:org_id

I believe this narrows down the problem described in this issue to the specific workings of the Manage Users page.

When closing an overlay, the success alert that shows up on the top of the page is still inconsistently read. When an overlay is closed, we refocus the user back to the last point of regard on the page before the overlay was opened. My theory is there's confusion between the SR wanting to read wherever you're refocusing to (like a table cell) instead of reading the success alert at the top of the page.

I recommend exploring this approach:

1. When an overlay form succeeds, keep the overlay open and show the success alert in the overlay (similar to a page form)
2. Refocus the user to the success alert. Add a button in this alert prompting the user to close the overlay.

This approach could have the added benefit of fixing issues like #544 where it's unclear what's been changed in a success message. (Keeping the user in the form will show exactly what's been changed.)

[echappen]

I also took the time to experiment with using React's Context API to handle aria live messages. The packages linked above weren't compatible with React 18, so I created a custom prototype to demonstrate how Context can be used for this. I believe this approach could be used in the future, for global invisible alerts to be read. But I see no current use cases for it, as our current use cases deal with visible USWDS Alerts that should be read instead. This can be seen on the branch eoc/531-context.

[beepdotgov]

Just logging two things for myself before tomorrow’s jam:

• Sara Soueidan on accessible notifications
• A quick sandbox/sketch I threw together to explore options

[echappen]

Our TODO's from our discussion at a11y jam are:

1. Ensure that the aria-live region in the alert component is present on page load and use an isVisible prop to show/hide the alert instead
2. Success alerts will use use role=status (equivalent to aria-live=polite aria-atomic=true)
3. Error alerts will use role=alert (equivalent to aria-live=assertive aria-atomic=true)

These are done in #581