Dark mode accessibility

[skjnldsv]

Hello fellow nextcloud developers/users.
This issue has been discussed here and there on the owncloud project before, but never with the new project. So I would like a real talk about this.

The dark mode isn't a design solution. Personally, I have some issues with my vision, and have a safe environnement set up on my computer. Basically, everything's black. I have a lot of custom themes for most of my websites, and for the rest of them a script to revert the colours if the brightness is too big. So yeah, I'm browsing 70% of the websites on negative 😝

Since the nextcloud project has started to extend the theming function, I though it would be a great idea to implement this on core as a default functionality.

Right now, I started cleaning the unwanted and useless white backgrounds all over nextcloud (see #1657). If we want to implement the dark mode, we can easily do this by using a rgba composition based on the middle rgb value: grey 127,127,127.

What it means in simple word: same contrast for different background.

What do you think of a dark mode on nc? Would you use it? Any recommendation?
If this request is denied, I will offer this as a theme outside the nextcloud project. 😉

Here's a quick example of what i'm using right now (still needs some work 😄).

@nextcloud/accessibility @nextcloud/designers @irgendwie @jancborchardt

[MorrisJobke]

I really like it. This is basically moving from a clear black/white for borders, etc to a value in the middle of the grey scale to be able to apply it without change on bright and dark background, right?

[skjnldsv]

Basically yes!
I'm calculating the exact grey values to keep the same rendered colour on white background.
For example, a #DDD background will become a rgba(127, 127, 127, .266) (26.5625% to be precise) on white background.
Like so we can apply a dark background and keep the same gap between #FFF/#DDD with #000 and the new rgba colour.

There is some limitation though. Because we can't go higher than the rgb 127, the font colour (that are usually opposed to the background) can't have a correct value. So it must be set on body like the background.
This is basically the only two values we have to change: font and background. The reste of the ui will automatically adapt.

[jancborchardt]

I would say it can be an app first, because otherwise we suddenly need to test all core cases for two entirely different color modes. It would be a lot to support for what probably not that many people use (sorry but most people use the default ;) Are you ok with that @skjnldsv?

One thing about the current dark mode: The icons of the navigation need to also have their grayscale inverted to be white. cc @juliushaertl

[skjnldsv]

What core case are you referencing to? :)
I'm not sure, but I think it could be more complicated to build an app for this instead of a simple switch on the user settings and a css file applied then.

Edit; if you're referencing the ui as it is, this is the purpose of the gray rgba filter I'm talking about. If the display is good as it is in white, it will be good with black too, no tests needed 😉

[juliusknorr]

@jancborchardt The icon inversion back to white is quite simple, I also do that inside the directmenu app https://github.com/juliushaertl/direct_menu/blob/master/templates/direct_menu.php#L160-L167

I'm with @jancborchardt , that this would probably fit best in an extra app.

As this is an accessibility feature, that might only be used by some users who need it, it should be also possible to enable per user.

[jancborchardt]

@skjnldsv core cases like apps not being optimized for it for example. If we offer it in core, it needs to be tested. And we simply can’t test all these possible cases and apps. ;) Just because it’s easy doesn’t mean we should do it. It’s perfect for an app though! :)

[skjnldsv]

As long as we can provide a simple way for a user without permission to activate it, it's fine.
This is the main issue with the app system. A simple user would have to ask his admin to install the app :)

You make a solid point @jancborchardt, but we already force devs to fit the owncloud guidelines. We could simply do the same with the white backgrounds 😛

[juliusknorr]

@skjnldsv As far as I can tell you could add a custom section to the personal settings and just add a checkbox to enable it per user from there. The app is enabled for all users, but the custom styles only get loaded when the user has checked the setting.

[deanso]

Awesome! Would certainly use this.

[mdev88]

I also have issues with my vision and using the "classic" Nextcloud theme is so painful and frustrating. It has very low contrast, the fonts are really thin and it's just so... white! 😄

Is there any way I could try this @skjnldsv ?

[skjnldsv]

@martinchodev Since the last variable update, you should be able to easily edit your default nextcloud colours by editing the variables.scss file :)

[comradekingu]

Speaking of default, why does it not vary with time?
It is the fair assumption that users would want their sleep cycle to be in tune with the sun.
Or in the least not be skewed by a static default. Added benefit of somewhat being able to tell time that way.

[jancborchardt]

Except for ebook readers or navigation systems, I’ve never seen a whole interface which completely switches. And that would also be pretty strange – especially cause we need to judge either by time+timezone, or ambient light cause people use indoor lighting, or or or.
People can write an app for that, but the default will simply be light.

[skjnldsv]

Yep, I agree with @jancborchardt !
I saw this behavior on some apps, but never by default.
We'll see if a dark mode is possible after I finished cleaning everything! :)

[jancborchardt]

By the way, because you mentioned the middle rgb(127,127,127) value – this is not something we can do because it doesn’t pass WCAG AA guidelines:

On white: https://contrastchecker.com/?c=7f7f7f&b=ffffff

On black it passes AA (although we shouldn’t use #000 complete black as background cause it’s too hard):
https://contrastchecker.com/?c=7f7f7f&b=000000

---

On white for example, the lightest grey which passes AA is rgb(118, 118, 118) / #767676, which I fixed in 0d675ec

The lightest grey which passes AAA (and color contrast test) is #585858 / rgb(88, 88, 88). Since we have $color-text-details now, we could have the »High contrast mode« simply change that variable from rgb(118, 118, 118) (which is already AA compliant) to rgb(88, 88, 88).

[skjnldsv]

Yeah, the idea of middle value to have a dark theme has been dropped :)
Since we have our variables now, we should easily implement this without any issues ;)