High contrast and color blindness settings

[swick]

Similar to the org.freedesktop.appearance.color-scheme key in the settings portal it might be a good idea to expose

1. preference for high contrast UIs for people with bad contrast perception
2. type of color blindness to avoid certain colors and color combinations in UIs

[smcv]

What desktops have these settings and how are they represented?

xdg-desktop-portal cannot unilaterally invent a setting: it must exist in desktop environments first.

[3v1n0]

For sure GNOME has org.gnome.desktop.interface.a11y's high-contrast, not sure if KDE has something similar too.

[swick]

To my knowledge color blindness settings don't exist on a desktop level, yet, so that's on to do list. So yeah, this is more of a reminder that we should add that at some point.

[dominichayesferen]

I was going to make a new issue about High Contrast, but given this one exists, with High Contrast as part of it, and to prevent duplicate issues, guess I'll just 'hijack' this issue to at least get the High Contrast aspect of it potentially solved first.

Note: This message is solely about tackling the lack of a standardised High Contrast value, and not about Colour Blindness.

High Contrast is an important accessibility feature, being a way to introduce more contrast in the user interface of applications for the visually impaired user-bases, however right now all the Desktop Environments that have HC options seem to store the setting in their own respective areas - wouldn't it be great if there was just ONE standardised hint/setting for applications to be able to read to detect if High Contrast is desired by the current user?

My idea would be very similar to https://github.com/flatpak/xdg-desktop-portal/pull/633, except:

• Instead of a list of 3 options, use a boolean instead
• Name the key high-contrast or prefers-high-contrast?

As for potentially adding application colour palettes for High Contrast, given some Operating Systems allow users to specify a colour palette for applications to follow in High Contrast, I'm sure that can be tackled in its own separate discussion (maybe even through a standardised colour palette for applications, irregardless of High Contrast, to follow and users/DEs to customise, ala KDE colour schemes or Windows Classic?).

CC @Exalm from the GNOME side CC @danirabbit from the elementary OS side CC @aleixpol from the KDE side Sorry for not partaking in discussion about this before committing to this message - given how basically all High Contrast implementations, irregardless of platform, all appear to just be boolean values, I would assume there's no need for anything more than a boolean value anyway to merely hint to applications that High Contrast is desired, but of course if that isn't the case... apologies for not asking your opinions upfront beforehand.

[dominichayesferen]

Note: I'm ready to make a pull request (once I figure out how to add boolean values to the necessary xdg-desktop-portal files), but I haven't made one yet because I want to be sure everyone is a-ok with it being a boolean, first.

[danirabbit]

Just noting here that Pantheon doesn't support a high contrast mode, so that's kind of all you need to know from our side :)

Rationale is based on the WCAG success criteria for contrast wherein it is stated that users with vision loss above what would be considered AAA contrast ratios typically use assistive technologies like magnification or screen readers. So our goal is to have the default styles meet the WCAG success criteria instead of having a separate mode.

I don't think we've made a hard stance regarding color blindness, but generally I think we have a similar outlook where we try to avoid using only color to convey data in the default styles already

[dominichayesferen]

Just noting here that Pantheon doesn't support a high contrast mode, so that's kind of all you need to know from our side :)

Rationale is based on the WCAG success criteria for contrast wherein it is stated that users with vision loss above what would be considered AAA contrast ratios typically use assistive technologies like magnification or screen readers. So our goal is to have the default styles meet the WCAG success criteria instead of having a separate mode.

I don't think we've made a hard stance regarding color blindness, but generally I think we have a similar outlook where we try to avoid using only color to convey data in the default styles already

That's fair enough, though... while unrelated to this issue, wouldn't it be potentially beneficial to still supply an option in Accessibility just for all the non-elementary applications ('Request applications to use higher contrast'?), like those using LibAdwaita, as well as websites on the internet (given websites are often given High Contrast treatment on other platforms when H.C. is enabled)?

It's completely up to y'all to decide whether that's a good idea to consider or not, but... yeah, just food for thought if we get the High Contrast value standardised.

Ultimately, irrespective of this, I think all that needs to be done here is just deciding if a boolean is ok for the DEs that do want/have High Contrast switches, and if so, getting a Pull Request made for doing just that. We can always discuss the potential addition of application colour palettes to supplement H.C. in a separate issue. This issue can then be used to deal with colour blindness settings-standardising discussion, after the decision is made about what form a standardised High Contrast setting should take.

[alice-mkh]

GNOME has a high-contrast pref atm, but it's used as a catch-all for everything a11y - things like larger click targets in the past and switch labels now. Or making certain buttons non-flat. etc. That needs to be fixed, not standardized.

[dominichayesferen]

GNOME has a high-contrast pref atm, but it's used as a catch-all for everything a11y - things like larger click targets in the past and switch labels now. Or making certain buttons non-flat. etc. That needs to be fixed, not standardized.

In all fairness, right now LibAdwaita does have a HighContrast variant, doesn't it? Yes, whatever issues there might be can always be fixed in the future, but for right now wouldn't it be beneficial in general to get a standardized value and have every toolkit, every application with High Contrast functionality possible follow it, GTK/LibAdwaita included? Yes, it might get removed later down the line in GTK/LibAdwaita, but... that'd still mean all the other applications that have High Contrast options available get to benefit from having an optional High Contrast switch in most desktop environments that affects them all.

[alice-mkh]

No, it can't be changed anymore if it's standardized. That's the whole point of standardizing it.

[dominichayesferen]

No, it can't be changed anymore if it's standardized. That's the whole point of standardizing it.

I mean, this standardisation would just be a hint for applications to indicate high contrast is desired or not, fundamentally. The implementation on the application's side can always be adjusted. Even if LibAdwaita and/or GTK doesn't need it, that still doesn't invalidate that there are a bunch of applications out there with High Contrast options that may benefit from a standardised hint.

Edit: Additionally, further standards can always be made if needed, to accomodate for smaller things. As it stands right now, though, there is merit for having a standardised generic 'please use high contrast' hint at the very least.