WordPress.org

Make WordPress Core

Opened 7 months ago

Last modified 2 days ago

#47144 assigned defect (bug)

Text inadvertently rendered by assistive technologies

Reported by: anevins Owned by: anevins
Milestone: 5.3.1 Priority: normal
Severity: normal Version:
Component: Media Keywords: needs-patch wpcampus-report
Focuses: accessibility Cc:
PR Number:

Description

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.

Change History (23)

#1 @afercia
7 months ago

  • Milestone changed from Awaiting Review to 5.3

#2 @afercia
6 months ago

Related: #47156.

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


6 months ago

#4 @anevins
6 months ago

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

#5 @afercia
6 months ago

Note: I split the live region issue to #47156

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

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


5 months ago

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


4 months ago

#8 @joemcgill
4 months ago

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

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


4 months ago

#10 @afercia
3 months ago

  • Keywords needs-screenshots removed

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

http://cldup.com/Sgy0DUdP87.jpg

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:

http://cldup.com/QqpNyL_itl.jpg

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:

http://cldup.com/PTGQSfg-PM.jpg

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

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


3 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 #core-media by mike. View the logs.


3 months ago

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


3 months ago

#16 @joedolson
3 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.


2 months ago

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


2 months ago

#19 @audrasjb
2 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.


7 weeks ago

#21 @afercia
7 weeks 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.

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


13 days ago

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


2 days ago

Note: See TracTickets for help on using tickets.