Make WordPress Core

Opened 4 months ago

Closed 6 weeks ago

Last modified 6 weeks ago

#63114 closed defect (bug) (fixed)

No screen reader announcements for upload image errors

Reported by: joedolson's profile joedolson Owned by: joedolson's profile joedolson
Milestone: 6.9 Priority: normal
Severity: normal Version:
Component: Media Keywords: has-patch has-test-info commit
Focuses: accessibility Cc:

Description

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.

Attachments (4)

library_fix.mov (1.5 MB) - added by navi161 4 months ago.
add_media_textcopy.png (386.1 KB) - added by navi161 4 months ago.
add_media_textcopy.2.png (386.1 KB) - added by navi161 4 months ago.
library_textcopy.png (395.4 KB) - added by navi161 4 months ago.

Change History (21)

#1 @joedolson
4 months ago

  • Owner set to joedolson
  • Status changed from new to accepted

This ticket was mentioned in PR #8520 on WordPress/wordpress-develop by @yogeshbhutkar.


4 months ago
#2

  • Keywords has-patch added; needs-patch removed

### Description

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

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

#3 @rishavdutta
4 months ago

  • Keywords has-testing-info added

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

#4 follow-up: @yogeshbhutkar
4 months ago

  • Keywords needs-testing added; has-testing-info removed

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.

Last edited 4 months ago by yogeshbhutkar (previous) (diff)

#5 in reply to: ↑ 4 ; follow-up: @rishavdutta
4 months ago

  • Keywords has-testing-info added; needs-testing removed

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

Last edited 4 months ago by rishavdutta (previous) (diff)

#6 in reply to: ↑ 5 @yogeshbhutkar
4 months ago

  • Keywords needs-refresh added

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.

Last edited 4 months ago by yogeshbhutkar (previous) (diff)

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


4 months ago

#8 @joedolson
4 months ago

  • Milestone changed from Awaiting Review to 6.9

#9 @yogeshbhutkar
4 months ago

  • Keywords needs-testing added; needs-refresh removed

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

#10 @navi161
4 months ago

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

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

@navi161
4 months ago

#11 @yogeshbhutkar
4 months ago

  • Keywords needs-testing removed

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.

#12 @wordpressdotorg
2 months ago

  • Keywords has-test-info added; has-testing-info removed

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


8 weeks ago

#14 @joedolson
6 weeks ago

  • Keywords commit added

Re-tested and ready for commit.

#15 @joedolson
6 weeks ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

#16 @sabernhardt
6 weeks ago

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

#17 @joedolson
6 weeks ago

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.

Note: See TracTickets for help on using tickets.