Blocks use custom selection color

[karlgroves]

Blocks use custom selection color

• Severity: Low
• Affected Populations:
  • Low-Vision
• Platform(s):
  • All / Universal
• Components affected:
  • Block Editing
  • Block Options

Issue description

Blocks use a custom CSS color for text selection.

For Firefox users who have low-vision and use a Windows high-contrast
theme, custom selection colors are not honoured, but are not replaced by
defaults either. Consequently, these users will not be able to see what
text is selected.

Issue Code

    .editor-block-list__layout .editor-block-list__block ::selection {
        background-color: #b3e7fe;
    }

Remediation Guidance

Remove custom selection rules, and allow the browser/OS native color to
be rendered.

Relevant standards

• 1.3.3 Sensory Characteristics
  (Level A)

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-97 in Tenon's report

[afercia]

To my knowledge, Firefox honors ::selection (at least on macOS?). I'd agree on the general issue that the best option is to not play with operating system defaults. Will take care to propose this issue for discussion during next accessibility team meeting.

[melchoyce]

Full report screenshot:

[StommePoes]

To my knowledge, Firefox honors ::selection (at least on macOS?).

MacOS doesn't have a real full high contrast setting compared to what Windows does (to my knowledge, unless I'm out of date?).
I could have sworn there was a filed Bugzilla on this however I am having trouble finding it. :(
It is still easily reproduceable on a fresh latest Firefox and Windows High Contrast however:

The second and last images are when you have selected something and then for example clicked another desktop application (allowing focus to leave Firefox without removing the selection).

These are without any changes to Firefox colour settings, which I kind of assume would change these results? But I'm not sure.

[afercia]

Right, I missed the "and use a Windows high-contrast theme" part :)

[mapk]

I'll take a look at this. In today's triage on slack, the Design Team agreed to just use the browser's default highlight if possible. How this effects high contrast modes will probably need further work.

[StommePoes]

Leaving selection to the default will Just Work.
This bug is something to do with how Firefox deals with how it reads the Highlight colour from Windowing software (so Windows just has... Windows) as there are bugs on similar issues on Linux (where various Gnome High Contrast schemes meet terrible ends when run with Firefox which also allows users to set certain window colours, as well as how FF deals with windowing themes... it's a bit of a mess).

[mapk]

So @StommePoes, thanks for your detailed comments. In your experience, Windows high contrast mode in FF will still show the text as highlighted if we use the default browser selection highlight? Is that correct?

[m-e-h]

This issue was also brought up in sanitize.css. csstools/sanitize.css#173

[StommePoes]

@mapk correct. As in, simply not having a ::selection or -moz-selection anything in the CSS at all.