Material-ui: Grouped autocomplete color contrast

[dmitriid]

Filed as a bug, because it's more of a usability bug

• [ x ] The issue is present in the latest release.
• [ x ] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

Regular | Dark mode
---|---
|

Category names are indistinguishable from regular items as there's not enough color contrast between items (it looks better on retina screenshots than in real life). This will be even more noticeable when category names are longer.

It may be worse with disabled items thrown into the mix (haven't tested this though).

Expected Behavior 🤔

Category names should be more pronounced.

Could be solved with any of: different color, bold font, underline. A horizontal rule before the start of the category, perhaps. Offset could probably work, but needs testing with longer category names, might still be confusing.

Steps to Reproduce 🕹

Tested on https://material-ui.com/components/autocomplete/ -> Grouped

Context 🔦

Material Design in general suffers from very low contrast, or not enough contrast between elements

Your Environment 🌎

Safari 13.0.4 (15608.4.9.1.3), MacOS 10.15.2

[UniverseHan]

What should we do? Aren't there options for that?

[dmitriid]

Could be solved with any of: different color, bold font, underline. A horizontal rule before the start of the category, perhaps. Offset could probably work, but needs testing with longer category names, might still be confusing.

Possible solutions:

• Start with a bold font. See if that helps. Possibly, bold font and capitalize (see "4 items in your cart" in the Transitions demo)

• You could offset the items in the same way browsers do it (note: default browser representation on the Mac has very poor color contrast for group headers):

• A divider with a subheader is an option (though it has to be checked for color contrast).

Even better: a divider with a (subheader) in the theme's primary color. See this screenshot from the docs. Here the category is to the left of the list, but could be on its own line.

[oliviertassinari]

Do we have examples of how Google solve this problem with its products? It could be an interesting source to benchmark with.

[TommyJackson85]

@oliviertassinari
This one is of their search bar which just uses a hr line underneath.

Here is just the search results which shows grey text above giving a rough overview of the results.

Could use a combination of greyed text and a grey underline. It would be quite subtle. I don't think I would like bold text. Bold text would be better used to put emphasise on words in found results (i.e. words matching the word you searched). In the search results section you can see bold text is used to put emphasis on words not inputed by the user.

[oliviertassinari]

Sorry, I should have been more precise. I meant how the select + categories/groups problem is solved.

[dmitriid]

I would advise against looking at what Google does.

• it's a huge organization with very different approaches and levels of implementation. See this mess for an example: https://grumpy.website/post/0TBOWnfjB

• even the official Material website is known to break its own rules

First and foremost I would look at accessibility guidelines, and go by those. Material's own guidelines are quite good: https://material.io/design/usability/accessibility.html

Quote:

Color and contrast can be used to help users see and interpret your app’s content, interact with the right elements, and understand actions.

Color can help communicate mood, tone, and critical information. Primary, secondary, and accent colors can be selected to support usability. Sufficient color contrast between elements can help users with low vision see and use your app.

Contrast ratios

Color contrast is important for users to distinguish various text and non-text elements.

Color contrast is important for users to distinguish various text and non-text elements.

end quote

[oliviertassinari]

@dmitriid we won't be able to advance the resolution of this concern without benchmarking how others are solving this issue. I have noticed that select2 uses an indent. I would highly recommend to look at what Google is doing. I'm not that much interested in the consistency of their product nor how well they follow the specification. It's not a hard science. It's subject to interpretation.
I think that we should focus on reviewing the solutions smart UX/UI designers that have faced the problem in the past came up with.

[dmitriid]

@oliviertassinari Good point.

I've quickly looked around.

Kendo UI | PrimeFace | SyncFusion
--- | --- | ---
Vegetables is group header | |

jQuery UI Autocomplete | Random Stackoverflow Question :) | Another SyncFusion Example
--- | --- | ---
| |

Vue Autosuggest | jQuery Typeahead Plugin | Svelte Select
--- | --- | ---
| |

Windows Combobox with Grouping | Drupal Search Autocomplete | ZK
--- | --- | ---
| |

[oliviertassinari]

Thanks, very interesting.

[dmitriid]

It looks like very few (easily Googlable) projects to grouping in autocompletes

[oliviertassinari]

We have the same problem with the Select component. Here is an example with Angular Material: https://material.angular.io/components/select/overview#creating-groups-of-options.

[embeddedt]

I notice that Angular Material and the native select element for Firefox (at least on Ubuntu) use indentation and bold text to accent the category headings.

(The list is partially transparent because it begins fading out to close as soon as you press PrtScrn.)

[oliviertassinari]

Looking more closely at the material design specification and the google products, it seems that groups are not something they support. So, I think that we can take some freedom.

I would personally be in favor of introducing a light left indent (to follow native selects) and look at how we can solve #18200 at the same time.

[dmitriid]

👍

1em or 2em will probably be more than enough (but needs to be checked with a variety of text lengths).

[embeddedt]

needs to be checked with a variety of text lengths

It seems that long option names do not get any special handling with the current implementation, at least from my limited testing here: https://codesandbox.io/s/mui-select-long-names-448b3

[oliviertassinari]

I would propose the following diff:

diff --git a/packages/material-ui-lab/src/Autocomplete/Autocomplete.js b/packages/material-ui-lab/src/Autocomplete/Autocomplete.js
index 463ff0f2f..3e7e1eb47 100644
--- a/packages/material-ui-lab/src/Autocomplete/Autocomplete.js
+++ b/packages/material-ui-lab/src/Autocomplete/Autocomplete.js
@@ -162,17 +162,14 @@ export const styles = theme => ({
     ...theme.typography.body1,
     overflow: 'hidden',
     margin: '4px 0',
-    '& > ul': {
-      maxHeight: '40vh',
-      overflow: 'auto',
-    },
   },
   /* Styles applied to the `listbox` component. */
   listbox: {
     listStyle: 'none',
     margin: 0,
     padding: '8px 0px',
-    position: 'relative',
+    maxHeight: '40vh',
+    overflow: 'auto',
   },
   /* Styles applied to the loading wrapper. */
   loading: {
@@ -223,6 +220,9 @@ export const styles = theme => ({
   /* Styles applied to the group's ul elements. */
   groupUl: {
     padding: 0,
+    '& $option': {
+      paddingLeft: 24,
+    },
   },
 });

What do you guys think about it? @d0minikt Do you want to open a pull request? :)

[dmitriid]

Looks really good 👍

Can you try with longer category names? Though it still should look good :)

[oliviertassinari]

28 pixels?

[embeddedt]

I can make a PR to close this and #18200 together if you would like.

[oliviertassinari]

@embeddedt I think that we can handle the Select and Autocomplete component independently in this case. I'm not sure how the solution for the Select would look like, it will likely be way different. But it's worth exploring :)

[embeddedt]

Okay; I am working on a PR for the Autocomplete component. Once that's done I will look at the Select component.

[dmitriid]

Thank you! 👍💪