Add prefixes to all admin notices (Warning, Error, Success, Info)

[kebbet]

This is a continuation #47656

From @afercia comment (ticket:47656#comment:47)

• Make sure all the Error and Warning notices use respectively an "Error:" and "Warning:" text prefix
• Further discuss whether also the "Success" and "Info" notices should use a similar text prefix
• Update documentation related to admin notices, for example: ​https://codex.wordpress.org/Plugin_API/Action_Reference/admin_notices and ​https://developer.wordpress.org/reference/hooks/admin_notices/
• Create a new issue on the Gutenberg GitHub to add text prefixes for the editor notices: right now, none of them uses a prefix (see screenshot below)

I would like to add

• Combine strings constructed like __('Error:') . __('any string') into one string for better context for translators.

[apedog]

I understand the reasoning behind having mandatory Error and Warning prefixes. I don't hold an opinion either way - but I understand why it can be considered beneficial. It might not be pretty. It might be redundant for some messages (eg. strings that already contain the word 'error' in them) but they're a good marker/label for those notices. Good for accessibility. They grab attention regardless of coloring scheme. And they're unambiguous.

However mandatory 'Info' and 'Success' prefixes would just be annoying.

Adding the word 'Info' to what is already an information string does not add any new information. It's already information. It's not only redundant it's stupid.

The only difference between Info and Success notices is that Success notices accompany an action while Info notices are passive notices. There is no real accessibility need (none that I know or can think of) to disambiguate them from Info notices. Not in the way that Error and Warning need to stand out.

-1 for adding mandatory 'Info' and 'Success' prefixes.

[joedolson]

With the addition of the new admin notice functions, this can be handled much more easily. Slating to look at in 6.5. Pinging @costdev for awareness.

[costdev]

Thanks for the ping @joedolson!

To what extent should we consider extenders who may make use of these functions in 6.4?

• If they already prefix their notices with an appropriate or preferred string, forcing Core's own may be akin to a regression/BC break/inconvenience.
• For extenders who transfer to the new functions, they may use the same (translated) strings they previously used with hardcoded HTML. If those strings already contain a prefix and the extender feels they should now remove their prefix as Core enforces one, their translations will also need to be updated.
• Checking for existing prefixes is likely to be unreliable and an unnecessary (albeit, tiny) performance hit.
• Core could instead enforce its own rule for prefixing $message parameters passed in Core.
• The previous point is the reason why I didn't suggest adding a (string) $prefix key to $args.

To be clear though, I personally like the idea of abstracting this to wp_get_admin_notice(). The functions were created to benefit exactly this type of ticket. There are unlikely to be many notices requiring translation in the first place, and the markup is filterable if someone really doesn't like them.

I mentioned the above points because I think our thoughts about at least some of these should be documented on this ticket.

---

Regarding whether to prefix all notice types:

IMO, it's good for users to get the context of the notice right away - That's why we use colours. As these can't be utilized by all users, the prefixes should increase accessibility, and that's the main reason I think prefixing all notice types makes sense.

---

Combine strings constructed like __('Error:') . __('any string') into one string for better context for translators

This is where the use of the functions becomes problematic. The combined strings would be provided via the $message parameter, and therefore couldn't be standardized within the function. Thoughts @joedolson? How important do you think this addition is @kebbet?

[joedolson]

One reason for addressing this quickly is to reduce the impact of extender implementation. Most extenders won't take this up immediately, I suspect - for plugin authors, it's rare to only support the latest release, so the labor to start using this heavily won't be common right away. So I think we can make reasonable use of this if we implement it early and provide a good dev note - the changes any extender would need to make will be text only, so they're relatively easy changes.

One thing we can consider is making the text more decorative, e.g. actual text present in association with the border, but presented in a way that it doesn't simply append as text. More of a label or flag on the panel. That makes the information more of an accessible version of the existing border indication, rather than an extension of the error text.

Adding needs-design to reflect that.

[costdev]

Great points @joedolson!

[joedolson]

Reading through the history of this issue, as reflected in #47656, I can see that there are a number of problems that should be taken into consideration. Design-wise, there's some back-compat issues with handling this outside of core, and a lot of text churn that could happen with changing all errors. In many cases, the context of an error or warning is fairly clear, but right now the distinction is only conveyed using color. Adding this as text is reasonable, but this might be a case where we can more easily handle this issue by adding an icon to indicate each state with accessible text.

What this avoids is 1) the need to modify the text of existing notices. 2) Fixes the color-only indicator problem, by providing cues through color, icon, and text (for screen readers.) The gap is a lack of text indication for sighted users who don't immediately understand the icon, but this information is all enhancing comprehension; the color and icon should never be critical to the message. If we have a message in a notice that leaves ambiguity, then that message should be updated.

I suggest using dashicons-no for errors, dashicons-warning, for warnings, dashicons-info, for info, and dashicons-yes for success.

Open to arguments against this, however.

[sabernhardt]

The dashicons-no icon looks very similar to the dismiss icon in admin notices. Would a red flag be a good (international) choice for error messages?

[joedolson]

Good call; we don't want people to start thinking there are two dismiss buttons.

[kebbet]

And a sidenote on prefixes: the swedish locale tends to remove the translations of success in many messages as there is no good translation for it. Adding Success as a prefix sound to me really unnecessary.

[joedolson]

It probably makes more sense to try and complete this after we've finished extending usage of the admin notice functions globally. We didn't get that finished in 6.5, so I think this is best punted. However, I'm going to milestone it for 6.6, since I think that's pretty plausible.

[mukesh27]

@joedolson Does this ticket in your radar for 6.6?

[joedolson]

Yes, I was looking at it last Friday, but I'm still on the fence on implementation.

[joedolson]

We have three options: 1) text and an icon; 2) icon with screen reader text or 3) icon without screen reader text.

The current notices only use color to indicate type: info, error, or success.

The goal is to make the type of notice more evident.

Adding visible text creates a large amount of labor for plugin authors and for core, as some existing notices will already contain the relevant text, e.g. "Error: your error message".

Adding screen reader text is less evident to authors, so it creates the same duplication only for screen reader users, and is less likely to be observed or fixed by extenders.

So the question is whether only adding an icon is acceptable. It improves on the existing model, which only uses color. In theory, the text of the message should always be clear enough to communicate the type of message, in which case adding screen reader text is redundant.

Do we consider this visual information to be supplemental, or informative? If it's supplemental, then we don't need screen reader text. If it's informative, we do.

From the accessibility bug scrub, we agreed that the icon should be considered informative, for consistency. This means that along with making this change, we'll also need to review the text of all core notices to potentially rewrite and remove any existing prefixes, and also provide sufficient time to extenders to be able to rewrite their own messages.

Punting to 6.7 and marking as early.

[alexstine]

I certainly agree this would be informative for all users. I think while a dev note could be added to instruct authors to remove the prefix, I assume it probably isn't super important. Couldn't we just do something like this?

<?php
$error_prefix = __( 'Error' );
$check_error_prefix = preg_match( '/^Error/', $admin_notice_content );
if ( $check_error_prefix === 1 ) {
return sprintf( '<span class="screen-reader-text">%s: </span>%s', $error_prefix, $admin_notice_content );
}

My PHP is a bit rusty but I think the meaning is understood.

Thanks.

[joedolson]

Thanks, @alexstine! To me, that code is excessively fragile, since there are other ways that an error might be clear; and it's even possible that a string could start with 'Error' without being an error message. I think that we're generally agreed, however, that what this needs is an icon with screen reader text to provide context; and given that the worst case scenario is a single word duplication, I'm not sure that it's super crucial to manage the screen reader text automatically.

With an agreed on design, I think this could move forward quite quickly.

[matthewmcvickar]

proposal for icons in admin notices; icons are dark gray

[matthewmcvickar]

proposal for icons in admin notices; icons are in color, shared with the bar on the left of the admin notice

[matthewmcvickar]

proposal for icons in admin notices; icons are in color and are a larger size (20px) than the default (16px)

[matthewmcvickar]

proposal for icons in admin notices; icons are dark gray and a larger size (20px) than the default (16px)

[matthewmcvickar]

proposal for icons in admin notices; alternate icon for the warning icon (bell instead of circled exclamation point)

[matthewmcvickar]

proposal for icons in admin notices; alternate icon for the information icon (outlined lowercase letter i in circle instead of lowercase letter i in filled-in circle)

[matthewmcvickar]

proposal for icons in admin notices; alternate icon for the info icon (paperclip instead of circled lowercase letter i)

[matthewmcvickar]

First off, I apologize for spamming seven different image posts to this thread! I didn't know how to upload multiple images to be included in a single comment.

I have picked up this ticket to work on at WordCamp US 2024 in Portland, Oregon.

I have mocked this up in a number of variations, all included above. At the risk of introducing too many options, there are a number of variations on icon, icon size, and icon color.

I find the icons to be hard to discern, especially when in color, at the default 16px size. I think they are more legible—and therefore more accessible—at size 20px.

I prefer the bell icon to the circled exclamation point for the warning icon; I find it more interesting and universal than the circled punctuation.

I prefer the paperclip to the encircled lowercase letter i for the info icon. I think the paperclip is more universal than the letter, but I also see how it could be mistaken for something to do with links or attachments.

I have also begun writing the code to implement this in CSS and will start a PR shortly.

[matthewmcvickar]

proposal for icons in admin notices; lots of content in a notice, and text is not idented

[matthewmcvickar]

proposal for icons in admin notices; lots of content in a notice, and text is indented

[matthewmcvickar]

There may sometimes be a lot of content in an admin notice. In this case, I think it looks better to indent the content after the icon rather than wrap it around the icon. See the two images attached before this comment for examples of both.

[apedog]

If universality is a goal:

• Warning should be an exclamation mark in a yellow triangle. That's pretty much the universal warning icon.
• Bell icon simply means Notification/Reminder (usually marking in a folded Notifications tab). It doesn't carry the meaning of Warning.
• Flag does not carry the meaning Error. (An X, a cicle-strike-through, etc.)

(IMHO. But also - universally speaking..)

[joedolson]

Thanks @matthewmcvickar and @apedog! Regarding the warning icon: there is no icon of that description in the WordPress icon choices; the symbol used for warning throughout WordPress is the exclamation point, with no triangle. I don't think we'll introduce a new icon for this purpose.

@matthewmcvickar I think that we should still avoid the ambiguity between the 'i' icon and the '!' icon, and using the paperclip for information makes sense to me.

@apedog There was a specific reason we didn't use the 'x' icons for errors, which is because it creates ambiguity with the existing 'close' icons on dismissible notices and throughout the WordPress admin. We don't want to create an issue where people are clicking on this icon to close the notice.

Overall, I like https://core.trac.wordpress.org/attachment/ticket/50442/proposed-admin-notices-icons-indented-text.png, and would like to see a patch for that with the icon change mentioned above.

[apedog]

Replying to joedolson:

Regarding the warning icon: there is no icon of that description in the WordPress icon choices .. I don't think we'll introduce a new icon for this purpose.

There are yellow-bordered .notice-warning notices.
(or did you mean the icons must be limited to the frozen/archived dashicon set?)

There was a specific reason we didn't use the 'x' icons for errors, which is because it creates ambiguity with the existing 'close' icons on dismissible notices.

Yes. That's obvious.
A circle with a strike-through is the next best "universal" then.
That one has the disadvantage of being mostly white/transparent - as opposed to the other "bullet" icons. It has the advantage of not being a flag (which is a neutral-ish icon).

[davidbaumwald]

@joedolson Is it still feasible to include this in 6.7 Beta 1? With this being tagged early, still needing work, and the Beta releasing in a few hours, I'd defer to you on keeping this in the milestone or moving to 6.8.

[joedolson]

@davidbaumwald No; this needs to be punted. It's had good progress, but needs some final design decisions and a patch, and that's not going to happen in time.

[joedolson]

Gutenberg has introduced a badge component with equivalent icons; they settled on Check, Information, Circled Exclamation, and Triangle Exclamation (see ​https://github.com/WordPress/gutenberg/pull/66555#issuecomment-2511544769)

In the interest of consistency, this should do the same.

@jameskoster Can you confirm that those icons are the final choices used?

[jameskoster]

@joedolson that's correct. The Badge component (and the icons) can be viewed on Storybook: ​https://wordpress.github.io/gutenberg/?path=/docs/components-badge--docs

(Edit: fixed URL to badge component)

[matthewmcvickar]

@joedolson @jameskoster These look good. Since these icons are only part of Gutenberg and not part of the Dashicons set, though, how should they be integrated into the WP Admin?

I do think the i and ! are not very distinguishable in the example, but I'm willing to punt on that for now in the interest of moving this forward.

[karmatosed]

I would say this has design but I also would like to note the following point raised by others:

• The info icon seems to be doing double duty. I would also expect a warning icon for that case as otherwise the only difference is color and that feels not a great accessibility point unless I am mistaken.

I will however remove the 'needs design' as it certainly has that and it now has feedback also. Thank you everyone.

[joedolson]

@karmatosed Per the above comments, we're actually moving to use the ​same icons used in Gutenberg, so that issue is already resolved. Thanks for noting, however!

A draft PR for 50442.

Getting the SVGs as images is probably not a good path, because it prevents us from defining color via CSS. Might just want a rendering function to print the SVG into the code. However, SVG isn't permitted by wp_kses_post(), so may need to address related ticket first. (See ticket.)

Trac ticket: https://core.trac.wordpress.org/ticket/50442

[joedolson]

Started a draft PR to start moving this forward; but I think we may need to resolve #62619, first.

[joedolson]

Given where this is, and the complexity of integrating this with all the admin notices across core to make sure the design works globally, this is going to need to be punted to 6.9. Hopefully @matthewmcvickar will have some more time available to keep working on it with less time pressure!