Make WordPress Core

Opened 4 years ago

Last modified 4 weeks ago

#50486 accepted defect (bug)

Improve the admin notices accessibility

Reported by: afercia's profile afercia Owned by: joedolson's profile joedolson
Milestone: 6.8 Priority: normal
Severity: normal Version:
Component: Administration Keywords: needs-patch dev-feedback
Focuses: ui, accessibility Cc:

Description

Follow-up to #47656. See also #50442/

The admin notices accessibility has room for improvements.

Currently, all the admin notices are just text printed out on the admin pages. They have no special semantics. There are no mechanisms to inform users some important information is printed on the page other than visuals. There are no methods to navigate directly to admin notices nor established standards on their placement.

This way, users with accessibility needs will likely miss important information, as they may have no clue whether and where these messages are printed out.

Depending whether the admin notices are PHP-generated notices that appear after a page load or JavaScript-generated ones that are "injected" into the DOM, there are ways to improve their accessibility. At the very least, the following improvements should be considered, some of them were mentioned in #47656.

All notices

  • establish standards for the admin notices placement in the page: there should be one, well defined, area where notices are printed out (recommended: after the main H1)
  • establish standards for the admin notices content: see the discussion related to the "text prefix" on #47656 and #50442
  • the above item should apply to the whole WordPress UI, including the block editor
  • "inline" notices (the ones printed out in the middle of the page): make a decision whether to keep them or allow only notices at the top of the page
  • if "inline" notices are kept, explore ways to make them more accessible
  • worth considering admin notice should be visually prominent and appear within the initial viewport anyways
  • consider the introduction of a dedicated PHP class with methods to get / print admin notices and additional features, also keeping into consideration the WP Notify project and the recent call for feedback on the WP Notify v1 requirements document

PHP notices

  • prepend to the document title a short text to inform users there are notices and their number: the document title is the first thing screen readers announce after a page load
  • the notices should be printed out after the main H1 heading as that's the part of the content with higher chances to be navigated to
  • define the page area where notices are printed out with an ARIA role that's also a landmark role, e.g. complementary (an <aside> element) or other role that is a landmark
  • add a new "skip link" after the "Skip to main content" one to allow all keyboard users to jump to the notices area: this skip link should only be printed out when there are notices

JavaScript notices

  • all notices injected in the DOM should have an ARIA role alert or status depending on their "politeness" level, so that they're automatically announced by screen readers

Any additional suggestion and/or technique to improve the admin notices accessibility is very welcome.

Change History (35)

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.


3 years ago

This ticket was mentioned in Slack in #feature-notifications by ryokuhi. View the logs.


3 years ago

This ticket was mentioned in Slack in #feature-notifications by raaaahman. View the logs.


3 years ago

#4 @psykro
3 years ago

@afercia thanks for detailing these issues. To clarify what you have raised here, I have a couple of questions.

"inline" notices (the ones printed out in the middle of the page): make a decision whether to keep them or allow only notices at the top of the page

  1. Can you give me an example of this type of inline notice?

the notices should be printed out after the main H1 heading as that's the part of the content with higher chances to be navigated to

  1. Is this not currently the case? If I use the example notice from the official documentation:
<?php
function sample_admin_notice__success() {
        ?>
        <div class="notice notice-success is-dismissible">
                <p><?php _e( 'Done!', 'sample-text-domain' ); ?></p>
        </div>
        <?php
}
add_action( 'admin_notices', 'sample_admin_notice__success' );

it's rendered just below the main h1 of that admin page.

#5 follow-up: @ryokuhi
3 years ago

Hello @psykro,
You can find a screenshot in ticket:47656#comment:29: I think this is an example both of an inline notice and of a notice that is printed in the middle of the page and not right after the H1 element.

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.


3 years ago

This ticket was mentioned in Slack in #feature-notifications by raaaahman. View the logs.


3 years ago

#8 in reply to: ↑ description @raaaahman
3 years ago

Replying to afercia:

It would be worth coordinating the effort on that class with the WP Notify project indeed. If we manage to define a common interface for the 'get/set' methods, we may be able to change its implementation for the new dispatch mechanism when it become fully operational. We are going for a [Repository](https://github.com/WordPress/wp-notify/blob/develop/includes/persistence/interface-wp-notify-notification-repository.php), would this interface match your needs?

This ticket was mentioned in Slack in #feature-notifications by jon_bossenger. View the logs.


3 years ago

#10 in reply to: ↑ 5 @psykro
3 years ago

Replying to ryokuhi:

Hello @psykro,
You can find a screenshot in ticket:47656#comment:29: I think this is an example both of an inline notice and of a notice that is printed in the middle of the page and not right after the H1 element.

Thanks, @ryokuhi I see that this code is in the /wp-admin/plugin-editor.php file, like 283

https://github.com/WordPress/wordpress-develop/blob/6d574d7cabfaf6cc9797d2119ba1a10d9cd78fa3/src/wp-admin/plugin-editor.php#L283

The "problem" we have here is that it seems there are two ways that WordPress core renders admin notices from the PHP side.

  1. using the admin_notices action hook
  2. hardcoded inline in specific pages (like the plugin-editor.php)

So the first, and most important step will be to look for any instances where notices are hardcoded in this way, and replace them with admin_notices callback functions.

Once all admin notices are registered in the same way, we can apply rules to all admin notices, and be sure that they will all receive the same updates/changes.

Please let me know if you have any questions here.

Version 0, edited 3 years ago by psykro (next)

This ticket was mentioned in Slack in #accessibility by alexstine. View the logs.


2 years ago

#12 @alexstine
2 years ago

  • Keywords needs-patch added

#14 @joedolson
21 months ago

  • Owner set to joedolson
  • Status changed from new to accepted

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


19 months ago

#16 @joedolson
19 months ago

  • Milestone changed from Awaiting Review to 6.3

This ticket was mentioned in Slack in #core by oglekler. View the logs.


17 months ago

#18 @oglekler
17 months ago

  • Keywords dev-feedback added
  • Milestone changed from 6.3 to 6.4

This ticket was discussed in the recent bug scrub.

It looks like this cannot be ready to the Beta 1 and due to the existing project Feature notifications in needs to be revised, more info in #comment:8 but for now I am moving this ticket to 6.4

Additional props @mrinal

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


17 months ago

This ticket was mentioned in Slack in #core by oglekler. View the logs.


15 months ago

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


15 months ago

This ticket was mentioned in Slack in #core by marybaum. View the logs.


15 months ago

#23 @marybaum
15 months ago

Thanks to a note @joemcgill surfaced from @joedolson, this can move forward. That note is at https://wordpress.slack.com/archives/C02RP4X03/p1692376124664849

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


14 months ago

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


14 months ago

#26 @joedolson
14 months ago

  • Milestone changed from 6.4 to 6.5

This will not be ready for 6.4, but following the work done in #57791 during 6.4, I think it's plausible for 6.5.

#27 @joedolson
13 months ago

Also pinging @costdev on this ticket, as it's another thing related to #57791 to look at.

#28 @swissspidy
9 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.


9 months ago

#30 @joedolson
9 months ago

  • Milestone changed from 6.5 to 6.6

Moving to 6.6; this will need more time.

This ticket was mentioned in Slack in #core by oglekler. View the logs.


5 months ago

This ticket was mentioned in Slack in #accessibility by rcreators. View the logs.


5 months ago

#33 @sabernhardt
5 months ago

  • Milestone changed from 6.6 to Future Release

I'm moving this to Future Release, but please add a numbered milestone as soon as the ticket has more activity.

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


4 weeks ago

#35 @joedolson
4 weeks ago

  • Milestone changed from Future Release to 6.8
Note: See TracTickets for help on using tickets.