WordPress.org

Make WordPress Core

Opened 8 months ago

Last modified 2 months ago

#47120 assigned defect (bug)

Media modals: Upload errors and field information are not associated with their control

Reported by: afercia Owned by: antpb
Milestone: 5.4 Priority: normal
Severity: normal Version:
Component: Media Keywords: wpcampus-report needs-patch early
Focuses: ui, accessibility Cc:
PR Number:

Description

Moved from the WPCampus accessibility report issues on GitHub, see https://github.com/WordPress/gutenberg/issues/15302

Errors and field information are not associated with their control

  • Severity: High
  • Affected Populations:
    • Blind
    • Low-Vision
    • Cognitively Impaired
  • Platform(s):
    • Windows - Screen Reader
    • Windows - ZoomText
    • Mac - VoiceOver
    • Android - TalkBack
    • iOS - VoiceOver
  • Components affected:
    • Media Dialog

#### Issue description

When users attempt to upload an image in the "Featured Image" modal
dialog, and the image is too large, an error message appears visibly.
However blind and low-vision users are not alerted with the
announcement, and focus remains on the upload button (except in Edge
browser, where focus goes back to the top of the page after a failed
upload).

The 2MB limit is also not programmatically associated with the "Select
Files" button, so blind and low-vision users may miss that limit unless
they happen to navigate past the button in exploration of the whole
modal.

Users who are zoomed-in or using magnification software may not see the
error as it may be outside their viewports. Screen reader users remain
on the "Select Files" button and need to navigate around to see if
there are any errors or if the upload was successful.

[![Screenshot of the error message and the 2MB limit informative
text](/images/17718_feature_image_bigly_yuge.png)]{.image-wrap}

##### Issue Code

    <button type="button" class="browser button button-hero" id="__wp-uploader-id-4" style="display: inline-block; position: relative; z-index: 1;">Select Files</button>


    ...


    <div class="upload-errors">


        <div class="upload-error">


            <span class="upload-error-filename">trump.gif</span>


            <span class="upload-error-message">trump.gif exceeds the maximum upload size for this site.</span>


        </div>


    </div>


    ...


    <div class="post-upload-ui">


        <p class="max-upload-size">Maximum upload file size: 2 MB.</p>


    </div>

#### Remediation Guidance

Put role=alert on the error, and on any additional error or success
messages that are added as users upload media. This will allow screen
reader users to know immediately that there is an error.

Consider moving focus to either the error container or the error
container close button when the error appears. This will ensure that
Braille-only and screen magnification users are alerted that an error
has occurred.

Normally, moving focus to errors like this is not advised, however
currently the error and the informative text are visually far away from
the "Select Files" button, and neither Braille nor screen
magnification software announce status messages. A better solution is to
change the design to bring the error visually directly under the
"Select Files" button (while still also using a live region on the
error message).

Programmatically associate the informative text ("max 2MB size") with
the "Select Files" button using aria-labelledby. Do this by giving
the informative text container an id value and set this in order in
an aria-labelledby attribute on the "Select Files" button. Include
the button's own id token in the aria-labellebdy so that the
button's text isn't overridden.

##### Recommended Code

    <button type="button" class="..." aria-labelledby="__wp-uploader-id-4 post-upload-info" id="__wp-uploader-id-4" style="...">Select Files</button>


    ...


    <button type="button" class="...">


        <span class="screen-reader-text">Dismiss Errors</span>


    </button>


    ...


    <div class="upload-errors">


        <div class="upload-error" role="alert">


            <h3 class="...">trump.gif</h3>


            <p class="...">trump.gif exceeds the maximum upload size for this site.</p>


        </div>


    </div>


    ...


    <div class="post-upload-ui" id="post-upload-info">


        <p class="max-upload-size">Maximum upload file size: 2 MB.</p>


    </div>

#### Relevant standards

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by [Tenon](https://www.tenon.io) and funded by [WP Campus](https://wpcampus.org/). This issue is GUT-60 in Tenon's report

Attachments (2)

47120.png (124.4 KB) - added by afercia 6 months ago.
47120-2.png (166.5 KB) - added by afercia 6 months ago.

Download all attachments as: .zip

Change History (27)

#1 @afercia
8 months ago

Note: this applies to all the media views when uploading attachments and upload errors are displayed, usually because of (and can be tested with):

  • file size exceeding upload limit
  • dangerous file extension (e.g. .exe)
  • file with no extension
  • empty file

#2 @afercia
7 months ago

  • Milestone changed from Future Release to 5.3

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


6 months ago

#4 @anevins
6 months ago

@afercia We still need to figure out where to move the focus. The remediation says "moving focus to errors", but at the same time it can be a bit unhelpful to move the focus to a containing DIV that lacks information. Do we move the focus to the element with the Alert role?

#5 @afercia
6 months ago

@anevins thanks for the ping.

For the announcement, I think it's OK to use role=alert or, better, wp.a11y.speak() with the assertive parameter, which is equivalent to an alert.

For the focus part, I think the remediation actually says the preferred solution would be bringing the error message "in view" close to the "Select Files" button. Re-reading:

Consider moving focus to either the error container or the error container close button when the error appears. This will ensure that Braille-only and screen magnification users are alerted that an error has occurred.

Normally, moving focus to errors like this is not advised, however currently the error and the informative text are visually far away from the "Select Files" button, and neither Braille nor screen magnification software announce status messages.

A better solution is to change the design to bring the error visually directly under the "Select Files" button (while still also using a live region on the error message).

Ideally, I'd recommend to change the design. Alternatively, move focus but I wouldn't move it to the alert or to a DIV. An example can be seen here: https://www.tenon-ui.info/forms-full-demo

  • submit the form leaving all fields empty
  • focus is moved to the top, to a h2 heading with meaningful text

#6 @anevins
6 months ago

@afercia I'm not sure I understand. The Focus will still need to happen won't it? Because people will be left on the form's submission button and will have to navigate backwards to get to the form field in question. Is navigating backwards okay? I'm asking genuinely.

@afercia
6 months ago

#7 @anevins
6 months ago

Gotcha

@afercia
6 months ago

#8 @afercia
6 months ago

I've uploaded the image from the WPCampus complete technical report PDF document (329 pages) and one more image for clarification, as I think the image from the report identifies only one of the possible cases.

It's important to note that the media uploader behavior actually differs depending on the error type, for example:

  • file exceeding allowed size or file with no extension: the error is displayed inline below the "Select Files" button (first image)
  • empty file: the modal switches to the media grid and the error is displayed in the sidebar (second image)

This makes things a bit more complicated.

Regardless, in this case there's no text input field nor form submission. There's a "Select Files" button. In any case the error message should be displayed underneath the button otherwise it may be outside the viewport for some users or difficult to find for other users e.g. Braille-only users.

Note: When in doubt, please refer to the WPCampus complete report, as some details may have been list when moving issues from GitHub to Trac. The PDF is published on the WPCampus web site.

This ticket was mentioned in Slack in #core-media by anevins. View the logs.


4 months ago

#10 @anevins
4 months ago

Hi @afercia We've mentioned this in the Media meeting and struggled to define a set of actions we need to take when assigning this to someone to own. Would you be able to help with this? Thanks!

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


4 months ago

#12 @joedolson
4 months ago

If you need help with guidance, I can also provide some help here. I'll track the ticket for questions; I can't easily make the media team meetings, however.

#13 @afercia
4 months ago

I would try to investigate:

  • why the modal needs to switch view to display some errors in the sidebar: any technical reason for this?
  • ideally, the view shouldn't change
  • the error should just appear "in place", as close as possible to the "Select Files" button

Re-reading the essential parts of the remediation suggested from the WPCampus report:

Normally, moving focus to errors like this is not advised, however currently the error and the informative text are visually far away from the "Select Files" button, and neither Braille nor screen magnification software announce status messages.

A better solution is to change the design to bring the error visually directly under the "Select Files" button (while still also using a live region on the error message).

This ticket was mentioned in Slack in #core-media by anevins. View the logs.


4 months ago

This ticket was mentioned in Slack in #core-media by anevins. View the logs.


3 months ago

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


3 months ago

#17 @audrasjb
3 months ago

  • Keywords needs-patch added

@mikeschroder does the core media team need some input from accessibility side?
It would be nice to have an owner from the Core media team here. Thanks :)

This ticket was mentioned in Slack in #core-media by mike. View the logs.


3 months ago

#19 @antpb
3 months ago

  • Owner set to antpb
  • Status changed from new to assigned

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


3 months ago

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


3 months ago

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


3 months ago

#23 @mikeschroder
2 months ago

Just wanted to check in!

@antpb: Do you want any more input or help with this one?

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


2 months ago

#25 @audrasjb
2 months ago

  • Keywords early added
  • Milestone changed from 5.3 to 5.4

Hi,

5.3 beta 3 is on Monday, and this ticket doesn't have any patch for the moment.
Since it will probably deserves some testing before commit, I don't think it's realistic to get this fixed in 5.3.

Moving the ticket to 5.4 early so it could be fixed on time for 5.4.

Note: See TracTickets for help on using tickets.