High Contrast hint on settings portal

[dominichayesferen]

Introduction

High Contrast is a feature where, much as the name implies, the contrast of applications that support the feature is increased, whether it be adding more opacity to lines in applications, or in the rare case changing the entire palette of an application to be of the maximum possible colour contrast. Irregardless of implementation, this hint has existed for quite a long time in the UNIX space, as well as existing in most other Operating Systems, and this pull request gives this long-standing accessibility hint a standardised location for both existing and future uses of high contrast to come.

Details

A new key on the settings portal, high-contrast, would be introduced into the org.freedesktop.appearance namescape. This key will use a boolean value.

The design of this key is based on every existing instance of a high contrast switch - in all platforms I know of, including those in the UNIX space who provide this value in a non-standardised manner, it has always been a simple boolean value which, if True, enables high contrast, but otherwise restores normal application styling if False.

This serves as a hint, just like its non-standardised variations, informing applications of the desire for contrast to be increased - applications are absolutely free to ignore it if, for example, they believe their default application appearance is of high enough contrast.

The hope for a standardised high contrast switch is that it will allow toolkits' existing high contrast options to be easily accessible from other Desktop Environments, such as GTK's high contrast option outside of GNOME, as well as encouraging programs, natively supported on XDG-compliant platforms, that technically have high contrast support programmed in, such as Mozilla Firefox and the Chromium Project, to expose this functionality on XDG-compliant platforms too.

Acks

• @snwh (GNOME)
• @sonnyp (GNOME)
• @JoshStrobl (Budgie)
• @CarlSchwan (KDE)
• @mmstick (Cosmic)
• @danirabbit (Elementary)
• @emilio (Gecko (Firefox's) Browser Engine)
• @nothingneko (Helium)

Implementations of High Contrast

• GNOME, and all GTK-powered Desktop Environments: High Contrast boolean-switch in Settings
• Firefox: Currently only available on GNOME

Technically also exists in Chromium, although is currently inaccessible on Linux.

Implementations using this standard

• https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/143
• https://gitlab.gnome.org/GNOME/libadwaita/-/merge_requests/1039
• https://gitlab.gnome.org/GNOME/libhandy/-/merge_requests/845
• settings: Implement the contrast settings xdg-desktop-portal-gtk#466
• https://invent.kde.org/plasma/breeze/-/merge_requests/397

[GeorgesStavracas]

I think this is pretty uncontroversial as is, thanks for proposing it. Let's just check if anyone objects to this proposal.

[GeorgesStavracas]

Just taking the list of ACKs from #815:

• @alice-mkh (GNOME)
• @JoshStrobl (Budgie)
• @Sodivad (KDE)
• @jackpot51 (Cosmic)
• @danirabbit (Elementary)

[JoshStrobl]

Ack on the Budgie side. Seems like a pretty obvious key to me. I'll make sure this one is kept in mind when we implement our own portal 👍

[dominichayesferen]

I'll also ping @emilio in here in advance, as I remember them participating in the accent colour portal MR discussion, as a pseudo-rep of sorts for Gecko and thus presumably Firefox - would you be able to, by chance, be a, or alternatively get a, representative from Mozilla Firefox's maintainers in here by chance to also see if they suggest anything to add as part of a standardised high contrast hint?

As for Chromium, not sure about how to get in touch with getting a representative for their side, for the record.

[lleyton]

I wonder if the namespace for the key should be something like org.freedesktop.accessibility instead of org.freedesktop.appearance. That's a minor detail though, everything else seems fine to me :p

[dominichayesferen]

Follow up from lleyton's above comment:
If the general consensus is in favour of Lleyton's idea, should it be called "org.freedesktop.accessibility" or "org.freedesktop.a11y"? Sorry if it has a confirmed name already and I just couldn't find it.

[JoshStrobl]

@dominichayesferen Personally prefer accessibility over a11y but not fussed either way.

[GeorgesStavracas]

I have a philosophical appreciation of Cassidy's "accessibility features are just features" assertion, so, in my humble opinion, org.freedesktop.appearance is fine. But it's not a strong opinion.

[GeorgesStavracas]

I'm going to leave it up to you all to agree on the naming scheme, I'm fine with all the options presented so far, and my preference for org.freedesktop.appearance over others is very faint.

[danirabbit]

I don't have super strong opinions here. We haven't historically supported a separate high contrast mode because our goal is to meet WCAG AA by default and my understanding is that folks with significant vision loss past this level would likely need other types of assistance like magnification or a screen reader.

WCAG also talks about some folks needing low contrast, so I'm not sure if it makes sense to go ahead and add a three-state setting for contrast if there's going to be a contrast setting? Or if it would be better assumed that a low contrast setting would be implemented by a compositor shader or something

[orowith2os]

Ack on appearance (as a third party).

Similarly, as not all Desktop Environments currently employ any form of High Contrast switches, this hint should also be considered optional for the Portal implementers - if you do not want a high contrast option in your Desktop Environment, simply hardcode returning False into your Portal implementation (remember, however, that by doing so third-party applications supporting this feature will never expose their high contrast implementations if this preference is merged and they start following it).

Did any app ever expose it in their UI? GNOME's and KDE's sure didn't. It's probably in the same realm as dark mode; it should be controlled in the system menus, not per-app.

But that would be getting into design discussions unrelated to this change. Nothing to block this on. I'd like to merge this as-is.

[dominichayesferen]

Ack on appearance (as a third party).

Similarly, as not all Desktop Environments currently employ any form of High Contrast switches, this hint should also be considered optional for the Portal implementers - if you do not want a high contrast option in your Desktop Environment, simply hardcode returning False into your Portal implementation (remember, however, that by doing so third-party applications supporting this feature will never expose their high contrast implementations if this preference is merged and they start following it).

Did any app ever expose it in their UI? GNOME's and KDE's sure didn't. It's probably in the same realm as dark mode; it should be controlled in the system menus, not per-app.

But that would be getting into design discussions unrelated to this change. Nothing to block this on. I'd like to merge this as-is.

I'm referring to the following:

• Applications: They can choose to read whatever the preference is, and if they want to whenever the preference returns True they can switch into a state of higher contrast
• Desktops: GNOME, Cinnamon, MATE, Cinnamon, maybe Budgie, and possibly XFCE (not sure though) all expose high contrast, in a non-standardised form, in their System Settings applications (currently under Accessibility).

[dominichayesferen]

I don't have super strong opinions here. We haven't historically supported a separate high contrast mode because our goal is to meet WCAG AA by default and my understanding is that folks with significant vision loss past this level would likely need other types of assistance like magnification or a screen reader.

WCAG also talks about some folks needing low contrast, so I'm not sure if it makes sense to go ahead and add a three-state setting for contrast if there's going to be a contrast setting? Or if it would be better assumed that a low contrast setting would be implemented by a compositor shader or something

I'm more than willing to convert this to a tri-state like theme-preference is, so we can accomodate low contrast preference, but while a part of me says we should just so that we don't need to make a V2 to add it in the future, another part of me says that might be too niche, what with literally no platform I know of having a 'low contrast' option except ancient GTK3 and maybe GTK2.

[dominichayesferen]

Actually, given that you could argue theme-preference's "Prefer Light" is of similar niche-ness... probably best for it to have Low Contrast added just on the off chance - although I REALLY don't expect anyone to ever implement it anywhere, though.

I suppose if nobody NACKs that idea, I'll implement it tomorrow or the next day.
re:Shaders: Wouldn't it be wise to, if the idea of low contrast isn't NACK'd generally, allow applications to know they're behind a low contrast shader anyway? That way, they can optimise themselves to... better be low contrast. Think of it as similar logic to the reasoning for having a potential colour blindness hint in Portal in the future - letting applications, especially games come into mind, account themselves for any filters in use.

[GeorgesStavracas]

Then I suggest turning this into a contrast string property or somesuch, with 2 documented values: "default" and "high-contrast". This will allow documenting a third "low-contrast" mode in the future without breaking API.

I don't think it's useful to add low-contrast mode right now. It seems like an unnecessary burden right now, given that apparently nobody implements it.

[dominichayesferen]

I'd probably make it the following:
0 - normal (basically the no preference mode)
1 - high
2 - low (undocumented until deemed necessary?)

Edit: Alternatively 'higher' and 'lower' could be a better fit for their names, but I'm probably being overly specific about smth that'll just be documentation now I think about it

[GeorgesStavracas]

That would work as well. Just don't document low-contrast right now, we should evaluate adding that later.

[dominichayesferen]

Anyway, how's that for a structure to accommodate lower contrast?

[orowith2os]

Anyway, how's that for a structure to accommodate lower contrast?

Can't be any better, I like it.

Think of it as similar logic to the reasoning for having a potential colour blindness hint in Portal in the future - letting applications, especially games come into mind, account themselves for any filters in use.

This, and many other settings hidden behind the org.gnome namespace, would also be great candidates for including in the Settings portal next, since color blindness might take a bit to design and work on on the toolkit side of things.

[lleyton]

I have a philosophical appreciation of Cassidy's "accessibility features are just features" assertion, so, in my humble opinion, org.freedesktop.appearance is fine. But it's not a strong opinion.

I wasn't aware of that article, but I'll admit the argument is quite compelling. org.freedesktop.appearance makes sense then.

Anyway, how's that for a structure to accommodate lower contrast?

Seems good with me :)

This, and many other settings hidden behind the org.gnome namespace, would also be great candidates for including in the Settings portal next, since color blindness might take a bit to design and work on on the toolkit side of things.

Agreed.

[dominichayesferen]

I feel that y'all will be able to handle discussion about this merge request in particular while I'm absent from it in lieu of IRL stuff and focusing on college, so to allow for that to potentially happen, it's time I undraft this.
If this standardisation-idea gets anywhere, I'll make sure to rebase this pull request from time to time, until I'm able to devote full time to this pull request again, so that it can be merged immediately if everyone wants it ahead of time.

As for colour filter hints PR: I think it'd be best to keep that as a draft for now until more discussion is had per each Desktop Environment on whether they want to do it, how they want to do it, etc. on their side.

[emilio]

I had missed the ping above, but this seems fine to me as well. Thanks for working on this!

[dominichayesferen]

I had missed the ping above, but this seems fine to me as well. Thanks for working on this!

Should I count that as an ack on Mozilla's side, or would it be better to get another Firefox/Gecko rep in the discussion for that...?

[emilio]

Sure

[snwh]

I would concur with @GeorgesStavracas that overall this seems pretty uncontroversial. I'm reminded of the prefers-contrast media query in CSS, which has already been mentioned, and would also agree on doing a 3 state key for contrast that somewhat mirrors the WCAG spec:

• default: no preference, or a deference to the current state
• high: hint for an active option that increases contrast
• low: hint for an active option that reduces contrast

I do think even if not all the stakeholders fully implement something like low contrast, it'd be good to have it in and documented just so it can be forward-looking, especially if this is an accommodation that could be made in future for a subset of users.

[sonnyp]

Agree with @snwh and @danirabbit on the 3 states suggestion to follow WCAG

GNOME Foundation will fund the backend implementation.

[sonnyp]

@dominichayesferen I pinged you on Mastodon in the hope it would help clarify

We are contractors for https://foundation.gnome.org/2023/11/09/gnome-recognized-as-public-interest-infrastructure/

As far as this PR is concerned
@snwh maintains the GNOME Shell contrast mode / stylesheet and I coordinate a11y efforts.

We acknowledge this PR but as we said, we share @danirabbit (Elementary) observation that the setting should follow the WACG recommendation and offer 3 states. High contrast, low contrast and no preference.

I'll mention this in a review to clarify. Feel free to reach out

[dominichayesferen]

@dominichayesferen I pinged you on Mastodon in the hope it would help clarify

We are contractors for https://foundation.gnome.org/2023/11/09/gnome-recognized-as-public-interest-infrastructure/

As far as this PR is concerned @snwh maintains the GNOME Shell contrast mode / stylesheet and I coordinate a11y efforts.

We acknowledge this PR but as we said, we share @danirabbit (Elementary) observation that the setting should follow the WACG recommendation and offer 3 states. High contrast, low contrast and no preference.

I'll mention this in a review to clarify. Feel free to reach out

Alright, thanks, just want to be sure to not make a mess of this PR's conversation from misassumptions.

[dominichayesferen]

Alright, with that, there's only a few ACKs left I would think.

[sonnyp]

Thanks a lot for working on this

I agree with @danirabbit (Elementary) and @snwh (GNOME) that we should follow WACG recommendation and support 3 states.

• no preference
• low contrast
• high contrast

Although I just realized while writing this that adding a low contrast option later is possible

Unknown values should be treated as 0 (no preference).

I'm not aware of any DE supporting a low contrast mode so I think it's fine to wait and see 👍

ack from GNOME

[CarlSchwan]

The proposal looks sensible to me.

ack from KDE

[snwh]

@sonnyp @snwh Can I confirm that you two are ACKing this MR, given your messages and who you may be representing?

Yeah, weighing in from GNOME. 👍

[mmstick]

ack from COSMIC

[danirabbit]

Ack 😊 thanks everyone

[dominichayesferen]

Wow, this actually reached 'full house' in terms of its ACKs, thanks everyone from basically all of the corners of FreeDesktop and beyond for providing your concerns, and eventually ACKs! 💙

I suppose this means this is ready for merging, then, but that's on those who can merge. In the meantime, if there are any MRs made in toolkits or desktop environments, with this proposal in mind, please drop them in this discussion so I can add them to the main message.

[GeorgesStavracas]

Please fix the commit history to have a single, properly formatted commit (see the main branch for commit message guidelines).

[nothingneko]

Ack from Helium. Let's do this

[dominichayesferen]

Alright, gotta remember how to flatten and rewrite commits properly, so that I don't mess up and accidentally auto-close this PR.

[nothingneko]

I think you can do it from the GitHub UI. Should be a button for a maintainer to squash and merge.

[dominichayesferen]

@GeorgesStavracas Ready!

[dominichayesferen]

Guess that means I'm now officially an XDG standard author, nice.

[sonnyp]

@dominichayesferen well done

Here is the issue for GNOME backend impl https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/119

[dominichayesferen]

oh yeah, @emilio, now it's merged you might be interested in the bug report made in advance: https://bugzilla.mozilla.org/show_bug.cgi?id=1861775

[hfiguiere]

Shall we implement it in the -gtk portal as well?