High Contrast hint on settings portal #1175
Conversation
|
I think this is pretty uncontroversial as is, thanks for proposing it. Let's just check if anyone objects to this proposal. |
|
Just taking the list of ACKs from #815:
|
|
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 👍 |
|
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. |
|
I wonder if the namespace for the key should be something like |
|
Follow up from lleyton's above comment: |
|
@dominichayesferen Personally prefer |
|
I have a philosophical appreciation of Cassidy's "accessibility features are just features" assertion, so, in my humble opinion, |
|
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 |
|
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 |
|
Ack on
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:
|
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. |
|
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. |
|
Then I suggest turning this into a 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. |
|
I'd probably make it the following: 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 |
|
That would work as well. Just don't document low-contrast right now, we should evaluate adding that later. |
|
Anyway, how's that for a structure to accommodate lower contrast? |
dominichayesferen
force-pushed
the
main
branch
from
83ca4c3 to
065c318
Compare
Can't be any better, I like it.
This, and many other settings hidden behind the |
I wasn't aware of that article, but I'll admit the argument is quite compelling.
Seems good with me :)
Agreed. |
|
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. 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. |
dominichayesferen
changed the title
|
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...? |
|
Sure |
|
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
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. |
|
Agree with @snwh and @danirabbit on the 3 states suggestion to follow WCAG GNOME Foundation will fund the backend implementation. |
|
@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 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. |
|
Alright, with that, there's only a few ACKs left I would think. |
There was a problem hiding this comment.
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
|
The proposal looks sensible to me. ack from KDE |
|
ack from COSMIC |
|
Ack 😊 thanks everyone |
|
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. |
|
Ack from Helium. Let's do this |
|
Alright, gotta remember how to flatten and rewrite commits properly, so that I don't mess up and accidentally auto-close this PR. |
|
I think you can do it from the GitHub UI. Should be a button for a maintainer to squash and merge. |
Specify a key for getting the system's preferred contrast level.
dominichayesferen
force-pushed
the
main
branch
from
d54ce3e to
d6299bb
Compare
|
@GeorgesStavracas Ready! |
|
Guess that means I'm now officially an XDG standard author, nice. |
|
@dominichayesferen well done Here is the issue for GNOME backend impl https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/119 |
|
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 |
|
Shall we implement it in the -gtk portal as well? |
See flatpak/xdg-desktop-portal#1175 Signed-off-by: Hubert Figuière <[email protected]>
See flatpak/xdg-desktop-portal#1175 Signed-off-by: Hubert Figuière <[email protected]>
See flatpak/xdg-desktop-portal#1175 Signed-off-by: Hubert Figuière <[email protected]>
See flatpak/xdg-desktop-portal#1175 Signed-off-by: Hubert Figuière <[email protected]>
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 theorg.freedesktop.appearancenamescape. 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
Implementations of High Contrast
Technically also exists in Chromium, although is currently inaccessible on Linux.
Implementations using this standard