Allow to control aria-live attribute in settings_errors()

[andremenrath]

Users using a screen reader get not properly noticed about admin notices added with the function add_settings_error().

The attribute aria-live could help to point the attention to settings errors in multiple levels.

​https://developer.mozilla.org/de/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-live

[joedolson]

This is effectively a subset of the issue noted in #50486. This could be somewhat helped by adding role="alert", which can be used at initial load to trigger a notice being read. However, that is not reliable; the alert role is intended to be equivalent to aria-live="assertive", and is not intended by design to be read on page load, though some screen readers do.

What probably does make sense is for add_settings_error() to support all the same parameters already supported in wp_admin_notice(), and to use those functions to print output. This would also have the advantage that settings errors would be filterable.

I'm also noting that the output of added settings errors in settings_errors() wraps the message text in strong elements, which is not something we want, per the recently closed #50402.

This dates back to the addition of the function in version 3.0.0.

[abcd95]

I have attempted to make the add_settings_error() function support the parameters as wp_admin_notice() does. Now, regarding the latter part, the output wrapped in <strong>, I am not sure if we must remove the bold entirely or make specific parts bold, so I am waiting for some feedback on that.

[sainathpoojary]

Test Report

Description

This report validates whether the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8642

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.27.5
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 136.0.0.0
• OS: macOS
• Theme: Twenty Seventeen 3.8
• MU Plugins: None activated
• Plugins:
  • MyPlugin
  • Test Reports 1.2.0

Actual Results

✅ Issue resolved with patch.

Supplemental Artifacts

Before:

After:

[joedolson]

This will need a detailed test route so that this can be tested properly. The above test by @sainathpoojary is unfortunately invalid, as it does not test a usage of settings_errors(). settings_errors() is only used in settings pages.

[joedolson]

I've been slow in getting this testing information provided; I'm going to commit to doing that this weekend, and will conduct the tests myself.

[joedolson]

On testing, the intent of this ticket won't have the desired effect. While aria-live is useful for ensuring that a JS-inserted error message is announced by a screen reader, it doesn't have any impact on a page if the content inside the aria-live region is already set when the page is loaded, which will be the case in settings pages.

What would potentially do the job would be to add JavaScript which looked for settings update notices and executed a wp.a11y.speak() command after the page was loaded. This will require some extra thinking, however, to ensure that it *doesn't* catch all of the junk marketing notices that plugins inject into the admin, as those would be undesirable.

Given the remaining timeline for 6.9 beta 1, I'm going to move this to 7.0, to figure out this alternative path.

[joedolson]

A possibility for reducing announcements could be to read the full notice if there's only one, but only announce the number of announcements if there are more: e.g. "there are four admin notifications to review".

It can also prioritize errors and warnings, and deprioritize notices and info.

[joedolson]

Moving to future release, since there's been no movement during this cycle.