WordPress.org

Make WordPress Core

Opened 16 months ago

Closed 5 months ago

#47611 closed defect (bug) (fixed)

Media views: hide the "file upload button" from assistive technologies

Reported by: afercia Owned by: afercia
Milestone: 5.5 Priority: normal
Severity: normal Version:
Component: Media Keywords: has-screenshots has-patch commit
Focuses: accessibility, javascript Cc:

Description

Noticed while working on #47145, which proposes to make the media modal a real ARIA modal dialog.

When navigating content within the media modal using the keyboard (with or without a screen reader running), at some point there's a tab stop at the bottom of the modal content. Screen readers announce "file upload button", see attached screenshot.

This button is the one that gets used to upload attachments and should be perceivable only in the "Upload FIles" tab. Instead, it's always perceivable and focusable in all the various media views.

A tab stop on an invisible control is confusing for keyboard users. Screen readers users will be confused as well, as this button is announced also in work flows that don't relate at all with file uploading.

I'd like to propose to find a way to hide this button from assistive technologies when it's not supposed to be used, making sure its functionality is preserved.

Attachments (4)

media modal file upload button.jpg (116.8 KB) - added by afercia 16 months ago.
47611.diff (364 bytes) - added by audrasjb 11 months ago.
Hide moxie-shim container and input via CSS
47611.1.diff (426 bytes) - added by azaozz 9 months ago.
47611.2.diff (2.0 KB) - added by afercia 5 months ago.

Download all attachments as: .zip

Change History (42)

#1 @afercia
16 months ago

Note: if I remember correctly this issue was solved at some point in a previous release cycle, but I couldn't find a reference. Just to note that's likely a regression.

#2 @afercia
14 months ago

Similar issue: #47144

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


14 months ago

#4 @joemcgill
14 months ago

+1 on making this less confusing for those using assistive technology. @afercia is this only happening in the editor context, or also in the media library? If the former, it might be a regression that was introduced when the media modal was implemented in the new editor.

#5 @afercia
14 months ago

@joemcgill happens also in Classic Editor.

It's an <input type="file" ... with a CSS class moxie-shim moxie-shim-html5.

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


14 months ago

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


14 months ago

#8 @joedolson
14 months ago

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

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


13 months ago

#10 @audrasjb
13 months ago

  • Milestone changed from 5.3 to Future Release

This ticket still needs some work and improvements.
Moving it to Future release.

Feel free to ask for reintegration in 5.3 if a patch is available in the next few days.

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


13 months ago

#12 @afercia
13 months ago

  • Milestone changed from Future Release to 5.3.1

Discussed during today's accessibility bug-scrub: agreed this ticket seems a quick fix as it would likely need the element to be hidden via CSS. Milestoning for next minor release. See related #47144.

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


11 months ago

@audrasjb
11 months ago

Hide moxie-shim container and input via CSS

#14 @audrasjb
11 months ago

  • Keywords has-patch dev-feedback added

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


11 months ago

#16 @audrasjb
11 months ago

Hi there,

@afercia @joedolson this one should be committed as soon as possible if we are all ok with the current patch.
Do you have time to review and commit it?

Otherwise, we could punt it to 5.4, so no emergency (just need to know if it can land in 5.3.1 this week).
Indeed, it's a regression, but not a regression from WP 5.3.

Cheers,
Jb

Last edited 11 months ago by audrasjb (previous) (diff)

#17 @azaozz
11 months ago

  • Keywords needs-testing added

Has this been tested in "all" recent browsers? If I remember correctly there are some security restrictions in the browsers preventing the use of "hidden" <input type="file"> elements, especially from JS.

#18 follow-up: @audrasjb
11 months ago

@azaozz I tested it on Firefox, Chrome and Safari, but I'm not sure I understand your point. The field is already hidden, we just need to hide it from assistive technologies.

(in any case, I think this ticket is going to be moved to 5.4)

#19 @audrasjb
11 months ago

  • Milestone changed from 5.3.1 to 5.4

Moving this ticket to milestone 5.4.

#20 in reply to: ↑ 18 @azaozz
11 months ago

Replying to audrasjb:

The field is already hidden, we just need to hide it from assistive technologies.

"Technically" it's not hidden, it is "off-screen". Current code:

<div
    id="html5_1drm54kle1qkop61h77ia9j53_container"
    class="moxie-shim moxie-shim-html5"
    style="position: absolute; top: 0px; left: 0px; width: 0px; height: 0px; overflow: hidden; z-index: 0;"
>
<input
    id="html5_1drm54kle1qkop61h77ia9j53"
    type="file"
    style="font-size: 999px; opacity: 0; position: absolute; top: 0px; left: 0px; width: 100%; height: 100%;"
    multiple=""
...

Note the position: absolute; top: 0px; left: 0px; width: 100%; height: 100%; which I think is needed for drag/drop upload to work.

Looks like hiding it from assistive technologies may not be as easy as adding display: none !important. But yes, lets look there during 5.4 :)

Last edited 11 months ago by azaozz (previous) (diff)

#21 @afercia
11 months ago

  • Keywords needs-testing removed

Yep, I don't think this input can be hidden via CSS. On #30392 / [31117] we made some work to move this input out from the "tabbable" elements within the media modal dialog thus this input can't be tabbed to.

The problem is that it still can be navigated to when arrowing with a screen reader as well as when using other navigation tools screen readers provide.

Since it's already non-tabbable, there's just the need to hide it from assistive technologies. It is already meant to be visually hidden thus it should be non-visible for all users. I guess an aria-hidden="true" would work. Unfortunately, as far as I see, this input is injected with innerHTML and not exposed in the mOxie object so I can't think of a non-hackish way to add a HTML attribute to it.

Worth noting that the WordPress moxie.js file is pretty out of date. For example, on the upstream latest version a tabindex="-1" attribute was added to this input 2 years and a half ago. See https://github.com/moxiecode/moxie/commit/d2e3bfdf8fbf5e1674fae09db445af811ae36c61

I guess a good first step would be updating the WordPress moxie.js file to its latest version. This should happen early in the 5.4 release cycle.

Before that though, I'd suggest to ask the Ephox team to add aria-hidden="true". Fixing this issue upstream seems to me the most reliable way to make this input not perceivable to all users.

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


9 months ago

#24 @afercia
9 months ago

Pinging @azaozz for his expertise with moxie-related things :)

#25 @azaozz
9 months ago

updating the WordPress moxie.js file to its latest version.

That's not possible, the license for the newer versions has changed and is not compatible. See #48277.

Looking a bit more there and trying to figure out why this is needed. Seems it was added (years ago) to support use of Flash for the "select files" button. The div.moxie-shim is positioned where the "Select Files" button is (when going to the media modal => upload), but doesn't seem to make difference for HTML 5.0.

Seems it may need a bit more testing in "obscure browsers", but setting it to display: none doesn't seem to break it for the HTML 5.0 "runtime". The patch should probably use div.moxie-shim.moxie-shim-html5 to target it specifically.

@azaozz
9 months ago

#26 @azaozz
9 months ago

In 47611.1.diff: almost the same as 47611.diff but it hides the wrapper and the input field only when the html5 runtime in Moxie.js is used.

Seems to work properly here in Chromium and Firefox, needs testing in other/older browsers.

Last edited 9 months ago by azaozz (previous) (diff)

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


9 months ago

#28 @audrasjb
8 months ago

Hi there,

With Beta 3 approaching, we'll need a decision and a commit action very soon.
For Component maintainers: if you don't feel the current patch is ready to land in WP 5.4 in the next few day, it's could be better to move it to 5.5. We're leaving it in the milestone for now.

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


8 months ago

#30 @afercia
8 months ago

Seems to work properly here in Chromium and Firefox, needs testing in other/older browsers.

Tested on macOS Safari with and without VoiceOver. Tested on Windows:

  • Firefox with and without NVDA
  • Chrome with and without NVDA
  • IE 11

Works as expected. The "Select files" button is operable with mouse and keyboard. Screen readers don't announce the hidden input file any longer.

Can't test on mobile, Edge, or other "exotic" browsers.

#31 @SergeyBiryukov
8 months ago

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

In 47375:

Accessibility: Media: Hide the invisible "file upload button" on media views from assistive technologies.

The button is visually hidden, but was announced by screen readers in workflows unrelated to file uploading, leading to confusion.

Props afercia, audrasjb, azaozz.
Fixes #47611.

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


7 months ago

#33 @afercia
7 months ago

  • Keywords needs-patch added; has-patch removed
  • Milestone changed from 5.4 to 5.5
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening. See ticket:49753#comment:37

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


6 months ago

#36 @afercia
6 months ago

  • Owner changed from anevins to afercia
  • Status changed from reopened to assigned

@afercia
5 months ago

#37 @afercia
5 months ago

  • Keywords has-patch commit added; dev-feedback needs-patch removed

47611.2.diff hides the "shim" input file from assistive technologies by adding aria-hidden="true" and tabindex="-1" attributes. In the context of the media modal dialog, tabbing is already constrained within the modal so it's not possible to tab to the input file. I added the negative tabindex just in case.

I couldn't find a way to get this input field with a Plupload method, as it seems Plupload doesn't expose anything to reference this element. Thus, I opted to use a jQuery selector .moxie-shim-html5 input[type="file"]. A similar selector is already used in the media views FocusManager and seems fine to me. Worst can happen is that it does nothing.

Tested with IE 11 and Edge (44.18362.449.0): the upload button works as these attributes don't impact the computed display property of the input file, see [47549] / #49753.

Tested with latest Firefox / NVDA and IE 11 / JAWS 2019 and the input file isn't announced any longer.

The patch does also a couple more things:

1
Minor coding standards.

2
TL;DR: it removes a line of jQuery that was meant to hide the "shim" container. Turns out the format of the container ID:
'#' + this.uploader.id + '_html5_container'
isn't used any longer since a few years. Actually, on WordPress 3.8 it used to be something like this:
id="p1e8mvp38f1lbl1u5mbin1ckg1na20_html5_container"
then in WordPress 3.9 it changed to:
id="html5_1e8mr85t0q6o1n9t1ko610ldjre5_container"
so this line of code doesn't do anything since a few years. It appears the ID format changed with the upgrade to Plupload 2.11 in #25663. See also [21380] / #21437. In any case, I don't think we actually want to hide this container.

There are probably more things a bit out of date in wp-plupload.js but they're out of the scope of this issue.

#38 @afercia
5 months ago

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

In 47834:

Accessibility: Media: Hide the invisible "file input" on media views from assistive technologies.

The file input button is visually hidden, but was announced by screen readers in workflows unrelated to file uploads.
It is now hidden from assistive technologies by the means of an aria-hidden attribute, as its CSS display property must not be changed to make sure it still works on old browsers.

See #49753.
Fixes #47611.

Note: See TracTickets for help on using tickets.