Shiny Updates: error messages with HTML and wp.a11y.speak()

[afercia]

With the new Shiny Updates, some error messages dispatched to the aria-live regions may contain HTML, e.g. links. For example:

Installation failed: An unexpected error occurred. Something may be wrong with WordPress.org or this server&#8217;s configuration. If you continue to have problems, please try the <a href="https://wordpress.org/support/">support forums</a>.

Though the message gets inserted in the aria live region as a text string, and thus it should be safe, having screen readers read out "less than ... href equal http slash slash etc. ... greater than support forums ..." or something like that is far from ideal:

Ideally, any HTML should be stripped out from the message string as already done in a couple of cases in updates.js for example $( '<p />' ).html( message ).text().
See also #35191.

Side note: I'm not so sure error messages returned in a response should contain HTML in the first place. I can understand that, historically, they were meant to be injected as HTML, for example in the notices on top of the screen. But now that these messages are going to be used in different places and for different purposes maybe it's time to re-think them since there's the need to distinguish when a message is "plain text" or "rich text with HTML" (or maybe provide both versions in the response?).

[swissspidy]

Yay, another Shiny Updates bug! :-)

I think we should strip the HTML for the aria-live region and think about dealing with those scenarios differently in a future release.

The An unexpected error occurred. … error string is part of a number of files and often gets displayed using trigger_error(), but sometimes is passed as a WP_Error object. We need to better understand why it currently is like that.

[afercia]

Replying to swissspidy:

I think we should strip the HTML for the aria-live region and think about dealing with those scenarios differently in a future release.

+1

[adamsilverstein]

@afercia I started working on a patch replacing all out errorMessage passing to wp.speak to convert HTML to text as you suggested.

I also thought that perhaps this functionality should be in wp.speak itself - would there ever be a use case where passing HTML into wp.speak would be useful? Perhaps for speaking out a code snippet?

[adamsilverstein]

In 37382.diff​: ensure all errorMessage use for wp.speak is stripped of HTML.

37382.2.diff​ is an alternate approach that strips HTML from any string passed to wp.wpeak

[afercia]

Replying to adamsilverstein:
@adamsilverstein hi. Thanks for having a look into this.

I also thought that perhaps this functionality should be in wp.speak itself

Yep, I've considered this option, and while it would resolve the technical issue in an efficient way, it wouldn't guarantee that the messages passed to wp.speak.a11y() should preferably be short and meaningful. Ideally, messages for wp.speak.a11y() should be carefully crafted case by case and we shouldn't assume already existing messages fit this specific use case.

would there ever be a use case where passing HTML into wp.speak would be useful? Perhaps for speaking out a code snippet?

Hm difficult to say but probably very unlikely.

[swissspidy]

@adamsilverstein hi. Thanks for having a look into this.

I also thought that perhaps this functionality should be in wp.speak itself

Yep, I've considered this option, and while it would resolve the technical issue in an efficient way, it wouldn't guarantee that the messages passed to wp.speak.a11y() should preferably be short and meaningful. Ideally, messages for wp.speak.a11y() should be carefully crafted case by case and we shouldn't assume already existing messages fit this specific use case.

True, but definitely something for a new ticket :-)

would there ever be a use case where passing HTML into wp.speak would be useful? Perhaps for speaking out a code snippet?

Hm difficult to say but probably very unlikely.

That would probably be against the "short and meaningful" rule of thumb. Therefore 37382.2.diff​ seems preferable.

[afercia]

Replying to swissspidy:

37382.2.diff​ seems preferable.

Makes sense :) and seems to be the most efficient solution since it solves the issue also in other admin screens. See for example the Import screen in the screenshot below, no more HTML in the aria live message. Notice also the multiple... notices on top of the page, probably something to consider in a separate ticket.

[afercia]

In 38115:

Accessibility: Ensure only text is sent to aria-live messages.

While messages passed to wp.speak.a11y() should preferably be meaningful,
short, and carefully crafted case by case, this will ensure any HTML tags will
be stripped out from the message string.

Props adamsilverstein.
Fixes #37382.