Text inadvertently rendered by assistive technologies

[anevins]

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

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

Issue description
Users of assistive technologies such as screen readers who navigate to
the bottom of the Settings panels will find a button which they cannot
activate (nor see if sighted) called "Select files".

Additionally, if users change the color modes in the popup custom color
picker, the current mode is announced in a live region. However, long
after users are done with choosing a color, even after choosing to edit
another block on the page, when they reach the bottom of the Block panel
they'll still hear "hex color mode active". At this point, users may
not remember what this was for and have no idea what this is
referencing, as it no longer has any context.

Issue Code

    <!-- color announcement -->


    <div id="wp-a11y-speak-polite" aria-live="polite" aria-relevant="additions text" aria-atomic="true" class="screen-reader-text wp-a11y-speak-region">Hex color mode active</div>





    <!-- select files -->


    <div class="wp-uploader-browser" id="wp-uploader-browser-o_1d2saqvj4l3skgruvl1ejo1ejp3" style="position: fixed; top: -1000px; left: -1000px; height: 0px; width: 0px;">


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


    </div>

Remediation Guidance
When users have performed an action, such as clicking another block (or
whatever action causes "No block selected" to appear in the Block
panel), clear the live region so that users who encounter it while
manually reading do not hear it. Refill the live region when users
change color modes.

The hidden file selection button should be hidden from all users with
display: none whenever it is not visible nor meant to be used.

Recommended Code

    <!-- color announcement -->


    <div id="wp-a11y-speak-polite" aria-live="polite" aria-relevant="additions text" aria-atomic="true" class="screen-reader-text wp-a11y-speak-region"> </div>





    <!-- select files -->


    <div class="wp-uploader-browser" id="wp-uploader-browser-o_1d2saqvj4l3skgruvl1ejo1ejp3" style="display:none;">


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


    </div>

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 and funded by WP Campus. This issue is GUT-41 in Tenon's report

Note: The a11y-speak live regions are used in core as well. In several places. Thus, clearing the live regions shouldn't depend on a specific user action or scenario. It would require a more generic solution, preferably avoiding setTimeout() which seems to me a very fragile solution by its own nature.

[afercia]

Related: #47156.

[anevins]

2 issues being discussed;

1) The "Select files" button isn't hidden to all users, only to some;
2) There is a stray aria-live region that has information no longer relevant to the user

With 2 solutions:
1) As stated in the ticket, this should be an easy fix with 'display none' css
2) We can remove the region's text contents when focusing onto another field

[afercia]

Note: I split the live region issue to #47156

[joemcgill]

@afercia do you have any more information here? It's unclear to me what is meant by "Settings panels" in the issue description. If you could help clarify the issue, that would be a big help.

[afercia]

@joemcgill sure. The "Settings panels" is the Gutenberg sidebar, which is rendered close to the end of the markup. That's just to indicate that after that, at the very end of the markup, there's a button.

This button is generated by wp-plupload.js. It's positioned off-screen but still focusable and operable. Perceived by assistive technologies, hidden only from humans:

I'm not sure if wp-plupload.js is really needed in the Gutenberg context. For sure, the way the "insert" frame is initialized in Gutenberg is a bit different from Classic Editor.

Seems to me in Gutenberg this button is rendered only after a block with an image is added:

Worth also noting that a new insert frame is rendered each time a block with an image is added. In this scenario, there are multiple insert frames and multiple buttons:

To my understanding, this is different from core Classic Editor, where same care has been taken to reuse the insert frame, if it already exists. For a simple example of the core usage, see https://core.trac.wordpress.org/browser/trunk/src/js/_enqueues/admin/custom-background.js?rev=43347&marks=86-143#L79

If I remember correctly, there are other places in core where a similar check runs.

Not sure initializing multiple insert media frames is ideal from a performance perspective. Regardless, the button should be hidden either with display: none or visibility: hidden until there's the actual need to use it. (Not 100% sure but I think it's never actually used and works as sort of fallback).

[afercia]

Similar issue: https://core.trac.wordpress.org/ticket/47611

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

[audrasjb]

Hi there,

Given this ticket is not a regression from WP 5.3 and as it still needs a patch and testing, let's move it to milestone 5.4.

Of course, if a patch lands in the next few hours, feel free to move in back to 5.3.1.

Cheers,
Jb

[audrasjb]

We are at 14 day from 5.4 beta 1 so let's move this one to Future release. The patch doesn't looks that easy as it would need to figure out when that button is used or not, etc.

[antpb]

Mentioned in the recent Media Component meeting, this looks like a good ticket for 5.8. Adding to the milestone for visibility.

[JeffPaul]

With 5.8 Beta 1 next week and no patch/PR on this ticket, I'm going to punt this to Future Release. Once a patch/PR is available this ticket can be added back to a numbered milestone.