https://bugs.documentfoundation.org/show_bug.cgi?id=156789
Caolán McNamara <caolan.mcnam...@collabora.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.wegh...@posteo.de --- Comment #16 from Caolán McNamara <caolan.mcnam...@collabora.com> --- Yeah, this is apparently by design. Maybe following the "letter of the law" for some compliance effort in the past, I find the outcome quite odd but there is quite a lot of built-in code that works hard to provide this result for high contrast accessibility. IIRC when I enable a similar setting in e.g. MSOffice I get fairly bizarro-land results too. I tried to cover what I know in slide 7 of https://fosdem.org/2023/schedule/event/lotech_darkmodes/ which I'll paste here: << Accessibility High Contrast Mode May not be a dark mode, but often is, but this is a special mode. We make a special effort to follow these rules, with arguably strange results: * learn.microsoft.com/en-us/windows/win32/winauto/high-contrast-parameter “Map all colors to a single pair of foreground and background colors. Use the GetSysColor function to determine the appropriate foreground and background colors, using either a combination of COLOR_WINDOWTEXT and COLOR_WINDOW or a combination of COLOR_BTNTEXT and COLOR_BTNFACE. The GetSysColor function returns the colors selected by the user through the Control Panel. * Omit any bitmapped images that would typically be displayed behind text. Such images are visually distracting to a user who needs high contrast. Images that would typically be drawn in multiple colors should be drawn using the foreground and background colors selected for text.” >> I don't know if Michael W. has any specific insight into if we're doing this right at all, but I think this old a11y recommendation is why we end up like this. -- You are receiving this mail because: You are the assignee for the bug.