Dynamically added notifications need ARIA role alert or status

[afercia]

Follow up to #46995.

In the various admin screens, all the notifications / warnings and the like that are rendered "on the fly" and injected in the DOM need either an ARIA role alert or status to be properly perceived by assistive technologies and users using these technologies.

This doesn't apply to the standard "admin notices" that are normally rendered on page load. It only applies to JavaScript-rendered notices that appear at some point in a page. There are a few of them across the admin that would greatly benefit from a standardized component.

References:
​https://www.w3.org/TR/wai-aria-1.1/#alert
​https://www.w3.org/TR/wai-aria-1.1/#status

Quoting from the Aria Authoring Practices (emphasis mine):

Dynamically rendered alerts are automatically announced by most screen readers, and in some operating systems, they may trigger an alert sound. It is important to note that, at this time, screen readers do not inform users of alerts that are present on the page before page load completes.

W3C role=alert example:
​https://www.w3.org/TR/wai-aria-practices/examples/alert/alert.html

[afercia]

Related, as a good example of dynamically added notifications: #47147.

[afercia]

Related: #47147.

[joedolson]

This is a good thing to keep in mind while completing the work on #57791. Pinging @costdev to keep us both in the loop on that.

[swissspidy]

@joedolson Is this on your radar still for 6.5? Looks like a punt candidate given the lack of activity.

[joedolson]

Still on my radar, but not going to happen this cycle.

Fixes : ticket/47111

##Summary

Add role as alert on containers showing any type of dynamically added notifications error/success/informational notice (specifically on javascript files).

Fixes : ticket/47111

## Summary

Add role as alert on containers showing any type of dynamically added notifications error/success/informational notice (specifically on javascript files).

[joedolson]

Thanks, @cyrus11! The attached PR is a great start; the biggest gap is that it's going to need some testing instructions so that contributors can properly tested the patch. I checked the changes to user-profile.js, which apply to the password reset option on the user profile page. But some of the other changes would really benefit from testing instructions.

The code changes themselves look good and straightforward.

Added some additional instances I found while reviewing this. Please see the comments on the ticket, as well; this is going to need some testing instructions. Thank you!

[cyrus11]

@joedolson How do I test it on local and how to add testing instructions. I tried running the test scrips written on package.json npm run test:performance, npm run test:e2e and so on. But they all gave some sort of error I added the screenshots of the errors in this drive link .​https://drive.google.com/drive/folders/1mN3gEYgoNidhyhNUp8TSCVm5wavEOT_R?usp=sharing

[joedolson]

The automated test suite will have run as part of the Github Pull Request, so you don't really need to worry about running those locally. I can see that all of the unit tests pass with these, which is expected; the changes here aren't anything that would be picked up in the test suite.

I'm asking about manual testing: for each line of code modified, what is the process to check that the change has the expected result: where and when does that notice get rendered? It can be figured out from examining the code, but it can save a lot of time when getting multiple testers involved to have those instructions written out.

For example:

• Go to Users > Profile. Request a password reset. Verify that before the patch, the notice is not read out immediately by the screen reader and that after the patch, it is.

[cyrus11]

@joedolson Please review my testing instructions on the PR description.

[joedolson]

Thanks, @cyrus11! Those look great. Sample code to trigger the key errors can be useful, as well, but most of those errors should be fairly easy to trigger, so it's not crucial.

[rcreators]

I was able to test this PR with NVDA. Works Great. Here is the result of the test.

Testing steps needs to updated as below:

Sample: Go to tools -> erase personal data. Add username and add request. Once the request is added to the table below, hover on the title and you will find a quick action button. Clicking on the remove/erase personal data button will trigger an inline alert. Before the patch, this dialogue was not picked up by the screen reader. It is now working fine.

1) Privacy:

• Export Personal Data - have some issues with the trigger as the browser changes focus to save dialogue if the download destination is set to ask every time. If saved to fix the destination set, works great.
• Erase Personal Data - Work

2) Profile:

• If you go and edit different user from users list, below password reset field, you will find password request link button. Clicking on it, send request to user and will add an inline alert. - Works with NVDA

3) Plugin:

• Go to add plugin page. Disconnect your internet and try to install the plugin. It will give an inline alert of unable to install plugin. - Works with NVDA

4) Customizer & Widget:
Not able to generate any error. So not sure if it works or not.

5) Adding media to post:
Was able to generate error. - Works with NVDA.

[joedolson]

Tested Customizer & Widget and confirmed performance as expected. Marking for commit.

[joedolson]

In 58455:

Administration: A11y: Add role="alert" on JS injected admin notices.

Add the attribute role="alert" on 12 instances of admin notices that are injected into the DOM using JavaScript. The role="alert" attribute allows screen readers to recognize the addition to the DOM and announce the errors to users.

Props afercia, cyrus11, rcreators, joedolson.
Fixes #47111.

In r58455