Update shortcut opacity

[alexroseb]

Description

Increased opacity at .84, the lowest it can be while still passing WCAG AA standards. Fixes #10576.

How has this been tested?

Doesn't affect anything except this small section because it's very specific CSS.

Screenshots

Original:

Updated:

Types of changes

Very small CSS change

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[postphotos]

LGTM! Nice tweak. 👍

[youknowriad]

By looking at the screenshot, I'd argue that while this fixes the accessibility issue for people with sight issues, it creates usability issues for regular people as it's very hard to distinguish the shortcuts from the menu captions. And since the shortcuts are visible more clearly in the "Shortcuts modal", I'd be more in favor of leaving the current color.

[tofumatt]

I agree with @youknowriad; this creates issues for users without vision issues–and we do have keyboard hints elsewhere that are much more accessible. If we could rely on symbols everywhere like MacOS does we could do this, as the keyboard shortcuts would be quite small and far away enough from the menu item to not confuse things. As-is this is unreadable to me.

Could a compromise be to increase the opacity but lower the font size? How would that look? 🤷‍♂️

[ffoodd]

IMHO, it would be better either to increase contrast on menu captions (to better distinguish them from shortcuts) since they're "only" 6.47:1, or to increase their font-weight a bit (which would result in better readability, making them more visible than shortcuts).

Don't know how to play with this, but FWIW the issue with shortcuts and captions looking almost the same isn't that shortcuts are too legible, is it?

Make every thing more readable, please :)

[afercia]

See #10576 (comment)

[designsimply]

Noting that @afercia's suggestions are to widen the settings area and make the keyboard shortcut the same color of the item labels and that a decision is needed for this issue to go forward.

[gziolo]

I copied #10576 (comment) to make it easier to follow this PR:

Any updates / plans on this?

I get why better contrast is important

It's not only important: it's a requirement, which seems something some designers and developers here don't want to acknowledge.

Re: the Windows argumentation: also on Windows the keyboard shortcuts, while larger, are of the same color of the menu items:

there's always a certain distance between the menu item and the shortcuts because the menu is larger.

Seems to me this is more a design issue. Why the more menu is only 260 pixels wide to start with? Worth also noting that languages other than English typically have longer strings and the menu doesn't account for them. When a menu item label goes in two lines, it's really not nice to see:

I'd propose to:

• make the menu adapt to the width of the item label + shortcut, in a way they're always on the same line separated by a decent amount of blank space
• make the keyboard shortcut the same color of the item labels

@alexroseb are you fine addressing this feedback?

[kjellr]

I think widening this to 300px would be fine. That way, it's a little bit wider than the sidebar column, and we can provide a bit more separation between the label and the shortcut.

As for the color of the shortcut labels, is there a reason we use opacity here instead of just swapping out with one of our actual gray values (like $dark-gray-300 for instance)?

[jasmussen]

Worth noting that in #13732 I'm changing the shortcut opacity to be fully opaque when hovered. I also updated the normal opacity to match this PR, so the rebase should be easier, which ever one gets approved first.

[aduth]

The specific changes proposed by this pull request were encompassed separately as part of #13732 . There seems to be a separate specific recommendation about the width of the menu, though I think it would be fair to acknowledge as a separate task tracked by #10576 (also in mind of lack of progress here).

For that reason, I'd suggest it be closed, and a separate pull request created for remaining items.