pursue better contrast on outlines for menus, dialogs, etc. especially in dark mode

[mbgower]

Especially in dark mode, the outlines of tooltips, menus, dialogs and other types of overlays can be under-pronounced.
In the below screenshot of a dialog, the low constrast between the gray box and the darker gray background results in an experience where things like the X close buttons seems to be floating in the middle of the page.

Although 'white space' can be used to separate the text of such non-persistent content from the background a demarcation of the border that achieves 3:1 would reduce potential failures of Non-text Contrast.

Note that this is more likely in the realm of 'ehancement' than 'bug' -- I don't think in most cases we'd fail Non-text Contrast, because one can argue that you don't need the border to identify the component. But the benefit of more contrast is clear and backed up by our research. This is especially useful for low vision users, who may have more difficulty locating this material when it appears, as well as more difficulty differentiating between this material and content behind it.

[mbgower]

One interesting thing I noticed was that in the Overflow menu on the usage page, the focus indicator is used to create that clear boundary.
That's a little unusual, but may be interesting to explore as an overall solution.

[joshblack]

cc @aagonzales @laurenmrice

[aagonzales]

@mbgower That outline is what actually happens on all our dropdowns. I think a lot of our illustrated dropdowns in website images aren't showing the focus border but it does always appear in code for dropdowns. The focus stays on the whole menu then the hover style is what appears when arrowing through the options. It gets to be a lot of you have a focus outline around the menu and also a focus outline around the items.

https://react.carbondesignsystem.com/?path=/story/components-dropdown--default

[mbgower]

@aagonzales

That outline is what actually happens on all our dropdowns...The focus stays on the whole menu then the hover style is what appears when arrowing through the options.

I think this can be a good approach where the component takes some kind of outline focus around the whole. Please note that the hover style shading when arrowing through the options needs to meet 3:1 against the non-focused items!

However, this approach doesn't address the problem for something like a dialog (where the focus would normally only be on the elements within it that take focus). So I think the request to improve contrast on outlines in such situations still exists?

[sstrubberg]

This might need to turn into a Github Discussion rather than an issue that needs to be addressed.

[mbgower]

I also believe that some of the work @thyhmdo has done on Tiles may be appropriate to consider here.
Thy, in regard to outline, do you see any of the considerations you had around tile contrast enhancements being relevant to increasing the outline of dialogs and complex components that do not take focus around the whole?

[thyhmdo]

Hey Michael, there are couple thoughts.

1. I think we should look at more examples of what these components look like on the product pages. For example, when I first come to this Security page. It is an issue that the modal looks like it's blending in with the background even though there is an overlay background.

2. However, there are also a case where they use a lighter background modal and that looks much better. I wonder if these cases have enough contrast for accessibility? If these pass the accessibility requirements, then we can advise people to avoid using the modals those look like it could create the issue here.

3. But here is just the modal case. Seems like the dropdown focus line could work. Are there any other specific components you think of for this issue? The header menu could be a problem? While Security has a subtle border around it, Cloud doesn't have it. Note that our current menu doesn't have a border either.

[mbgower]

thanks, Thy. I think the outline around that Dallas menu/dropdown is working okay. They've basically stuck with the black of the top nav bar for the options list background, and then used grey 80 both for the item with focus and as the stroke on the outline. Ironically it is not very high contrast either. If they used a gray 70 that could almost get to 3:1 while letting the the Gray 10 text still contrast more than 4.5:1 when the item is selected (Dallas). It's actually going to be hard to indicate the option with focus using just a fill because it's tough to get a color that both contrasts 3:1 against the fill of unselected options and also 4.5:1 between the fill and the text colour.

A safer option is to put a focus indicator around the menu/list as well as the item. It wouldn't even need to be as thick as the one around Manage in the bottom example, but a 1 pixel around the whole list would certainly pump it up and ensure that when the focus appearance comes into force with WCAG 2.2, this would pass. (As it is, it will fail the contrast on the option with focus.)

So I guess there are two different topics we should be careful not to mix up too much:

1. a better distinction of the border of dialogs and dropdowns/menus (nice to have)
2. a 3:1 distinction between an item/option with focus and one without focus (arguably necessary now, and definitely a requirement in WCAG 2.2)

[laurenmrice]

Another instance from the zAIOps team (Example provided by Phoebe Cai) where dropdown menus overlay dashboard content using similar colors. I do know currently that the menu would technically get a focus outline here, but we have had recent discussions on if we need to change it.

[Phoebecdy91]

For some of the dropdown, like Combo box & Filterable multiselect, the dropdown menu doesn't have a focus border. But for the default and multi-select one, the menu has the focus border. I would suggest to keep consistent.
And I will put one of our dev env for implementing this. Seems the focus border makes it too different from others.

[mbgower]

Thanks, @laurenmrice. I will note that WCAG 2.2's Focus Appearance has been moved to a AAA. It's not that people did not want to have a requirement for enough contrast for the item with the focus, but we could not find a way of consistently testing it that did not get very tricky on variable backgrounds.
The non-text contrast requirements remain for Focus, but there's no requirement that it necessarily contrast with the non-contrasted item. In my opinion, Carbon should still try to make the delineation on dropdowns in particular better, but the existing contrast requirement is that the indicator for which item in the dropdown is currently focused needs to be at least 3:1, which it isn't using just the hover effect.