Summary: | Constant Colors Fail WCAG 2.1 Contrast Ratio | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | flywire <flywire0> |
Component: | UI | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED NOTABUG | ||
Severity: | normal | CC: | c_strobbe-fdo, hossein, libreoffice-ux-advise, m.weghorn |
Priority: | medium | Keywords: | accessibility, needsDevAdvice, needsUXEval |
Version: | Inherited From OOo | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=133268 https://bugs.documentfoundation.org/show_bug.cgi?id=148085 |
||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 101912 | ||
Attachments: | LO7.5 - Alpha Fails WCAG |
Description
flywire
2022-07-10 10:24:35 UTC
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. |