No screen reader announcements for upload image errors

[joedolson]

When an image upload fails, there should be a screen reader announcement to go along with the visible notice of the error.

Additionally, there should be a confirmation announcement for screen reader users when the error is dismissed.

See #60074.

The initial screen reader announcement should match the visible announcement, e.g. "filename.file has failed to upload". In my opinion, the additional reasons given are not very useful; the notification of failure is sufficient, and the user can explore to discover further information.

The dismiss button is in context, and could use aria-describedby for an explicit relationship with the notice being dismissed to provide confidence. The error message can simply be "Error dismissed".

There's no need to provide further detail on the error message being dismissed, because there is no action performed here *other* than the removal of a message; it's a non-breaking, non-critical action, which will happen automatically on leaving the page, anyway.

### Description

This PR adds screen reader announcements for upload image failures and dismiss interaction.

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

[rishavdutta]

Test Report

PR Tested:- ​https://github.com/WordPress/wordpress-develop/pull/8520

Test Environment [Playground]

• WordPress version: 6.8-beta2
• PHP Version: 7.4.31-dev
• Database version: 3.40.1
• Browser: Google Chrome
• OS: macOS

Test Results

• ✅After uploading some file in unsupported format, it shows the expected the error

Screen recording: ​https://drive.google.com/file/d/19QBOghEuS_Ywy4wb9eusNLeWCC97mA08/view?usp=drive_link

[yogeshbhutkar]

Thanks, @rishavdutta, for testing the patch!

However, this patch and the track ticket are specifically for Screen Reader announcements, not just the appearance of error messages. To properly test it, you’ll need to use a screen reader like VoiceOver (Mac) or NVDA (Windows). I'd really appreciate it if you could verify the announcements using a screen reader.

Edit:
Please test the announcements by trying to upload the images from the Add New Media Files tab.

[rishavdutta]

Replying to yogeshbhutkar:

Thanks, @rishavdutta, for testing the patch!

However, this patch and the track ticket are specifically for Screen Reader announcements, not just the appearance of error messages. To properly test it, you’ll need to use a screen reader like VoiceOver (Mac) or NVDA (Windows). I'd really appreciate it if you could verify the announcements using a screen reader.

Edit:
Please test the announcements by trying to upload the images from the Add New Media Files tab.

Hello @yogeshbhutkar,

Thanks for pointing it out 👍.

Test Report

PR Tested:- ​https://github.com/WordPress/wordpress-develop/pull/8520

Test Environment [Playground]

• WordPress version: 6.8-beta2
• PHP Version: 7.4.31-dev
• Database version: 3.40.1
• Browser: Google Chrome
• OS: macOS

Test Results

✅ In case of uploading some file in unsupported format from the Add Media File, the error message is visible, and it's accessible through screen reader (VoiceOver)
Screen Recording: ​https://drive.google.com/file/d/1V7r_gUeDXZFW3PBIrY5AZHGl_Bbg4lYw/view?usp=drive_link

🤔 ❌ In case of uploading some file in unsupported format from the Media Library, the error message is visible but the message is not accessible though screen reader. Also the error message is not the same that appears in the above scenario. The users can upload media in both ways, so the behavior should be consistent across the dashboard.
Screen Recording: ​https://drive.google.com/file/d/1UIM58RwiWyNa2IK5Q67Ppa3plITTYe9s/view?usp=drive_link

[yogeshbhutkar]

Replying to rishavdutta:

In case of uploading some file in unsupported format from the Media Library, the error message is visible but the message is not accessible though screen reader.

Yes, you're right! If you upload a file directly from the Media Library instead of navigating to Add Media File, VoiceOver doesn’t catch the error announcement. However, I can see it in the a11y HTML markup. This might be due to the focus shifting to the dismiss button. Introducing a slight delay in triggering the speak event should resolve the issue.

Edit: For this particular scenario, this behavior also exists on Trunk.

[yogeshbhutkar]

In case of uploading some file in unsupported format from the Media Library, the error message is visible but the message is not accessible though screen reader. Also the error message is not the same that appears in the above scenario. The users can upload media in both ways, so the behavior should be consistent across the dashboard.

I've updated the patch to address the issue described above. If any testers are available, could you please test and verify the fix?

cc: @rishavdutta

[navi161]

Thanks for reporting this issue @joedolson @rishavdutta and thanks for fixing this @yogeshbhutkar!

Further splitting the above reported issue into two parts:

1. The one where the Screenreader isn't working - This is partially fixed. The error is read by the Screenreader now however it reads the same error message thrice. More details below.

Test Report

This report validates that the indicated patch addresses the issue.

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

Environment

• OS: macOS Sonoma 14.6.1
• Web Server: PHP.wasm
• PHP: 7.4.31-dev
• WordPress: 6.8-beta3-20250321.090836
• Browser: Chrome 134
• Theme: Twenty Twenty Five
• Active Plugins: NA

Actual Results

• ❌ Issue partially resolved with patch.

Video attached

2. The other where the error is different for the same use case of uploading an unsupported file format from Media Library and Add Media - This is still seen. Not sure if this is fixed as part of this. Should we split it into a separate ticket as this seems to be a non A11y issue?

Steps to reproduce:

1. Go to Media > Library > Upload a file with unsupported format > observe the error text copy
2. Go to Media > Add Media File > Upload a file with unsupported format > observe the error text copy

Expected Result: Error text copy in both 1 and 2 should be the same
Actual Result: Error text copy is different

Screens and videos attached.

[yogeshbhutkar]

Thanks, @navi161, for testing the PR!

The error is read by the Screenreader now however it reads the same error message thrice.

Playground has a known bug where speak runs multiple times, but it executes only once when used outside the playground environment (this can be verified by running the PR locally).
See: ​https://github.com/WordPress/wordpress-develop/pull/7944#issuecomment-2673977787
Related: https://core.trac.wordpress.org/ticket/62550

The other where the error is different for the same use case of uploading an unsupported file format from Media Library and Add Media - This is still seen. Not sure if this is fixed as part of this. Should we split it into a separate ticket as this seems to be a non A11y issue?

As mentioned, this issue is specifically about adding speak events for upload errors. Right now, the speak events correctly reflect the displayed errors. If there's a decision to standardize these errors across pages, that should be tackled separately.

[joedolson]

Re-tested and ready for commit.

[joedolson]

In 60263:

Media: Screen reader improvements for upload media errors.

Add a screen reader announcement when a media upload fails. Also add an announcement when dismissing upload errors, and improve the labeling context of the dismiss error button to explicitly identify which error will be dismissed.

Props joedolson, navi161, yogeshbhutkar, rishavdutta.
Fixes #63114.

[sabernhardt]

Did you intend to have esc_js() run on the filename and then the full $speak_message, or should it only escape the full message? (It did not make a difference with the .diff file I tried uploading.)

[joedolson]

I left it because I didn't consider it likely it would make a difference; it's certainly not necessary, but I don't think it's harmful.

Follow up to r60263.

The original commit uses esc_js() within a <script> tag rather than wp_json_encode(). Per the docs, the esc_js() function is ​intended to be used within inline script handlers, onclick="thing", rather than within JavaScript tags.

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

[peterwilsoncc]

@joedolson Sorry, I missed that this was been worked on.

The esc_js() function in [60263] ought to be wp_json_encode() as the former is for inline script handlers and includes escaping for HTML attributes along with escaping for JS.

I've put together a ​pull request to replace the escaping.

Thanks Joe, I'll get this committed. This is the before and after for a file with an & in voice over.

Before	After

[peterwilsoncc]

In 60520:

Media: Modify escaping used for upload image announcements.

Replaces esc_js() with wp_json_encode() for escaping the screen reader announcement when a media upload fails. As the code is within a <script> tag rather than an inline script handler, the esc_js() function would cause special characters to be announced in their HTML encoded form rather than as the character, eg & would be announced as &.

Follow up to [60263].

Props peterwilsoncc, joedolson.
Fixes #63114.