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

[afercia]

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.

[afercia]

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.

[afercia]

Similar issue: #47144

[joemcgill]

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

[afercia]

@joemcgill happens also in Classic Editor.

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

[audrasjb]

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.

[afercia]

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.

[audrasjb]

Hide moxie-shim container and input via CSS

[audrasjb]

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

[azaozz]

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.

[audrasjb]

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

[audrasjb]

Moving this ticket to milestone 5.4.

[azaozz]

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

[afercia]

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.

[afercia]

Created ​https://github.com/moxiecode/moxie/issues/185 upstream.

[afercia]

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

[azaozz]

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]

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.

[audrasjb]

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.

[afercia]

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.

[SergeyBiryukov]

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.

[afercia]

Reopening. See ticket:49753#comment:37

[afercia]

Potential new path for a fix: https://core.trac.wordpress.org/ticket/49753#comment:36

[afercia]

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.

[afercia]

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.