Re:UI design for software developers. Part 1, Colors
by habosa on Wednesday November 18, 2020 @09:10AM
(#25136891)
I'm no design expert but this advice is really thin and not that useful. Trust me that using a color palette generator is not the One True Way! Also there's no advice on how to pick a base color, just "pick one".
Again I am not an expert and I don't mean to be rude, but that's not a very nice looking app in my opinion. The colors, fonts, alignment, spacing, etc all seem just a bit "off".
Re:UI design for software developers. Part 1, Colors
by ukyrgf on Wednesday November 18, 2020 @02:55PM
(#25141639)
8 different font sizes, no logical line heights, some elements are spaced tightly (ordered list, share button) and some far apart (radio buttons). And the primary buttons in image 1 and 3 are teal, but in 2 we introduce a yellow button and in 3 there's a red one.
Re:UI design for software developers. Part 1, Colors
by V-2 on Wednesday November 18, 2020 @10:08AM
(#25137543)
Perhaps the fonts and alignment are deliberately off so that they can be improved in subsequent parts of the cycle. I'm not exactly blown away by the palette either, though.
Wording is sloppy, too ("into an email attachments"?).
Re:UI design for software developers. Part 1, Colors
by sixothree on Wednesday November 18, 2020 @01:13PM
(#25140187)
Looking at the link, I like the colors. But I have to agree the spacing really "appears to have issues". The wording overlaps and the buttons on the bottom have different left & right margin compared to the bottom margin.
Re:UI design for software developers. Part 1, Colors
by munificent on Wednesday November 18, 2020 @01:31PM
(#25140442)
> design is inherently subjective.
It's a really common misconception among technical folks that "subjective" == "arbitrary".
Design is inherently subjective, yes. But that does not mean that all design choices are equally good when goodness is measured by pleasing the greatest quantity of users by the greatest amount.
Ice cream flavor preference is subjective too, but if your ice cream shop only sells "sawdust sprinkles" and "frog's blood", business isn't going to go well for you. Or, perhaps closer to home, the choice of keywords in a programming language is entirely subjective. The compiler does not care if you use "while" or "rkdhx" for loops, but good luck convincing programmers to adopt a language that chooses the latter.
Designers have laboriously learned the aesthetic principles that align with how our visual system works and with the expectations users have coming from our shared culture's graphic history. That's what they mean when they say something is "right" or "wrong", and they have a lot of expertise to back it up.
Re:UI design for software developers. Part 1, Colors
by userbinator on Wednesday November 18, 2020 @09:36AM
(#25137195)
Not surprising to see no mention of "let the system (and by extension, the user) choose the UI colours if at all possible". It wasn't long ago that you'd set your preferences for colours, fonts, etc. in one place and every application would automatically use them and be consistent. Perfect for colourblind and those who have trouble seeing smaller fonts. UI design has gone backwards.
Re:UI design for software developers. Part 1, Colors
by hcarvalhoalves on Wednesday November 18, 2020 @12:49PM
(#25139867)
So, I looked it up, and it's indeed deprecated.
This is pretty ridiculous. The web is such a hack already, and deprecating this make it even worse at UIs. It seems every decision is optimised for branding (e.g. custom form controls), usability be damned.
Re:UI design for software developers. Part 1, Colors
by dragonwriter on Wednesday November 18, 2020 @01:05PM
(#25140086)
System colors are in the CSS Color Level 4 working draft updated less than a week ago. What appears to be (durably) deprecated is just a subset of the system color names, with what sounds like a reasonable reason:
Earlier versions of CSS defined several additional system colors. These color keywords have been deprecated, however, as they are insufficient for their original purpose (making website elements look like their native OS counterparts), represent a security risk by making it easier for a webpage to “spoof” a native OS dialog, and increase fingerprinting surface, compromising user privacy.
Re:UI design for software developers. Part 1, Colors
by jessaustin on Wednesday November 18, 2020 @01:42PM
(#25140612)
That explanation seems to be having it both ways. If it's really a spoofing security risk, do they still intend to provide functionality that is sufficient for the original purpose?
Re:UI design for software developers. Part 1, Colors
by dragonwriter on Wednesday November 18, 2020 @03:13PM
(#25141826)
> If it's really a spoofing security risk, do they still intend to provide functionality that is sufficient for the original purpose?
The explanation explictly says that the original functionality was a spoofing security risk, but even so was “insufficient for their original purpose (making website elements look like their native OS counterparts)”. So, no, they've fairly explicitly abandoned the original purpose.
They retained functionality has a more limited purpose, which I would describe as providing a vehicle for the user/browser/OS to provide defaults which pages/apps can reference, which when provided by the OS, minimize aesthetic clash and preserve contrast/accessibility between the page/app features and native UI without disguising the nature of the web page/web app, rather than actually mimicing native system UI.
Re:UI design for software developers. Part 1, Colors
by userbinator on Wednesday November 18, 2020 @07:48PM
(#25144867)
For Internet webpages it makes sense, but for things like Electron apps, the security argument makes no sense since the whole point is that they should look like the native OS.
Re:UI design for software developers. Part 1, Colors
by 3_hours_ago on Wednesday November 18, 2020 @04:47PM
(#25142853)
How would a global preference for colors even work? You can’t just change one color in a palette and expect the design as a whole to still make sense. Imagine a standard thing like a table where you want borders, subtle zebra stripes, focus/selection states, error states, and maybe color coded text for different types of values. Getting that to work at all requires careful coordination of the entire color palette.
It has one of the best discussions of contrast I have seen; very timely given the trends for low contrast design that seem prevalent combined with my now over 40 eyes (darn those kids!)
Re:UI design for software developers. Part 1, Colors
by coldpie on Wednesday November 18, 2020 @08:48AM
(#25136646)
> very timely given the trends for low contrast design that seem prevalent combined with my now over 40 eyes
I'm a decade younger than you and I still bristle every time I see someone disparage black-on-white. #000 on #FFF looks fine, guys, and it looks way, way better than the #BBB on #CCC that you're about to publish. You're overthinking it.
Re:UI design for software developers. Part 1, Colors
by gpanders on Wednesday November 18, 2020 @02:52PM
(#25141590)
> Accessibility is not a special case. In Q2 of 2018, sites using USWDS topped 1.4 billion pageviews. 4.5% [the portion of the population with some kind of color insensitivity] of 1.4 billion is around 60 million pageviews — when it comes to accessibility, thinking broadly and inclusively isn’t just a good idea, it’s our mission and responsibility.
It's honestly pretty cool to see this. I'm glad that the US government (or at least this one particular agency) takes accessibility so seriously.
Re:UI design for software developers. Part 1, Colors
by austincheney on Wednesday November 18, 2020 @08:58AM
(#25136751)
The greatest challenge when considering colors and accessibility is dealing with more than 2 colors. I wrote a tool to solve for all comparisons in a color scheme: https://github.com/prettydiff/colorContrast
In every real world scenario there will be a multitude of colors present that impact accessibility. It is almost never so simple as a single text color on a single background color.
Re:UI design for software developers. Part 1, Colors
by KineticLensman on Wednesday November 18, 2020 @06:32AM
(#25135631)
If you are reading this, Jerard, please please please consider the accessibility impact of colour, specifically on colour blind people. You should test your app's proposed colour with an accessibility-checking tool. You should also avoid using certain colours to distinguish between different things.
Re:UI design for software developers. Part 1, Colors
by Jerard_Victor on Wednesday November 18, 2020 @07:22AM
(#25135967)
hey, I do reading all the comments here. Frankly speaking, I didn't think about accessibility impact when I was playing with color palettes, but it turned out that Google does such assessment automatically when an app is being reviewed. Thankfully in my case, I didn't have any accessibility-related issues, but this is a valid point and probably it's better to do it during the mocking stage.
Re:UI design for software developers. Part 1, Colors
by ChrisMarshallNY on Wednesday November 18, 2020 @08:20AM
(#25136416)
Good luck with this. I do think that aesthetics could be improved in the tech field (I wuz an artist, way back, when).
But accessibility is critical. There are tools to do things like desaturate pages and apps, and measure contrast.
I write Apple apps, and I make sure that I provide (sometimes, quite verbose) accessibility labels to all my UI elements. There's actually a ton more that can be done, but acc. labels, and respect for dark mode, reduced transparency, and increased contrast, as well as haptics, is usually sufficient.
One thing about providing accessibility strings: They should be translated, as well, if you are localizing.
Re:UI design for software developers. Part 1, Colors
by KineticLensman on Wednesday November 18, 2020 @04:17PM
(#25142565)
> But accessibility is critical.
Totally agree. I once did some mandatory training at work (on avoiding discrimination, ironically) where some of the facts needed for a good score were only presented in the audio track and were thus inaccessible to deaf people. I'm partially deaf without my hearing aids so am sensitive to this issue.
Another place where I worked had the bays in its car park marked with a colour of brick that was the same as the main colour if you had a certain type of colour blindness. It's actually how most of us found out that one of our colleagues was colour blind, when he got a complaint about his apparently inconsiderate parking (usually taking two spaces because he couldn't see the markings).
Re:UI design for software developers. Part 1, Colors
by preommr on Wednesday November 18, 2020 @10:38AM
(#25137937)
These metric help for writing a report for the boss.
But really, these tools should not be a factor for UI design. They're much better for things like data visualization where you're working wit a lot more colors in a tight space.
If somebody is relying on slight variations in hue to differentiate between background and font color, they've already fucked up.
FWIW, I recommend using the squint test as a really rough metric, try and see if you can use something through your eyelashes as you're squinting.
Re:UI design for software developers. Part 1, Colors
by coldcode on Wednesday November 18, 2020 @08:35AM
(#25136516)
Don't be like Apple did in Big Sur, and reduce all colors to medium gray on light gray backgrounds (arguments I have had with UI designers for years who seem to favorite this combo). Also consider the size of elements when working with color contrast, larger elements are more forgiving than smaller ones, bolder fonts are more forgiving than thin ones. People's ability to see comes in many variations, its not binary (20/10 vision vs sightless).
Re:UI design for software developers. Part 1, Colors
by TheOtherHobbes on Wednesday November 18, 2020 @09:45AM
(#25137274)
The site has eccentric paragraph/element spacing and uncontrolled use of white space.
Serif fonts are fashionable but a questionable choice for legibility. (HN is much more legible.)
The header image is unnecessarily huge.
There's a login box, but you won't spot it unless you're paying attention. Why would you want to log in anyway?
Overall, the design looks knocked-together in a hurry with no real understanding of either good layout or UX.
The app itself has poor layout spacing and - ironically - the colour choices and combinations are unusual and not what you would expect from an experienced UI designer.
To be clear, this isn't being picky for the sake of it. I would honestly be surprised if a majority of experienced UI professionals were enthusiastic about the current design of either the site or the app.
Re:UI design for software developers. Part 1, Colors
by monkin on Wednesday November 18, 2020 @09:22AM
(#25137028)
I don’t have time for argument war, but same thing is with coding/vim/emacs/everything other courses on youtube from people that just started to learn them.
If you’re learning and trying to learn others at the same time will you take responsibility for passing on bad knowledge and your own mistakes? It takes years to get solid grasp of professional wisdom and experience in specific field. Without it, we have people who think git is too hard...
If you want to learn, learn from the best. Don’t get me wrong, I know that many people advise to write such thing to make yourself recognizable, but don’t start from learning others. :)
Re:UI design for software developers. Part 1, Colors
by layoutIfNeeded on Wednesday November 18, 2020 @12:31PM
(#25139607)
>same thing is with coding/vim/emacs/everything other courses on youtube from people that just started to learn them.
Spot on! I think we need a concise name for this phenomenon of low-effort rookie-level tutorials from people who barely have learnt the subject themselves.
How should we call it? Tutorial-spam? Tutorial farming? Amateutoring?
Re:UI design for software developers. Part 1, Colors
by KineticLensman on Wednesday November 18, 2020 @04:19PM
(#25142588)
They say that the best way to learn something is to teach it, but it doesn't follow that the experience will be optimal for your students. Teaching well is quite hard.
Re:UI design for software developers. Part 1, Colors
by inquirerofsorts on Wednesday November 18, 2020 @06:29AM
(#25135601)
UX advice for UI designers giving advice to software developers: Get a free cert from https://letsencrypt.org/ so my basic half-assed digital defenses don't block your site.
I'm not clicking through until you do sorry. Good luck with the multipart series.
Re:UI design for software developers. Part 1, Colors
by dmitshur on Wednesday November 18, 2020 @09:03AM
(#25136822)
I’m not the parent poster, but one reason I can suggest is:
When you know about the security properties of using the HTTP protocol over internet, and proceed to visit a read-only plain-HTTP website, your attention and time are used up unnecessary on thoughts like “did the author really include this bit of content, or is it being MITM’ed?” with no inexpensive way to find out.
Re:UI design for software developers. Part 1, Colors
by mch82 on Wednesday November 18, 2020 @09:46AM
(#25137290)
Thanks for taking the time to share a write up on something you learned & put it on your own domain instead of Medium or something like that.
Yeah, ssl probably matters & other people will prefer a different “step 1”, but it’s cool to see people share their lessons learned & process. And it’s smart to make use of the byproducts of your work.
Many designers use a “mood board” early in their process to establish the target feel of their project. Your explanation of wanting to choose a color that felt “futuristic and brave” reminded me of that approach.
https://en.wikipedia.org/wiki/Mood_board
Re:UI design for software developers. Part 1, Colors
by capableweb on Wednesday November 18, 2020 @07:44AM
(#25136119)
As far as I know, Let's Encrypt themselves do nothing to prevent you from hitting the expiry date with your certificates, but then I'm not sure what you mean with "Out of the box Let's Encrypt".
Usually you run Let's Encrypt with something like EFF's certbot, and then you certainly get lots of help to have up-to-date certificates, as long as you installed it in a way so it automatically runs (via cron or whatever you use).
Re:UI design for software developers. Part 1, Colors
by sjm-lbm on Wednesday November 18, 2020 @11:23AM
(#25138606)
I get emails from LE when my certs are about to expire. I'm honestly not sure how they do it (based on the email address, I'm guessing that they pulled the email they are using from WHOIS), but it's not something I went out of the way to set up.
I really like it, because it lets me know when I need to go in and kick certbot.
Re:UI design for software developers. Part 1, Colors
by Cthulhu_ on Wednesday November 18, 2020 @07:49AM
(#25136155)
I've used LE for a few years and multiple times Certbot has broken, needed to be reinstalled, reconfigured from scratch, etc. In theory it keeps things updated automatically, in practice it needed a lot of wrangling.
Re:UI design for software developers. Part 1, Colors
by capableweb on Wednesday November 18, 2020 @07:29AM
(#25136020)
Or if the author don't want to let Cloudflare control their entire domain and give away their users' data, since the author seems to self-host with nginx: Use certbot and python-certbot-nginx, very easy to setup and maintain
Re:UI design for software developers. Part 1, Colors
by baxtr on Wednesday November 18, 2020 @07:25AM
(#25135992)
The best resource I have found for devs who want to improve their design skills is (1). The article below is even about coloring schemes of apps. Very insightful.
Re:UI design for software developers. Part 1, Colors
by kevsim on Wednesday November 18, 2020 @07:29AM
(#25136021)
I've had going through RefactoringUI on my todo list for a very long time. I'm working at a small startup [0] on a fairly complex product and design resources is always a challenge. Being able to make some of the simple decisions myself feels like it could be a super power.
Re:UI design for software developers. Part 1, Colors
by nottorp on Wednesday November 18, 2020 @01:53PM
(#25140768)
> Common advice here will be not to use pure black or white colors, which, as perfectly described in the article, hardly present in the real-world color pallet.
However, on the OLED screens that are all the rage now, and for good reason, a pure black background means those pixels are off, which saves power and shines less light into the user's eyes making the screen less tiring.
Aesthetics aren't always good for your health/battery.
Re:UI design for software developers. Part 1, Colors
by WoodenChair on Wednesday November 18, 2020 @07:15PM
(#25144552)
I can second this recommendation. It was recommended to me years ago by an experienced app developer. Don’t be turned off by its use of print examples—most of the general ideas can just as well apply to the digital.
Re:UI design for software developers. Part 1, Colors
by jorams on Wednesday November 18, 2020 @08:10AM
(#25136329)
If the result of that calculation is 9px for you, your browser's default font is set to ~7px. That's even smaller than Chrome's "Very small" preset of 9px, and significantly smaller than the normal default of 16px.
Re:UI design for software developers. Part 1, Colors
by kuon on Wednesday November 18, 2020 @07:31AM
(#25136042)
If you need to deal with colors, especially dynamic ones, you might be interested on my writing¹ about HSLuv, which can help a lot in generating palettes.
Re:UI design for software developers. Part 1, Colors
by renke1 on Wednesday November 18, 2020 @07:11AM
(#25135902)
I always thought this is a good article about color palettes [0]. I haven't read the book (on which the article is based on) yet though, but it might be worth a look (maybe someone has?).
Re:UI design for software developers. Part 1, Colors
by Benjammer on Wednesday November 18, 2020 @09:07AM
(#25136855)
I learned a quick tip recently to easily implement a nice-looking dark mode without picking a whole new color palette. You can just take your regular colors and desaturate them and they will instantly look better in dark mode. If you don't understand saturation, think of it like using the "pastel" version of each color.
Re:UI design for software developers. Part 1, Colors
by joduplessis on Wednesday November 18, 2020 @09:24AM
(#25137051)
Color, typography & design - in the context of user interfaces - is hard! Understanding color is great, but how that color relates to a user interface: totally different story.
Second this author is basing the advice on this app: https://play.google.com/store/apps/details?id=net.amortizedc...
Again I am not an expert and I don't mean to be rude, but that's not a very nice looking app in my opinion. The colors, fonts, alignment, spacing, etc all seem just a bit "off".
Even though this is about infographics, there is a lot of useful information here: https://blog.datawrapper.de/beautifulcolors/
Wording is sloppy, too ("into an email attachments"?).
"into an email attachments" doesn't agree on number--it should be "into an email attachment" (singular) or "into email attachments" (plural).
It's not 100% clear that by "shrink" you mean "reduce file size" rather than "visually scale the image".
"Batch image resizer which will make photos smaller enough to fit them all into email attachments. In three easy steps."
Don't use the comparative form of the adjective "small". "Which" is not needed here either.
"Batch Image Shrinker reduces the file size of a group of images in three easy steps:"
That's a start at least. I hope that helps a bit.
i also kind of feel like your comments distill down to something very close to:
"there's no right way to do it, but that way is wrong"
design is inherently subjective. no single tool will seem "right" to everyone, and that's ok.
It's a really common misconception among technical folks that "subjective" == "arbitrary".
Design is inherently subjective, yes. But that does not mean that all design choices are equally good when goodness is measured by pleasing the greatest quantity of users by the greatest amount.
Ice cream flavor preference is subjective too, but if your ice cream shop only sells "sawdust sprinkles" and "frog's blood", business isn't going to go well for you. Or, perhaps closer to home, the choice of keywords in a programming language is entirely subjective. The compiler does not care if you use "while" or "rkdhx" for loops, but good luck convincing programmers to adopt a language that chooses the latter.
Designers have laboriously learned the aesthetic principles that align with how our visual system works and with the expectations users have coming from our shared culture's graphic history. That's what they mean when they say something is "right" or "wrong", and they have a lot of expertise to back it up.
But who is advancing all those arguments you are refuting?
They are all straw men.
As someone mentioned in this thread, look up US WDS advice on color. It’s a lot more objective.
This is pretty ridiculous. The web is such a hack already, and deprecating this make it even worse at UIs. It seems every decision is optimised for branding (e.g. custom form controls), usability be damned.
https://www.w3.org/TR/2018/REC-css-color-3-20180619/#css2-sy...
Earlier versions of CSS defined several additional system colors. These color keywords have been deprecated, however, as they are insufficient for their original purpose (making website elements look like their native OS counterparts), represent a security risk by making it easier for a webpage to “spoof” a native OS dialog, and increase fingerprinting surface, compromising user privacy.
https://www.w3.org/TR/css-color-4/#deprecated-system-colors
The explanation explictly says that the original functionality was a spoofing security risk, but even so was “insufficient for their original purpose (making website elements look like their native OS counterparts)”. So, no, they've fairly explicitly abandoned the original purpose.
They retained functionality has a more limited purpose, which I would describe as providing a vehicle for the user/browser/OS to provide defaults which pages/apps can reference, which when provided by the OS, minimize aesthetic clash and preserve contrast/accessibility between the page/app features and native UI without disguising the nature of the web page/web app, rather than actually mimicing native system UI.
It has one of the best discussions of contrast I have seen; very timely given the trends for low contrast design that seem prevalent combined with my now over 40 eyes (darn those kids!)
I'm a decade younger than you and I still bristle every time I see someone disparage black-on-white. #000 on #FFF looks fine, guys, and it looks way, way better than the #BBB on #CCC that you're about to publish. You're overthinking it.
Black and white, but take the edge of a little.
It's honestly pretty cool to see this. I'm glad that the US government (or at least this one particular agency) takes accessibility so seriously.
In every real world scenario there will be a multitude of colors present that impact accessibility. It is almost never so simple as a single text color on a single background color.
But accessibility is critical. There are tools to do things like desaturate pages and apps, and measure contrast.
I write Apple apps, and I make sure that I provide (sometimes, quite verbose) accessibility labels to all my UI elements. There's actually a ton more that can be done, but acc. labels, and respect for dark mode, reduced transparency, and increased contrast, as well as haptics, is usually sufficient.
One thing about providing accessibility strings: They should be translated, as well, if you are localizing.
Here's a really cool tool, that I use: https://michelf.ca/projects/sim-daltonism/
Totally agree. I once did some mandatory training at work (on avoiding discrimination, ironically) where some of the facts needed for a good score were only presented in the audio track and were thus inaccessible to deaf people. I'm partially deaf without my hearing aids so am sensitive to this issue.
Another place where I worked had the bays in its car park marked with a colour of brick that was the same as the main colour if you had a certain type of colour blindness. It's actually how most of us found out that one of our colleagues was colour blind, when he got a complaint about his apparently inconsiderate parking (usually taking two spaces because he couldn't see the markings).
But really, these tools should not be a factor for UI design. They're much better for things like data visualization where you're working wit a lot more colors in a tight space.
If somebody is relying on slight variations in hue to differentiate between background and font color, they've already fucked up.
FWIW, I recommend using the squint test as a really rough metric, try and see if you can use something through your eyelashes as you're squinting.
it sucks to readjust the app if you discover late in the development that the palette is not having enough contrast for some parts of the ui.
Serif fonts are fashionable but a questionable choice for legibility. (HN is much more legible.)
The header image is unnecessarily huge.
There's a login box, but you won't spot it unless you're paying attention. Why would you want to log in anyway?
Overall, the design looks knocked-together in a hurry with no real understanding of either good layout or UX.
The app itself has poor layout spacing and - ironically - the colour choices and combinations are unusual and not what you would expect from an experienced UI designer.
To be clear, this isn't being picky for the sake of it. I would honestly be surprised if a majority of experienced UI professionals were enthusiastic about the current design of either the site or the app.
If you’re learning and trying to learn others at the same time will you take responsibility for passing on bad knowledge and your own mistakes? It takes years to get solid grasp of professional wisdom and experience in specific field. Without it, we have people who think git is too hard...
If you want to learn, learn from the best. Don’t get me wrong, I know that many people advise to write such thing to make yourself recognizable, but don’t start from learning others. :)
Spot on! I think we need a concise name for this phenomenon of low-effort rookie-level tutorials from people who barely have learnt the subject themselves.
How should we call it? Tutorial-spam? Tutorial farming? Amateutoring?
I'm not clicking through until you do sorry. Good luck with the multipart series.
When you know about the security properties of using the HTTP protocol over internet, and proceed to visit a read-only plain-HTTP website, your attention and time are used up unnecessary on thoughts like “did the author really include this bit of content, or is it being MITM’ed?” with no inexpensive way to find out.
Yeah, ssl probably matters & other people will prefer a different “step 1”, but it’s cool to see people share their lessons learned & process. And it’s smart to make use of the byproducts of your work.
Many designers use a “mood board” early in their process to establish the target feel of their project. Your explanation of wanting to choose a color that felt “futuristic and brave” reminded me of that approach. https://en.wikipedia.org/wiki/Mood_board
Usually you run Let's Encrypt with something like EFF's certbot, and then you certainly get lots of help to have up-to-date certificates, as long as you installed it in a way so it automatically runs (via cron or whatever you use).
I really like it, because it lets me know when I need to go in and kick certbot.
- https://www.nginx.com/blog/using-free-ssltls-certificates-fr...
(1) https://refactoringui.com/previews/building-your-color-palet...
0: https://kitemaker.co, super fast, highly collaborative issue tracker
However, on the OLED screens that are all the rage now, and for good reason, a pure black background means those pixels are off, which saves power and shines less light into the user's eyes making the screen less tiring.
Aesthetics aren't always good for your health/battery.
The contrast is bad for your eyes, not the total amount of light, which your pupil can adjust for.
Proximity, alignment, repitition, and contrast are four basic principles that get you pretty far.
https://www.amazon.com/Non-Designers-Design-Book-4th/dp/0133...
https://github.com/sw-yx/spark-joy#courses
EDIT: I misread Firefox's calculation. Checking again it doesn't say 9px but 16.25px. I guess I just have tired eyes today!
I'd say that's on you.
1: https://www.kuon.ch/post/2020-03-08-hsluv/
[0]: https://refactoringui.com/previews/building-your-color-palet...
(edit: add lines below)
They even have guidelines for designing with luminance contrast: https://colorusage.arc.nasa.gov/design_lum_0.php
https://contrastrebellion.com
It gives you shades & tints, has a Color Blindness Simulator, nearest web safe color and more.
https://hackdesign.org/