#47111 closed defect (bug) (fixed)
Dynamically added notifications need ARIA role alert or status
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.6 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Administration | Keywords: | has-patch has-testing-info commit |
Focuses: | ui, accessibility | Cc: |
Description
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
Change History (26)
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
19 months ago
#7
@
19 months ago
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.
#8
@
15 months ago
@joedolson Is this on your radar still for 6.5? Looks like a punt candidate given the lack of activity.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
15 months ago
#10
@
15 months ago
- Milestone changed from 6.5 to 6.6
Still on my radar, but not going to happen this cycle.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
12 months ago
This ticket was mentioned in PR #6639 on WordPress/wordpress-develop by @cyrus11.
11 months ago
#12
- Keywords has-patch added; needs-patch removed
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).
This ticket was mentioned in PR #6640 on WordPress/wordpress-develop by @cyrus11.
11 months ago
#13
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).
#14
@
11 months ago
- Keywords needs-testing-info added
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.
@joedolson commented on PR #6640:
11 months ago
#15
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!
#16
@
11 months ago
@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
#17
follow-up:
↓ 18
@
11 months ago
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.
#18
in reply to:
↑ 17
@
11 months ago
@joedolson Please review my testing instructions on the PR description.
#19
@
11 months ago
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.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
11 months ago
This ticket was mentioned in Slack in #accessibility by rcreators. View the logs.
11 months ago
#22
@
11 months ago
- Keywords has-testing-info added; needs-testing-info removed
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.
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
11 months ago
#24
@
10 months ago
- Keywords commit added
Tested Customizer & Widget and confirmed performance as expected. Marking for commit.
@joedolson commented on PR #6640:
10 months ago
#26
In r58455
Related, as a good example of dynamically added notifications: #47147.