Text inadvertently rendered by assistive technologies

[karlgroves]

Text inadvertently rendered by assistive technologies

• 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

[afercia]

Note: the "Select FIles" button (wp-uploader-browser) comes from the Media Views and this part should be moved to Trac, as it needs to be addressed in core. Going to add the "Media" label for this part.

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.

[anevins12]

Moved to Trac: https://core.trac.wordpress.org/ticket/47144

[afercia]

Leaving this issue open for now, pending decision on where to track the a11y-speak issue.

[karmatosed]

Should we close and discuss in Trac @afercia ?

[afercia]

@karmatosed OK, will create a ticket specific to the a11y-speak part.

[afercia]

See also https://core.trac.wordpress.org/ticket/47156 for the a11y-speak part.

[afercia]

Ping @StommePoes @karlgroves when you have a chance, any suggestions on a good way to clear out the live regions would be very appreciated. See ongoing discussion on https://core.trac.wordpress.org/ticket/47156

Ideally, I'd like to not use:

• "global" click / keyboard events
• setTimeout

[StommePoes]

I will have a think on this and post here. I can't remember my trac login!

[StommePoes]

pfff...

I've got nothing that's great. I think the setTimeout isn't as bad as it first seems: these live regions are known lengths (approximately), even when accepting language differences and the slowest assumed reading speed. If the user doesn't change their focus while the live region is reading out, even if it were emptied, this shouldn't stop the read (this would need to be tested as I'm not certain this is true for all AT+Browser combos, using a large amount of test text and emptying the region containers or display: none-ing them early. But my feeling is the announcement wouldn't suddenly stop part-way through).

It would be more ideal if more of these things could be made visible, like "hex color mode active" sounds like something that could be alternative text on a visible bit. Anyone glancing at the colour picker immediately knowing which mode. Maybe start with that first (how many can be integrated into the general design).

I thought about moving the regions to the top (where, on page load, they'd be empty), however during testing I found myself back at the top all the time, so I'd still run into old regions. So staying at the bottom it is.

Another thought I had was simply stating what these were for users, for example prefacing them with "announcement" and even a time (social-media style, like "5 minutes ago", "1 hour ago")-- something like this makes the existence of the region less confusing. Right now "hex mode active" by itself, if you run into it long after you messed with the colour picker, it's got no context, and you're like, wut? But if it was clear this was an announcement, leaving it there may be fine.

<p (maybe also empty on page load, and filled just once)>Announcement, 5 minutes ago:</p>
<div id="wp-a11y-speak-polite" aria-live="polite" aria-atomic="true" class="screen-reader-text wp-a11y-speak-region">
hex color mode active.
</div>

One advantage of leaving it there is Braille-only users (deaf-blind) do not get live announcements. That's another argument for maybe leaving them there but just with some more context added.