And before we continue, let’s make it absolutely clear that we have no control of the color of the text in this very article, as it is hosted through Medium.com, which features poor visual accessibility of their site design.
Why is it used then? Put your actions where your mouth is and don’t use it.
The thing is, Medium doesn’t feature poor visual accessibility of their site design. Virtually every Medium article renders great in Reader Mode on Safari or Chrome, which lets you choose the font, font size, and contrast pretty easily.
If only there were some kind of style sheet, that could cascade in priority depending on where it was defined.
There’s no reason for this to be handled by the developers of every single website. This should be handled by the browser. If a user wants high contrast mode, there’s absolutely no reason there can’t be a setting on the client that forces text to a high contrast setting. It’s just numbers in a configuration file. Those numbers can be changed, automatically.
I wish there was some way of saying to browsers, “use modern defaults; I don’t care what they are, or if they change over time; I won’t touch the style; just make the page look good based on the semantic markup.”
There are generic Firefox addons like this but they are generally quite CPU hungry.
I end up just doing:
disabling all custom or web fonts
setting minimum font size to 12
setting default zoom level to 120 %
For web apps that I need to use for work (Outlook web app, Jira, &c.) that have bad contrast, I do try to add custom style sheets to fix some text that’s still unreadable to me after all this.
For articles, I can generally use “reader mode” that does switch to black-on-white, since, you know, that’s the best for reading, but that’s generally not helpful on web apps.
In short, I’d be very happy if it was practical to make a stylesheet or plugin to do this, but currently I would say it’s not, or someone would have made one already.
It seems unlikely ranting at web developers will help with this, so I think it would need to be fixed in browsers, However, I see that as an unlikely development, given that e.g. disabling custom fonts is becoming harder and harder, with for example Firefox for Android removing the ability to disable custom fonts.
This is the reality. Firefox has allowed, and continues to allow, forced colors. Go to about:preferences -> Colors, and activate “Manage Colors”. In the menu that pops up, set your preferred colors and set the “Override the colors specified by the page with your selections above” pref to “Always”. This feature is a lifesaver for me, as I deal with overstimulation and can’t stand having a new palette thrown at me every time I open a new page. It’s also replaced my dark mode addon; anything that gets rid of privileged addons is a win in my book.
On Windows, you can enable this system-wide with High Contrast mode. Contrary to the name, WHCM isn’t necessarily for high-contrast themes; you can set any palette you want. Every decent program will then receive a forced palette.
I would like to use this, but it’s regrettably not practical. As an example it prevents me from seeing the upvote arrow on your comment, and whether I’ve voted already.
This is something that browsers (all 3? 4? of them) can improve, though, rather than asking a billion web content creators to behave nicely towards any of hundreds of access concerns.
You could, but then you get extra-lower-brightness for other apps/pages which don’t buy into the white/black idea. I don’t think we’ll get the perfect solution either way.
And even if you adjust brightness, it can be a bad experience. I don’t get any actual health/sight issues from brightness or high contrast, but even with everything turned down to minimum on my phone, that medium post is tiring to read because of the white background.
Only if you can adjust all screens to both go down in brightness low enough and without destroying the colour accuracy.
We’ve got a system with at least 3 interdependent elements in it (defaults, preferences, design ideas, hardware capabilities, accessibility limits, …) - you can’t just point so one of them and say that causes all the problems. (Well, you can, but that’s oversimplification and doesn’t solve any issue)
…and I immediately had to flip that article into reader mode in order to read it. Which is not to say it’s wrong, but the contrast between the author’s experience and mine is illustrative, and one-size-fits all probably just isn’t going to work here. As she points out there are media queries, but:
@fly suggested in another comment here that this really should just be the browser’s responsibility, not the page’s, and I agree. For articles I tend to flip into reader mode at the first sign of trouble, but for apps I don’t really have that option. But for desktop apps developers mostly don’t have different styles of buttons; they just use the OS’s widget toolkit and accept what the OS vendor has decided. (of course, that’s changing as everything seems to be electron these days anyway…)
This is one reason why the APCA (next generation contrast algorithm) recommends against excessively high contrast, especially for dark themes.
It’s not just halation and migrations: overstimulation is another issue that I personally experience quite a bit. Foreground colors that have excellent contrast against dark backgrounds, like yellow, can cause overstimulate if they’re not appropriately de-saturated.
Special palettes that respond to media queries requesting dark/light schemes and more/less contrast are good, but I believe that defaults should also be as accommodating as we can make them; not everyone is okay with the fingerprinting potential of all these media queries. An APCA contrast of ~90 LcP seems to do the trick. You can go lower if you bump up the font size to compensate.
The goal of accessibility design is not making things “great [for] everyone”. It is ALLOWING people to make things great FOR THEM. Some users will have needs that require high contrast. Some users will have needs that require high contrast. Others won’t particularly care at all, and just want things to be pretty. Others don’t care about the contrast because they’re using a screen reader.
You can’t make things accessible by choosing colors. We have to enable users to configure their interfaces with the colors that they, personally, need or want. This has to be done largely at the browser level, although of course stuff like clear, semantic HTML that doesn’t use clever tricks to do things purely visually is a big part of the ask. But developers shouldn’t be forced to worry about colors. We should be forced to worry about allowing browsers to configure those colors.
Agreed. I think a better message here would be “use grey text responsibly”.
I often set body text to 65–75% opacity and reserve 100% opacity for headings, etc. It helps build visual hierarchy while retaining a good amount of contrast. This produces both a nice appearance as well as readable content.
Why is it used then? Put your actions where your mouth is and don’t use it.
The thing is, Medium doesn’t feature poor visual accessibility of their site design. Virtually every Medium article renders great in Reader Mode on Safari or Chrome, which lets you choose the font, font size, and contrast pretty easily.
As usual with accessibility, going really hard in one direction is often not great site everyone. Here’s another article about why you really want to keep grey / lower contrast for accessibility reasons: https://blog.tiia.rocks/web-apps-why-offering-a-low-contrast-mode-makes-you-more-accessible-not-less
If only there were some kind of style sheet, that could cascade in priority depending on where it was defined.
There’s no reason for this to be handled by the developers of every single website. This should be handled by the browser. If a user wants high contrast mode, there’s absolutely no reason there can’t be a setting on the client that forces text to a high contrast setting. It’s just numbers in a configuration file. Those numbers can be changed, automatically.
I wish there was some way of saying to browsers, “use modern defaults; I don’t care what they are, or if they change over time; I won’t touch the style; just make the page look good based on the semantic markup.”
could this be accomplished with a stylus style sheet or something similar? maybe an addon that just removes all style tags and links to style tags?
There are generic Firefox addons like this but they are generally quite CPU hungry.
I end up just doing:
For web apps that I need to use for work (Outlook web app, Jira, &c.) that have bad contrast, I do try to add custom style sheets to fix some text that’s still unreadable to me after all this.
For articles, I can generally use “reader mode” that does switch to black-on-white, since, you know, that’s the best for reading, but that’s generally not helpful on web apps.
In short, I’d be very happy if it was practical to make a stylesheet or plugin to do this, but currently I would say it’s not, or someone would have made one already.
It seems unlikely ranting at web developers will help with this, so I think it would need to be fixed in browsers, However, I see that as an unlikely development, given that e.g. disabling custom fonts is becoming harder and harder, with for example Firefox for Android removing the ability to disable custom fonts.
https://github.com/jayesh-bhoot/enforce-browser-fonts is an add-on that disables custom fonts, and it works quite nicely on Firefox for Android if you’re using Nightly or F-Droid that supports custom add-ons.
This is the reality. Firefox has allowed, and continues to allow, forced colors. Go to about:preferences -> Colors, and activate “Manage Colors”. In the menu that pops up, set your preferred colors and set the “Override the colors specified by the page with your selections above” pref to “Always”. This feature is a lifesaver for me, as I deal with overstimulation and can’t stand having a new palette thrown at me every time I open a new page. It’s also replaced my dark mode addon; anything that gets rid of privileged addons is a win in my book.
On Windows, you can enable this system-wide with High Contrast mode. Contrary to the name, WHCM isn’t necessarily for high-contrast themes; you can set any palette you want. Every decent program will then receive a forced palette.
I would like to use this, but it’s regrettably not practical. As an example it prevents me from seeing the upvote arrow on your comment, and whether I’ve voted already.
This is something that browsers (all 3? 4? of them) can improve, though, rather than asking a billion web content creators to behave nicely towards any of hundreds of access concerns.
Yeaaah…I used to be a fan of the lobste.rs interface before I started learning about accessibility. This is far from the only a11y issue on this site.
I try to avoid complaining things before filing issues properly and leaving constructive feedback, so here are two I just filed:
Why not just lower the screen brightness?
You could, but then you get extra-lower-brightness for other apps/pages which don’t buy into the white/black idea. I don’t think we’ll get the perfect solution either way.
And even if you adjust brightness, it can be a bad experience. I don’t get any actual health/sight issues from brightness or high contrast, but even with everything turned down to minimum on my phone, that medium post is tiring to read because of the white background.
So it actually is low contrast that causes the problem.
Only if you can adjust all screens to both go down in brightness low enough and without destroying the colour accuracy.
We’ve got a system with at least 3 interdependent elements in it (defaults, preferences, design ideas, hardware capabilities, accessibility limits, …) - you can’t just point so one of them and say that causes all the problems. (Well, you can, but that’s oversimplification and doesn’t solve any issue)
…and I immediately had to flip that article into reader mode in order to read it. Which is not to say it’s wrong, but the contrast between the author’s experience and mine is illustrative, and one-size-fits all probably just isn’t going to work here. As she points out there are media queries, but:
@fly suggested in another comment here that this really should just be the browser’s responsibility, not the page’s, and I agree. For articles I tend to flip into reader mode at the first sign of trouble, but for apps I don’t really have that option. But for desktop apps developers mostly don’t have different styles of buttons; they just use the OS’s widget toolkit and accept what the OS vendor has decided. (of course, that’s changing as everything seems to be electron these days anyway…)
This is one reason why the APCA (next generation contrast algorithm) recommends against excessively high contrast, especially for dark themes.
It’s not just halation and migrations: overstimulation is another issue that I personally experience quite a bit. Foreground colors that have excellent contrast against dark backgrounds, like yellow, can cause overstimulate if they’re not appropriately de-saturated.
Special palettes that respond to media queries requesting dark/light schemes and more/less contrast are good, but I believe that defaults should also be as accommodating as we can make them; not everyone is okay with the fingerprinting potential of all these media queries. An APCA contrast of ~90 LcP seems to do the trick. You can go lower if you bump up the font size to compensate.
Typo: s/migrations/migraines/
s/cause overstimulate/overstimulate/
The goal of accessibility design is not making things “great [for] everyone”. It is ALLOWING people to make things great FOR THEM. Some users will have needs that require high contrast. Some users will have needs that require high contrast. Others won’t particularly care at all, and just want things to be pretty. Others don’t care about the contrast because they’re using a screen reader.
You can’t make things accessible by choosing colors. We have to enable users to configure their interfaces with the colors that they, personally, need or want. This has to be done largely at the browser level, although of course stuff like clear, semantic HTML that doesn’t use clever tricks to do things purely visually is a big part of the ask. But developers shouldn’t be forced to worry about colors. We should be forced to worry about allowing browsers to configure those colors.
Agreed. I think a better message here would be “use grey text responsibly”.
I often set body text to 65–75% opacity and reserve 100% opacity for headings, etc. It helps build visual hierarchy while retaining a good amount of contrast. This produces both a nice appearance as well as readable content.