Improve the admin notices accessibility

[afercia]

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.

[psykro]

@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

2. 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.

[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.

[raaaahman]

Replying to afercia:

• 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

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?

[psykro]

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, line 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.

[SergeyBiryukov]

Related: #57791

[oglekler]

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

[marybaum]

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

[joedolson]

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.

[joedolson]

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

[swissspidy]

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

[joedolson]

Moving to 6.6; this will need more time.

[sabernhardt]

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