LO default colors fail WCAG 2.1 contrast ratio, for example, the colors used in the macro IDE: https://github.com/LibreOffice/core/blob/master/svtools/source/config/colorcfg.cxx#L447-L453 * default colors eg https://github.com/LibreOffice/core/blob/master/svtools/source/config/colorcfg.cxx#L406-L461 * color types constants: https://github.com/LibreOffice/core/blob/e4a57dcdabc9ae7d381025e008b90635c1b7b10c/include/tools/color.hxx#L448-L499 The IDE uses default colors which mainly fail as shown using https://webaim.org/resources/contrastchecker/?fcolor=000000&bcolor=FFFFFF&api (replace fcolor and bcolor as required). The required ratio varies but starts at 4.5: * COL_BLUE 00 00 80 - 000080 {"ratio":"16.0","AA":"pass","AALarge":"pass","AAA":"pass","AAALarge":"pass"} * COL_GREEN 00 80 00 - 008000 {"ratio":"5.13","AA":"pass","AALarge":"pass","AAA":"fail","AAALarge":"pass"} * COL_RED 80 00 00 - 800000 {"ratio":"10.9","AA":"pass","AALarge":"pass","AAA":"pass","AAALarge":"pass"} * COL_GRAY 80 80 80 - 808080 {"ratio":"3.94","AA":"fail","AALarge":"pass","AAA":"fail","AAALarge":"fail"} * COL_LIGHTRED FF 00 00 - FF0000 {"ratio":"3.99","AA":"fail","AALarge":"pass","AAA":"fail","AAALarge":"fail"} These colors are carried through into the guides and other documentation. ==================== Suggested: * tweak colors so they comply with WCAG 2.1 * eg red: #FF0000 -> #EE0000, grey: #808080 -> #696969 * take the opportunity to change constant color names and values to html colors ==================== The actual colors defined by the lo variables are often unexpected because they tend to be darker than similar color names used by html. Lo_Color HTML #000000 Col_Black = Black #000080 Col_Blue * Navy #008000 Col_Green = Green #008080 Col_Cyan Teal #800000 Col_Red * Maroon #800080 Col_Magenta Purple #808000 Col_Brown Olive #808080 Col_Gray = Gray #CCCCCC Col_Gray3 #D3D3D3 LightGray #666666 Col_Gray7 #696969 DimGray #C0C0C0 Col_Lightgray Silver #0000FF Col_Lightblue * Blue #00FF00 Col_Lightgreen Lime #00FFFF Col_Lightcyan Aqua #FF0000 Col_Lightred * Red #FF00FF Col_Lightmagenta Fuschia #E0E0FF Col_Lightgrayblue #E6E6FA Lavender #FFFF00 Col_Yellow = Yellow #FFFFFF Col_White = White 19 Total 4 * Conflict 5 = Match 7 Different 3 Unnamed Lo_Color constants changed to mixed case for readability
While most hard-coded colors become overwritten by the user-defined colors the request makes sense to me. Also to relabel the color names.
Hossein, what do you think? Could be some easyhacks.
(In reply to Heiko Tietze from comment #2) > Hossein, what do you think? Could be some easyhacks. I also think that this is a sensible request, but I think the amount of change needed to rename the constants is too much. Let's count: $ git grep COL_|wc -l 4935 $ git grep -l COL_|wc -l 853 So, 853 files should be changed in ~5k lines. That's a pretty big change. I accidentally came across this wiki page, which can provide good insight: Large scale changes https://wiki.documentfoundation.org/Development/LargeScaleChanges I think we should discuss this in the ESC call, before marking it as an EasyHack.
(In reply to Hossein from comment #3) > I also think that this is a sensible request, +1 > but I think the amount of > change needed to rename the constants is too much. No strong opinion here from my side either way.
We discussed this idea in the design meeting. The part to rename the internal variable names like COL_BLUE to COL_NAVY was rejected as too much noise for no benefit. The RGB values follow HTML with blue = navy, red = maroon, and green all with #80 instead full #FF. I fail to see how colors fail a11y besides the artificial test. For example, COL_BLUE is used on the progress bar when loading/saving files. It contrasts therefore with the system theme color for the window background. But ultimately should be taken from the system theme anyway being orange on Ubuntu, for example. So rather than changing a large number of files we fix the issues individually.
https://lists.freedesktop.org/archives/libreoffice/2022-July/089195.html > => do not change the names but give RGB values a try (In reply to Heiko Tietze from comment #5) > I fail to see how colors fail a11y besides the artificial test. What do you mean by "artificial test", it's a calculation of what is displayed on the screen. The simplest example is the Basic IDE. The concern is the red and grey which have noticeably poor contrast for people with good eyesight. (In reply to flywire from comment #0) > Suggested: > > * tweak colors so they comply with WCAG 2.1 > * eg red: #FF0000 -> #EE0000, grey: #808080 -> #696969 I doubt anyone would notice the subtle change but it *would* improve contrast. I also think it sends the wrong message to ignore WCAG 2.1 when it is so simple to accommodate it.
Created attachment 184227 [details] LO7.5 - Alpha Fails WCAG Dark theme needs colours for constants that meet WCAG contrast ratios. Can't read blue text on black background in tooltip.
We show labels for colors on the standard palette and #800000 is "red" but not #800001. Second, if the changes are so subtle we do not need to modify the defaults that are eventually not used at all. (In reply to flywire from comment #7) > Can't read blue text on black background in tooltip. That's exactly what I meant with solving the issue one by one. It has been reported in bug 148085 and requires to overwrite the COL_BLUE with what the OS defines for hyperlinks, maybe in SwAccessibleParagraph::_correctValues() but finding the right places is the tricky part.