DevTools: Box Modal coloring hard for color blind users |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Issue descriptionReference: https://stackoverflow.com/questions/37437262/changing-the-color-of-box-model-elements-in-google-chrome-dev-tool The color selection for the box modal diagrams is difficult for some users to see due to color blindness. These really are too close together in hue. Can we get a new set of colors to change these so they are more accessible?
,
May 29 2016
Cross-browser coloring reference: Edge: * Margin - Yellow * Border - Green * Padding - Red * Content - Blue Firefox: * Margin - Yellow * Border - Black * Padding - Purple * Content - Blue Chrome: * Margin - Orange * Border - Lighter orange * Padding - Green * Content - Blue
,
May 29 2016
Each component of the box model is labeled as such using text + is using distinct separation pattern. It should cover the a11y aspect outlined.
,
May 30 2016
I think simply because we outline well and label them internally doesn't mean we can't also make it easier for people with problems distinguishing colors. Attached to this are alterations of each major tool through common forms of color blindness. These are direct screenshots taken using the Contrast Analyzer recommended in one of the web a11y guidelines from the W3C. In these, you'll notice that Chrome *and* Edge differ very highly between different forms of color blindness. However, Firefox's colors are *extremely stable*. This makes for a very consistent experience and should be easier for everyone to navigate regardless of ability to distinguish colors. My current feeling is that we should align with Firefox's coloring here to provide the most consistent experience we can to users. I'm doing more research to see if there are any particular usability guidelines that address this case exactly. Most of what I'm finding by quick searches is all related purely to text-contrast and not elements/charts that relay information like this. The only thing I've found for relaying information is direct charts. For those it is suggested to use a pattern as well for the areas and provide a legend. However, since we have data *in* the display that could make it difficult to read that unless done just right. [1] https://www.paciellogroup.com/resources/contrastanalyser/
,
Jun 1 2016
The concern here isn't so much about the visual box model, but viewing the padding/width/margin difference when in element inspection mode. I'd want to know if FF or Edge chose their colors deliberately to consider color blindness, etc. @Garbee, can you ping https://twitter.com/helenvholmes and Andy Sterland? Do the Firefox colors change depending on Dark Mode?
,
Jun 1 2016
They do not change between light/dark theme. Yes I'll reach out to others later today once I've investigated a bit more into guidelines for these kind of UX patterns.
,
Jun 1 2016
I'm not finding much in the way of guidelines here aside from patterning the background which isn't a good solution with our UX's. My gut instinct from what we have here is, going with FF coloring (provided no one has a more accessible color scheme to present) but stay with our dash bordering to differentiate as well. FF uses a small dot border instead of dashes and that is difficult for even me to see in alt modes and these screenshots (more bearable live, but still.) I asked Andy and Helen to take a look via twitter if they have time.
,
Jun 1 2016
Helen sent a mockup of their current draft [1]. I ran their new coloring through the tool and it has a deeper variation of coloring compared to their current color scheme (images attached.) [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1128209
,
Jun 1 2016
,
Jun 1 2016
I just did some quick testing. The following color combination is based on the Firefox scheme and compared [1] to verify complete WCAG guidance. The output for different forms of blindness are attached. The worst is monochromacy where border and margin are essentially seen as full gray. But, in that case the strong dashed border makes the distinction clear. In each other case except for Tritanopia, the colors are very similar to the default coloring. Making any instructions or internal documentation by companies directly addressable to the widest audience. People affected by tritanopia will perceive the most varying color set, however they are still very distinct and shouldn't blend together. Margin: background - rgb(255, 240, 132) color - black Border: background - rgb(52, 88, 105) color - white Padding: background - rgb(52, 82, 178) color - white Content: background - rgb(190, 200, 239) color - black [1] http://snook.ca/technical/colour_contrast/colour.html
,
Jun 1 2016
We discussed this some more. I think we're gonna hold off on this for now. This is an extremely visible area and we'll have to have more time committed across the team if we expect to change our users expectations of how margin/padding are visually represented.
,
Jun 2 2016
I think its cool to hold off implementing anything. However I'd still like to try and get some a11y people to take a look and see if this is even the right approach. The original reason for this investigation is a report that someone is seeing them blur together. Yet, the proposed solution seems to me more easy to blur into each other. I'm not sure if we should be going for "least amount of color changing" for people with different color impairments or if we should go for distinct bordering colors so that they are least likely to blend into each other.
,
Jun 6 2016
Fwiw I've uploaded the colors we use in Edge/IE/VS over at: https://gist.github.com/andysterland/aa0df7128a2e898f972daf1cf8a071b3 Today the layout panel and element overlays are one of the few things we don't theme based on high contrast or other things. I'd be happy to change to any colors that meet the 4.5/1 to contrast ratio and when in high contrast mode meet 14/1 (typically we have a diff set of colors for high contrast).
,
Jun 6 2016
How unrealistic would it be to support what the original poster wanted and allow configuring the colors for this piece of UI? That way we wouldn't need to try and come up with a one-size-fits-all scheme, but allow users to pick what works for them, whatever their needs may be. I'm concerned that otherwise "holding off for now" will last indefinitely, since pretty much any color scheme which is going to provide sufficient contrast between adjacent colors for all users is going to end up looking like a 'target', which nobody will like the look of.
,
Jul 29 2016
@aboxhall: We could introduce an "Accessible theme" next to the dark theme. I can help with automating most of it.
,
Jan 2 2018
,
Dec 3
I don't think we can change it at this point. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comment 1 Deleted