This problem is so much bigger than low-contrast pages. Almost all technology of any kind selects in favor of aesthetics over equal access.
I have moderate amblyopia and severe astigmatism. For a frame of reference, I only barely pass the driver’s license vision test when I renew my license (don’t worry I don’t actually drive).
My vision has good days and bad days. My ophthalmologist thinks that I frequently have eye strain from looking at screens which further (temporarily) degrades my vision.
Examples that I’ve run into _in the last 24 hours_.
- Why can’t I choose the colors of web sites and applications?
- Why can’t I choose (and override) the default typefaces on mobile browsers?
- Why can’t I change the default system font for my iPhone or my Mac?
- Why can’t I change the font size in modern video games?
- Why do most desktop applications fall of the edge of the screen below 1080p?
I rely on hacky tools to get by — e.g. momentarily dropping HIDPI or jail breaking devices. No one would want to use technology the way I have to. It sucks and it’s constantly getting worse.
Have you seen the Stylus extension? I have several default styles configured in Stylus. This improves things on the desktop quite a bit. I wish it existed on mobile.
Actually, you can use it on Android, but it does require using Firefox Nightly[1].
That does come with downsides such as Nightly being less stable and installing extensions requiring some extra setup, so it isn't the best choice for everyone. But I myself am using Stylus (which works perfectly fine) and some other not officially supported WebExtensions on mobile this way and can recommend it if you don't mind the downsides.
I used to use Stylus several years ago. Didn't it sell out to another company and start tracking and selling user's data? Or am I thinking of another similar add-on?
Another useful extension is Dark Background And Light Text https://addons.mozilla.org/en-US/firefox/addon/dark-backgrou... . It's a one-button toggle to turn most text and backgrounds into colors you prefer. Great when you run across one of these accursed low-contrast sites.
Yes! Been using DB< for years on Firefox. It also mostly put an end to the glaring bright pages. You control the Default colors for all sites (set in Global Prefs) with five options; all are retained (the options used for already configured pages are listed in GP).
You can also select your own fonts and prevent pages from overriding them. Preferences → Fonts → Advanced → untick “Allow pages to choose their own fonts, instead of your selections above”. I did this a few months ago, and I’ve seen no breakage outside icon fonts, and apparently icon fonts are deader than I thought they were—DuckDuckGo has a few unimportant ones, and beyond that the only ones I’ve seen are Google’s Material Icons font, which uses a ligation technique that’s supposed to make things better but actually makes them vastly worse.
Over all, I’m much pleased by the results of forcing Equity/Concourse/Triplicate.
Given the partitioning of device storage, my understanding is that it's either not possible. I'm not sure the browser itself even supports userContent.css.
Many states will issue "non-driver ID cards" (examples below), which are typically cheaper than a drivers license, but which still involve the same level of proving who you are before you can get one (involving showing passport/birth certificate/bills/whatever)
Because these are relatively uncommon, they will lead to extra scrutiny and hassle in many situations (buying alcohol, showing ID at airport security, etc).
The US does not have federal level ID cards, although the federal government has used funding for state programs as a cudgel to make states comply with standards for how they verify who you are before issuing you an ID ("Real ID").
I think the extent to which "Americans consider voter ID excluding" is highly politicized and debatable.
ID is required for many things. Off the top of my head I've had to show ID to get into bars or buy alcohol, rent a car, drive, doctor visit, picking up kids at school, R rated movies, at the bank, opening a crypto account, opening a Robinhood account, when I need to prove my identity at work - and probably many other times. You need an ID for many random things in life and somehow that's not exclusionary.
I've just googled to see what percentage of American adults have ID and I saw percentages in the high 90's. Though, these survey results are a bit confused with some surveys excluding expired results or being strictly "driver's licenses" versus any government photo ID or counting people who "don't know" or decline to answer as not having ID.
I haven't voted in a long time, but the last time I did - I think they just asked me what my name is and I didn't show any kind of ID. They then check if the name you gave is on their list of voters. If it is, you get a ballot, and they check that name off the list. If it's not you get a provisional ballot and who knows what happens to that.
All this is to say that the politicians who believe voter ID would reduce their share of the vote consider it exclusionary. Politicians who believe voter ID would increase their share of the vote do not.
> I haven't voted in a long time, but the last time I did - I think they just asked me what my name is and I didn't show any kind of ID. They then check if the name you gave is on their list of voters. If it is, you get a ballot, and they check that name off the list. If it's not you get a provisional ballot and who knows what happens to that.
This various by region, but the procedure where I live is that you are registered to vote in a district. When you go to vote you provide your name and, if necessary to disambiguate, an address. The poll worker finds you and checks you off. Then you vote. If two people try to use the same registration, this catches that.
> All this is to say that the politicians who believe voter ID would reduce their share of the vote consider it exclusionary. Politicians who believe voter ID would increase their share of the vote do not.
The voter ID debate does concern whose ox is being gored. The party whose constituents are poorer and less mobile is the party whose voting share will go down with voter ID laws, depending on the law, because acquiring the ID allowed by the law may take travel and expense which is prohibitive to their voters. The argument for ID is that it will prevent in-person voter fraud. The argument against it is that the fraud it will prevent is negligible, the number of people it will disenfranchise is not negligible, and that the actual incidents of voter fraud, or election fraud, that should be prevented are not in-person voter fraud.
TLDR; voter ID laws will decrease participation and the laws can be gamed, by choosing acceptable forms of ID and whatnot, to selectively decrease one party or the other's voter base. Also, there is no evidence that this prevents fraudulent votes swaying elections and there is evidence that it has partisan bias, which will sway elections. A solution: issue a federal ID delivered to voters at no expense. This is not on the table.
When you renew your passport, you can also get a passport card for an extra $30 or something. They're only good for land/sea crossings (no flights) from US to Canada, Mexico, but you can put it in your wallet.
The downside is again that it's non-standard form of ID, but it is a photo ID and may be useful
When I was a teenager my vision was better. It has degraded as I’ve aged.
I do still technically pass the vision test, but I don’t think it tests for impairment from astigmatism very well.
It’s not rational, but I think a big part of keeping my license is anxiety. It’s really challenging to get around in America without driving. Knowing that my license is still valid makes me feel less trapped.
There's absolutely no reason you should forgo the optionality inherent in a driver's license so long as you continue to pass the test.
People need a ride to the hospital all the time, if the state says your vision is up to the task of doing it, why not be available for emergencies? There's no downside.
> isn't there some equivalent to ID card in US not requiring any test?
Most states have something like this. Typically you fill out some forms and pay a fee to get a “State ID”. Just be prepared for people to give you shit about it occasionally when ID’d.
If you’ve already gotten your drivers license in the past though, I don’t see any good reasons to get a new ID vs just renewing the driver license.
> Almost all technology of any kind selects in favor of aesthetics over equal access.
I don't think accessibility should mean that you have to forgoe aesthetics or compactness for those users that don't need the contrast or extra space or whatever so these don't need to be opposed. Instead, provide options for users that do need them and/or integrate with OS or third-party accessibility tools where possible.
> Why can’t I choose the colors of web sites and applications?
I can choose my applications colors under KDE and pretty much everything "native" (Qt and GTK <= 3 apps) will respect those settings. This seems more of a problem in the proprietary ecosystem where each company wants to insist on their own branding.
For websites there are prefers-contrast [0] and prefers-color-scheme [1] media queries that in theory provide some user configurability but they are a) barely exposed to users b) not implemented by most websites and c) very limited. It would be nice if there was a standard way for CSS to refer to system fonts and colors - then again that would also be yet another privacy leak that WILL be used for tracking :|
> Why can’t I change the default system font for my iPhone or my Mac?
You can in other operating systems. Apple has always been about aesthetics first so this this shouldn't really be suprising - not that that excuses Apple from not providing these configuration options.
> Why can’t I change the font size in modern video games?
This has actually become more common for CRPGs now. I guess most less text-heavy games still don't bother. OTOH most new-ish games scale text with the screen resolution. Older games might have fixed absolute font sizes but if they are old enough they also have a fixed (or limited set of) supported resolutions and you need to scale up the whole thing anyway.
> Why do most desktop applications fall of the edge of the screen below 1080p?
Windows is really bad about having fixed-size dialogs everywhere. This is another of those things I like about Qt-based applications - they have always had flexible layouts unless the developer deliberately breaks that.
> 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. Further, Medium prevents their users from selecting black text as a choice. While Medium’s “Fischer-Price-simple” content creation is easy to use, it is also extremely limited, and fails in accessibility in areas beyond color. Perhaps this article can serve as a wake up call regarding this issue.
So - why on EARTH are you publishing there? And for what it's worth, the areas that fail WCAG AA for colour contrast on this page are areas entirely within the control of the publication.
I had this exact thought. Maybe it's just me, but I grow increasingly tired of content published Medium. I'm not really too sure if I can nail down exactly what it is, though. Maybe I am too influenced by Anti-Medium arguments. Idk.
The article points out why AA is not a salient contrast metric, but also not true—in the design page, you have very limited control, and then after leaving the design page, the color you selected are changed and used differently (i.e. the highlight).
Note the licensing note in the repository[1] of the APCA™ index the author’s company[2] promotes:
> The files currently in this repository are presently considered pre-release, and as such do not have a permanent license attached. In this repositiory, all files present are under a time-barred beta license, and intended for use with web-based content only, and not for any other use without written permission.
The non-pre-release stuff[3] offered to W3C is better but still seems to be intended to end up non-FOSS:
> Files in this repository are licensed to the W3/AGWG under their cooperative agreement for use with WCAG accessibility guidelines for web-based content only, and not for any other use.
Similarly, the online calculators[4,5] referenced in the author’s posts (not this one) are
> PROPRIETARY AND NOT LICENSED FOR THIRD PARTY USE.
(The question being, of course, how much of this is copyrightable at all and to what extent these terms are just sowing legal FUD.)
Not that it's relevant to this thread, and I have clarified this elsewhere:
This is destined as open source. The only reason the public beta has a time limited license is to make it clear that the pre-release materials needs to be discarded once it's stable and in release. BECAUSE this is destined to be part of various standards, it is important to prevent "wrong versions" from circulating (to the degree possible) this has already caused problems, hence the current temporary license.
Any developer that wants a longer term license only needs to request it, so that we can have contact and follow through on changes.
> 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.
Sorry, but you don't get to excuse yourself with that. The text/background in your own post is awful, as others have already mentioned. Medium is a notoriously bloated platform, with their ad heavy and JS heavy pages producing a generally poor user experience.
No one is forcing you to use Medium, you could easily use GitHub pages, SubStack, or any number of other, better options. Options that allow you to control your own CSS. By continuing to use Medium, you are saying (basically yelling) that you really don't believe in what you're writing, at least not enough to do anything about it.
I also use GitHub pages, and other sites, and my own independent sites. But, none get the level of readers — this one article on Medium received tens of thousands of reads. For some of the other materials in teh current research, see the catalog at git.myndex.com
Also...always check the readability of type on Windows.
I can instantly tell when a designer is using a Mac and never bothered to check how text renders on Windows. In particular with thin fonts a Mac may render it somewhat legible whilst it completely falls apart on Windows.
To be clear, the author is well-intentioned but wrong.
Nothing is so simple to be just black and white (see what I did there!)
I say this so that other HN users that influence the design of their products don't walk away and start making changes that negatively impact their users.
This has been studies and there is a ton of research. Here are a few with selected excerpts- please read the articles in full!
"white text on black backgrounds creates a visual fuzzing
effect for people with astigmatism called “halation”."
"A research study found that “black text on a
white background overstimulates the OFF ganglion
cells while white text on black background
overstimulates the ON ganglion cells.” This finding
means that “white text from a black screen could
inhibit myopia, while black text on white background
may stimulate myopia.” The study advises against
reading black text on a white background due to
the striking effects of contrast polarity."
Read the whole article, though. The author does not advocate for pure black text on a white background on a screen.
Your sources cite the useful study concluding that pure black text on a pure white background on a screen causes eye strain for folks like me with astigmatism. The uxmovement site, however, jumps to the conclusion that black text on a white background is the worst configuration and anything else that gets a good WCAG contrast rating is better, and sufficient for readability. That's unsupported, seemingly false, and the topic of this article. Their asserting the grey-on-white text in their graphic is more readable than the black-on-white is patently absurd.
The appropriate way to decrease contrast is by tinting the background but leaving the text towards the extreme. The author argues that the current WCAG method of determining contrast without considering other factors such as leading, tracking, type size, etc. gives passing scores to inaccessible results, and more recent methodologies are much more accurate, especially in dark mode.
Your first two links seem to be about contrast polarity, not contrast ratios. (There is a mention of using low-contrast text in the second link, but it is not very good advice in the era of selectable light/dark mode. Those with astigmatism will tend to avoid dark mode, so the "hack" of using grey-on-grey to limit halation is not needed.)
The latter link provides some sources, but not much experimental evidence.
Yes thank you, this particular article was not at all about dark mode vs light mode -in fact it was mostly about light mode, with dark text.
The fact the article is currently displayed in dark mode is that medium really messing things up unless you set the page to #fff, which is visually fatiguing.
Nowhere in the article did I advocate for black and white — and far from that.
This article is part of research I am doing on readability contrast.
Also, "uxmovement" is about the last place to be taking advice on the subject.
Nevertheless, The subject is much more nuanced, but articles like the one you linked lead to misunderstanding.
Spatial frequency is critical, and it is spatial frequency that is the driver of contrast perception for smaller stimuli, particularly for small thin body text, where luminance contrast needs are substantially higher than for large bold headlines.
For those who have this kind of issue you should try out darkreader. Aside from doing a great job of dark mode for any website, the customisation allows you to fix the shitty contrast on most websites so that you dont get headache from reading it.
I've seen speculation that grey may be selected as may mock-up tools default to a greyed "Greeked" text, or just grey lines, as placeholders for actual textual content.
When it comes time to install the actual payload, it's presumed / assumed that grey is the text colour, or everyone (designers, reviewers, project owners / managers) are so used to the (non-semantic, incidental) placeholder representation that an unreadable text is simply accepted or presumed as the intent.
There are less charitable interpretations as well.
One fix would be to insist on high-constrast text in all phases of the design process. Yes, it will be visually distracting, but text should be your principle asset and intention.
Why would you use a different color for the placeholder text in the first place - the whole point of having you design filled with lorem ipsum instead of empty space is to see how it would look with real content.
So why are designers resorting to lighter and lighter text? When I asked designers why gray type has become so popular, many pointed me to the Typography Handbook, a reference guide to web design. The handbook warns against too much contrast. It recommends developers build using a very dark gray (#333) instead of pitch black (#000).
The theory espoused by designers is that black text on a white background can strain the eyes. Opting for a softer shade of black text, instead, makes a page more comfortable to read. Adam Schwartz, author of “The Magic of CSS,” reiterates the argument...
> in 2005, prior to WCAG 2, major websites such as CNN, Yahoo, About, and Wired used black text. Not long after WCAG 2 was adopted, those same sites were reducing contrast, moving to ever lighter grey texts.
Correlation is not causation.
Possible alternative version of this history: WCAG came out with its recommendations when it did precisely because trends in design at the time were towards using different font weights and colors, as cleartype rendering was becoming universal and displays were moving away from CRT to LCD and becoming higher resolution. (LCD monitor sales only surpassed CRT monitors in 2003. The concept of a 'retina display' dates to 2010.)
In the absence of WCAG contrast guidance, the wild west would have won. Instead, by putting a line in the sand for contrast, WCAG helped ensure that design trend was held in check.
Also, why don't we let users decide which contrast works best for them?
My https://wordsandbuttons.online/ uses default browser colors for anything other than interactive illustrations. For those, I just don't know how to make user choice work with the graphics they show since the graphics is always different from picture to picture, so I impose slightly tinted background as part of the palette.
Unfortunately the default browser colours for the web are always black text on white background and do not respect the user's desktop theme, be it dark or something else.
My job for the last decade has been to facilitate accessibility.
Not only have I never heard of this control existing in native Chrome, I can't figure out how to do it. I'm doubtful, then, that we can consider this a remedy of any kind for accessibility issues.
My hunch is that you mean that there are extensions that provide this – which I definitely have issues classing as "browsers providing" much in the way of anything.
Your hunch is incorrect. Perhaps they have removed this functionality, I haven't checked, but this historically is functionality that was used to change the default background/text colors of all pages, built in to the browser.
Hm... Perhaps you're misremembering? I'll be fairly surprised if this was ever in Chrome, for a few reasons. When do you know that this last existed?
Closest thing I can find are custom user stylesheets – which were removed in 2014 (also not sure if "write some CSS" is an a11y solution, heh): https://codereview.chromium.org/66383005/
I know at least firefox at one point used the system default background and text colors. This of course worked horribly as many websites (including Google at some point) would override the background or text color with a custom value and not the other assuming that the user would be using the default theme on Windows (or just not caring), which left you with dark grey text on dark background on many websites if you used a dark system theme.
I do agree the the actual point that the default colors have nothing to do with user preference though.
Contrast rules, font sizes, colours and contrast, button spacing and size all depend on way too many things to have an one-size-fits-all solution. There simply isn't one, some people learned it a while ago (https://www.thestar.com/news/insight/2016/01/16/when-us-air-...).
I don't want forced contrast or font size that's suitable for people with eyesight issues the same way people with eyesight issues don't want my dark theme or zoom level.
Website makers should learn to design for all, but not for everyone at the same time.
One should say very clearly that black on white—#000000 on #ffffff—is a poor choice except on poor displays or in poor viewing conditions. Much better is a lightly greyish or ever-so-slightly yellowish/brownish background with a less than fully saturated black for the text. Printers have known this all along.
Edit—author says so in his article. FWIW I might add that while my terminal emulator and my text editor both use light on dark color schemes, the way to make that work is to reduce contrasts. The most horribly eye straining web sites use incredibly harsh contrasts. I can work for many hours in both apps before getting anywhere near the condition that many 'dark mode' web sites can cause in a minute or so.
I really wish there were two "white" values that were software accessable. To comfortably read black on white text, I turn my backlight down, but to watch a movie, I turn it up. This makes sense because, presumably, the brightest thing in a movie will be brighter than a piece of paper...
So basically you want movies to be treated as high-dynamic range content while most applications are treated as having a lower dynamic range so #FFFFF will not be the max brightness of your monitor. I think this is the direction we are moving in with HDR monitors and may already be how some operating systems work (except maybe the part of treating non-HDR movies as having a higher dynamic range than standard applications).
I don't have HDR content nor HDR displays, so, I suppose I want something lower than standard (LDR?) for "office" content, and I want the lower dynamic range to be accomplished by lowering the maximum brightness.
I first noticed this with some video games (Maybe Hexan or Quake?) versus Word 2.0; however, back then my monitor had brightness and contrast knobs on the front so it was trivial to switch (IIRC, brightness adjusted black-level, contrast adjusted white-level).
Thank you for the feedback... I change the scheme regularly, as part of a series of user experience experiments. It's currently in Dark Mode because Medium's current restrictions on light mode made the article unreadable. (That is, choosing any color other than #fff for the background and Medium made the text so light grey it could not be read).
An article about computer text with no reference to Apple's influence? Computers used to be green or white text on black backgrounds. You know who changed that? Apple. Their push for "It looks like it will when printed", that culminated with those silly rotating CRT screens, caused the shift to black-on-white. That marketing was also appealing for schools where students were expected to print assignments. Microsoft then followed along. The net result was decades of needless eyestrain for billions of people.
I cringe every time I see someone open a black-on-white document up on a projector. White-on-black is infinitely easier to read in almost all conditions.
Hackernews is worse in this regard, yet little mention ever.
Downvote me and see - this comment fades into contrast-obscurity.
Downvoted comments turning grey/on greyer is beyond dumb, adding another UI-bezel on top of the pile of shit that is popular (>51%) opinion echo chamber.
Reddit hides comments via minimizing. Hackernews literally makes it more difficult to read.
anyone else notice the lack of outrage? it's the worst conceivable way of dealing with this.
it has, though, made me think about how contrasting/conterverial/more useful discussion chains get presented, at a UI level, and how that affects further participation.
I emailed dang about this once, though I didn't find the reply terribly illuminating:
> I think the original intention was probably to de-emphasize the top text a little, relative to the comments below, so it doesn't come across as so authoritative. But that's just a guess. I agree that it's low-contrast. I'm reluctant to mess with the existing design, but we'll think about it.
I like fading garbage comments, it is a quick visual indicator there's probably nothing of value in that comment. Rarely good comments are greyed, and in those cases I upvote to try to counter-act it. Doesn't seem like a problem to me.
> Downvote me and see - this comment fades into contrast-obscurity.
50/50 chance you get an upvote instead because the buttons are so small and close together on mobile. This is where I really like the Apollo app for Reddit. On it, you swipe left or right on the comment to access actions like reply, upvote, downvote. Similar concept in a lot of mobile mail clients for archiving or deleting.
It's a third party app. It's also the difference between trying to click a small button versus using a swipe gesture. You still have to write the reply. Not sure what your gripe is here, I'm talking about how their UI is more friendly towards mobile users.
Jan Tschichold, a famous typographer and book designer speaks against black on white. He says that the book paper should not be artificially whitened since too much contrast hurts readability just as too little.
I'm a contrast junky. Can't stand modern IDE and editor colorschemes like solarized because they're too vague and murky. Give me strong colours god damn it.
I have my custom theme for the 16 terminal colors, as tempus doesn't handle well dark <color>/light <color> contrast with the same <color>, and some terminal applications like to do that... But I'm not fully happy with my custom theme yet, the dark colors are too dark.
Agreed. I also set up my IDE (Jetbrains) so that it switches between light and dark themes according to my system preferences (which reflects available daylight)
Because reading code on a light theme is so much easier on the eyes during daytime. I don't understand why "coders" insist on dark mode everywhere all the time.
Anyone interested in readability and accessibility should look at the ‘modus-themes’ (emacs) by Protesilaos Stavrou [1]. They’re highly accessible and highly readable themes, with complete and thorough documentation and commentary on the design choices. His website should also serve as a benchmark for readability.
Simply because they’re inerested. If they’re not interested they won’t… want to read it, you pedant. It’s very obviously in the domain of accessibility and design, so may interest people who care about that.
I can say it has been immensely helpful reading through the comments here and I thank you all for your input. If you want to read further regarding the readability research project, there's a catalog of resources and further articles at:
In general: when reading, one may normally want to maximize contrast while minimizing "beamed" luminosity (meaning, the amount of light made to directly hit the eye).
That is for eye comfort.
So, yes: we adjust text for maximum contrast (#000 to #FFF) and adjust the light accordingly. This is expected behaviour.
Which, by the way, is also in general energy efficient.
I do prefer #000 over #FFF (or vice-versa) and generally agree with your sentiment, but it is worth noting that portions of overly-bright screen do not generally trigger the "seared eyeballs" sensation. There are scenarios where allowing a scant 1% of a photo (for example) to be over-bright means much more range in the rest of the image. Personally, I prefer a display that simply matches the static contrast ratio of the human eye. I use ambient lighting to keep my pupils from dilating when viewing a dark screen. (Which has the side-benefit of avoiding the dark-to-light transition that people hate so much.)
Unrelated fun idea for hardware engineers: develop a GPU that outputs average image brightness before each scanout. This allows the monitor (or GPU itself, though you'd suffer quantization issues) to slowly ramp during dark-to-bright transitions. Consumers would love the feature: people like to stare at devices in dark rooms (bed etc) but melt their eyeballs every time they navigate from a dark page to a light one. This would prevent that pain.
> There are scenarios where allowing a scant 1% of a photo (for example) to be over-bright means much more range in the rest of the image
I think that is why hdr invented at first place. Sdr is never meant to present "sun casting on you directly". The sdr #fff in hdr setting is called "paper white". Looking at paper shouldn't hurt your eye in reality and nor does on screen.
Yea, it's annoying. Medium does not allow the author to pick the text color. Believe it or not, this combo was the best contrast. Medium's fischer price CMS is really weak in this area.
The article was published April 1st... I am thinking this was intended to be a joke, as this is the first thing I noticed, breaking it's own rules for "clarity of text".
It's Medium's CMS. Author has no control over the text color, and I've been experimenting with combinations trying to find something useful. An effort in futility. I'm planning on moving my articles to my own site... then... then this went viral. OMG. The true irony.
Since gray is every color with no saturation between white and black, blanket statements like this aren’t very useful.
Pure black text is not needed everywhere. Make sure to keep the contrast levels nice and high, but experiment with low brightness grays and they may work better than pure black given in certain situations.
Medium is lame for more reasons than you might imagine, I have not had the time to move things to another site though. If you want, my catalog of current contrast research resources is listed at git.myndex.com
The contrast example images near the bottom are good. I almost missed them because the article really goes on quite a bit without adding anything enlightening, it just sort of repeats the same claims (or insults) a lot.
Only terminal-based websites can rid of that but the price is getting rid of non-monotype fonts as well. Medium, tangleweb, HN - all of that are not using black text. Neither rest of the web does unless some "this is a website" [1] or maybe Stallman's website [2].
I don't recall seeing this taking any more time than being instantaneous so that in itself wouldn't be a UX problem, but I also do like when things are not unnecessarily wasteful, so grateful for that cleaner approach :).
Tbh, I dislike web programming and anything close to DOM, I'm more of a backend and embedded kind of guy. I haven't had success in making a similar one that removes "overflow: hidden" from all elements. That in combo with removing anything with fixed position is a quick and dirty way of bypassing GDPR pop-ups.
Say you come to a new site, eg via a HN link. Boom, I have to indicate my stance towards tracking and ads by rejecting all cookies, and objecting to "legitimate" interests. That takes time, so instead I have a bookmarklet that removes anything with position:fixed (the gdpr pop-up). The second piece would be re-enabling scroll by disabling the "overflow: hidden". I do this manually now by inspecting.
I also dislike their specifying colours/fonts; often they have too big fonts. As the end user, I like to specify my own. In the old version of Firefox that I have, I can disable CSS, and often do because I dislike the CSS included in the web page.
As an author, I prefer not to define colours and fonts at all, except to specify which text must be displayed using fix pitch fonts. The end user can specify their own colours and fonts.
It's worth noting that Dark Reader can force light high-contrast modes.
I use it for this on my e-ink device. The results aren't always optimal (site graphics and navigation are often mangled), but the main body text is at least readable.
Oh, and this is an Android app (available via F-Droid to boot).
I've already got ... three web browsers installed (not including w3m and others under Termux). The thought that there's a need for yet more browsers just to read the fucking text seems ... sad?
Would you happen to know of screenshots / videos demoing features?
Well, if you are using browsers on EPD, one of the first points in the wishlist (or, "requirements unless desperate") is to have a high-contrast option.
This is 100% why I use Dark Reader. Even on my phone, right now, I'm using Kiwi. It has a "night mode" (which, by the way should not be the way to call a dark mode—I, and many others, use it all day). But I still use Dark Reader, because it has a crowdsourced WHAT TO INVERT and WHAT NOT TO INVERT which is AMAZING and fixes most situations.
This happens even in physical books. Have any of you seen the last few iteration of PMI's "A Guide to The Project Management Body of Knowledge PMBOK Guide"?
The pages are gray with black text on it. at nearly 1000 pages, it is exhausting to the eyes.
Did not really read the article - absolutely ugly choice of colors that hurts my eyes.
But yes this light grey on white (often using thin fonts) causes me to immediately leave. Modern design is most often about creating some crap with zero idea about the ergonomics.
I just had to interview someone who used grey text in their resume. I had to change the color to be able to read it. It may have been the first time I edited something in word in almost a decade.
My web site is black text on white background (or white on black if `@media (prefers-color-scheme:dark)` is set). If someone wants LESS contrast, they can change the settings on their monitor.
I may be naïve, but I have a hard time believing Medium hasn't done plenty of tests on how text is displayed on their site, and chosen the ones that have kept users there the longest.
For me this light pinkish text on the dark purple background is far worse choice... it's not just the eye strain that I felt immediately, it also has this anxious and aggressive vibe. Good choice of color palette for a striptease club, but not so much for a page with a lot of text IMHO...
Unfortunately, Medium does not allow setting the text color — they set it automatically based on the background... After trying several combinations, I've mostly given up with that site and am planning on moving to another.
Is this meant to be sarcasm? The entire site has gray text on a purple background. Sometimes the text is even a light purple still on a purple background.
The author, bound as you may know to the choice of the publisher, advocated for readability so that people could be encouraged to arrive at least to the actual first paragraph of text.
well not quite: 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.
Further, Medium prevents their users from selecting black text as a choice. While Medium’s “Fischer-Price-simple” content creation is easy to use, it is also extremely limited, and fails in accessibility in areas beyond color. Perhaps this article can serve as a wake up call regarding this issue.
> 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.
They present the fact that it's hosted through Medium.com as if that was an immutable law of nature. Other websites exist.
By hosting the article at Medium.com, despite their objections to how Medium.com constrains the article's appearance, the author is demonstrating that they don't consider their own argument particularly persuasive.
Well he says medium uses grey text, yet this article has a purple background which is clearly not a medium default - so obviously he had some control and made this unfortunate choice.
I still think it's worth pointing out. I do believe this is the first purple article I've seen on medium, so I don't believe purple is a limitation of the platform.
It's effectively the author's personal website. If he can change the A record for his domain name, he is in control. That he might not want to do this is a different matter.
If I chuck your vase at a wall, I don't get to blame the inevitability of inertia for the resulting mess.
When viewed through the TangledWeb publication,we have set it to a dark mode, which is probably the best contrast possible per how Medium is configured.
First, the experience of this article is vastly improved by reading it through Scribe, an alternate front end along the lines of Nitter, Invidious, Bibliogram, and Teddit:
Secondly: as someone who's switched almost wholly to e-ink for online reading[1], the greyed-out text, or worse still, grey-on-grey experience is all the more aggrevating.[2]
Fortunately for me, reading on my BOOX with Firefox, reader mode addresses the colour and font-face issues. Leaving me with a remaining third problem: scrolling.
Touch-based scrolling through a document on mobile devices is itself a horrendous experience, and e-ink's latency makes this worse.
At the highest display quality, scrolling causes the display to "shatter" into a sandstorm of pixels until movement is stopped. Given the nondeterministic nature of scrolling, trying to pick up where the original end-point of text was, and continue reading is ... difficult at best. Reducing image quality at least gets rid of the sandstorm effect (at a cost of display quality and increased ghosting), but scrolling remains uneven.
An alternate browser, Einkbro, which has numerous e-ink optimisations, features pagninated navigation. Specific zones of the screen (my preference is lower right & left for next/previous) will navigate by (nearly) a full page, deterministically (I leave about a 10% overlap for continuity). It's still not as good as a fully-paginated document, as with PDF-based e-books, but it's worlds better than scrolling.
I've been noticing how annoying online reading is for many reasons (ads, sidebar clutter, animations, and more), and was beginning to wonder if that was intrinsic to me or my device itself. Re-reading a 500 page novel this past week, on the device, I realised that no, it's mostly Web design / Web browser / Android interactions themselves, and that e-books are a vastly superior long-form format.
Even tools such as Pocket which offer a "page flip" mode turn out to be a horrendous UI/UX in comparison:
- The flipping is gesture, not region based.
- Application features such as highlighting and tagging are not available in page-flip mode. It's necessary to scroll slightly to expose these.
- Pagination is not fixed for the document, but is arbitrary depending on your position within the document when you initiated flip mode.
Consequence: I rarely use Pocket for reading.
Einkbro has one further trick up its sleeve, however: "save as ePub".
Yes, you can save as PDF, which should be familiar from other browsers. As with these, the result is a statically-formatted document with fonts poorly-selected for static reading, page-clutter from the online experience, lines cut off between pages and running into both side and vertical margins and gutters, and a pile of increasingly-difficult-to-navigate single documents.
Save-as-ePub:[6]
- Largely succeeds in stripping out all non-main-body text from the article.
- Standardises fonts to your ePub defaults.
- Formats vertical and side margins. (I'd prefer these could be made larger, that's actually the fault of my e-book reader.)
- Permits annotations of the document directly: highlighting, bookmarking, and both typed and handwritten annotations.
- The kicker: Compiling multiple Web articles into a single ePub book. This might be a set of articles on a specific topic, on a date (or date range), material for a project, to be sent to a colleague, friend, or family member, etc.
There are limitations , but it is transformational and uncannily brilliant. It also highlights that a tremendous problem with the Web is its very Webbyness.
Einkbro has several other highly-useful features:
- Font scaling ON THE MAIN TOOLBAR ITSELF. Not buried four levels deep within menus as in Firefox, or entirely nonexistant as with Chrome.
- A "White Background" toggle, which mostly works.
- A good "Reader Mode" feature, though IMO inferior to Firefox's. I'm often caught between Firefox's better reader mode and Einkbro's better navigation, at which point save-to-ePub is usually the best alternative.
- Various interface quirks which have my relying on Firefox more for content discovery (often through HN), and Einkbro for long-form reading.
But it's an excellent browser and if you're on an e-ink device, or even a tablet, I strongly recommend it.
But yeah, the further I can get from a site's own design and styling, in general, the better.
________________________________
Notes:
1. Exception: when I'm commenting on specific sites and services, as one of my accomodations is to not have any account-based services on my e-ink reader, so yes, this is being typed on a colourised & emissive older tablet.
2. "Night mode" defaults are also exceptionally bad. TFA's choice of an exceedingly grapey-purple background renders as grey-on-black, which ... is pretty bad itself. Worse still are colour combinations of similar luminosity (say, red-green or red-blue) in which all distinction between text and background is lost. Even my own take on the "Motherfucking Website" motif, which tends to render well on most colour-emissive devices, is suboptimal on e-ink. I should add a @media query based on available colour depth and toggle colours to maximal contrast for e-ink. https://codepen.io/dredmorbius/full/KpMqqB
3. Fonts matter. A lot. At 220 dpi, i much prefer serif to sans.
4. There are many other reasons for this, mind, I'm just referring to the navigation / interaction aspects. My years' old gripe list remains largely current, though there's been some small progress: https://old.reddit.com/r/dredmorbius/comments/5x2sfx/pocket_...
We should have a HN guideline to add (Medium) to the title when the URL itself obfuscates that fact.
Anyway, I agree with the article. I find myself resorting to reader mode more and more these days partly due to crummy web fonts, partly due to janky JS and bloat, and partly due to unreadable color combinations.
Are there any effective browser extensions to intelligently prevent things like a "Subscribe to our newsletter" popover?
I'm trying to think how i could tell uBlock origin to intercept any element with a high z-index which has it's ".display" attribute changed only in response to a timer or a scroll event.
In firefox i have the "I don't care about cookies" plugin and i genuinely forget that noise exists on the web until i use another browser and it all comes flooding back. I'm hoping there's something similar for this endemic cruft the web has been filled with.
Reader mode can be useful. NoScript can be useful but can also be painful.
I used to dive into the console and start removing stuff and even went so far as to write a bookmarklet that tries to identify and nuke anything with fixed position and reset the height to auto on body/html but ... if someone's going to be that user hostile it's not worth my time.
When this happens I'll copy the url, close the tab and paste it into archive.is.
Edit: it's a subscription. No, thanks. I much prefer the crowdsourcing model, which allows the entire world to have it (and contribute to it), and not only those who can pay such prices (that are quite expensive in most of the world, including where I live).
The problem I would think is the overlap for this of users who want jank removed from web pages and those who would choose to pay for it if optional is small.
Another subscription service and software you can't actually buy is much worse than the annoyance of pop overs. Does it atleast keep working without updates after a year?
I think it's about the websites you visit. If you only use "tech-y" or smaller niche websites you don't come across them. But if you visit websites like from the big news media or even niche websites that are not in English. There are filters for all major languages but there are certainly fewer skilled filter writers with time and willingness to write them in other languages.
There's also a gap of websites that are big enough to have this corporativist behavior of putting annoying... objects in their webpages, but not big enough that enough people visit to the point where it's likely that one of them will write the script.
Especially because, like, I do write some stuff for userstyles and userscripts sometimes, but I won't publish them unless I think they'll be useful for at least a small group of people, which I never seem to think will happen for websites in my mother tongue for some reason.
- Globally blacklist malicious JS (and other features) within uMatrix.
- uBlock Origin's "Annoyances" filter is highly effective.
- UBO's element remover tool is also quite good, and permanently removes misfeatures.
For added leverage, on desktop, I use Stylish to write custom CSS rules that assign annoyances the CSS property "display: none !important". This is typically on a site-by-site basis, though there may be some common targets that can be addressed either globally or with a standard stylesheet applied to multiple sites.
All of which is a pain, agreed, but less of one than not doing so.
It's a one click removal. It's nice because I dont have to search for the nearly transparent x or tiny no thanks, I can just muscle memory to the same button in the toolbar of my browser every time.
I know that such prompts are not technically pop up windows, but they are in spirit. I really wish the major search engines would penalize sites that use them, or that we would get browsers that started blocking them.
Yeah, the best solution is NoScript. It's not too painful as you tune your whitelist. It sucks, but it's better than the frigging popups. Even works well in Firefox for Android, which is a game changer.
Yes. I use tamper monkey to write scripts for sites I visit frequently that have annoying popups, content blocks (like chat) and link-jacking (streaming sports sites).
Give me a break. Medium is fine. The webfont they use is fine. Their jank is nonzero but minimal.
Sure, fine, whatever, The Web Is Worse Than It Used To Be. I wish every text-driven website (news, blogs, etc) rendered with zero jank and zero JS required. But Medium really isn't much worse here than everyone else. Their pages are more cluttered than they used to be, which sucks, but they're clearly just victims of the same forces driving all other commercial websites to do the same things.
Medium is (so far) the ultimate manifestation of "Eternal September".
It doesn't just save people the technical effort of making a blog, but people think that it saves them the marketing effort -- which is a lot more effort.
> 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 do they do that? They even have their own domain, they can get a domain but they can't host text themselves and choose their own colors?
Medium unfortunately simply doesn't work on my phone. It shows the first paragraph of text, then just nothing, no button to expand text or anything either. Some bug, they can't even render a textual article even though browsers could do that in 1993.
If any young entrepreneurs are reading this, one of the few things I'd actually pay for is a web browser that worked like reader mode, but all the time.
This existed and it was called Opera. It had the ability to replace the style sheet on a site with a custom version, one of which was a high contrast reader mode. Opera split into two, and the current version doesn’t have this feature but maybe Vivaldi still does?
Note that it does not include custom domains or image uploading on the free plan, but you can upgrade for $29 (lifetime), which gets you:
Custom domains (this is time-consuming)
Image uploading (due to the cost of hosting images)
Email subscriber lists (since it gets complicated)
Beta features (since they aren't ready yet)
You can upgrade for $29, flat.
The editing interface is just a textbox where you paste markdown; doesn't seem there's a github integration or anything like that, which is too bad.
Soft paywall for some random guy's blog. Uses 40mb of artisnal javascript to display a basic text document with a few images maybe. Hostile to the open web.
Using Medium is way worse for readability than using grey text.
Long body text should have sufficient contrast and good typography. Using only maximum contrast for all text "just because it worked for books" is bad advice. Not only was there not really a choice when it came to books, also books reflect natural light instead of emitting light. This is fundamentally different and needs to be taken into consideration when designing.
The web does offer incredible flexibility for improving information transmission with _good_ design. Establishing visual hierarchies, guiding the eye and emphasizing things, just to name a few. Just look at your code without syntax highlighting.
The issue is - as with most things - that there is a mix of bad taste, carelessness and lack of education going on.
Just like the design of this article.
> books reflect natural light instead of emitting light. This is fundamentally different
But do not forget that there are other technologies around: EPD, OLED do not quite overlap with that general idea. And both call for maximum contrast (EPD to reach a decent threshold for contrast, OLED to get a completely mute background on one pole and to be energy efficient on the other). Edit: I forgot "projectors" (there where the issue of contrast is nightmare).
> maximum contrast ... Not only was there not really a choice when it came to books
Not really. Try reading a printed book with non-black text. Your "eyes" should tell you it's "not good".
Yes I agree that there are special considerations for e.g OLED where I also prefer pitch-black background. My argument was just that the medium can hugely influence the design and needs to be taken into consideration. Also books are kind of a special category as they contain a LOT of text. So legibility really is the primary concern. With the often shorter prose on the web I feel we can give a little leeway. I would trade dark gray text for removal of intrusive ads any day of the week. Also a lot of books (at least in Europe) are also set in Serif typefaces. Something which did not really translate fully to the web either. Stuff like max line length, font size and kerning are also very important and often neglected elements of typography on the web.
> Also books are kind of a special category as they contain a LOT of text
:) I assumed that the context was that of focused-reading material, long text. Even the movement at https://www.contrastrebellion.com/ does not use B/W everywhere... I assumed that we were discussing a context where «legibility really is the primary concern».
For an aside, a title etc., function prevails - it works in a context; optimal readability: "for the time I will spend on it"...
But the web is full of articles - long text - set as grey on grey.
> For over 1000 years black text on white paper has been the best practice for printed texts worldwide.
This alone almost made me stop reading the article. What worked for printed text has no bearing for what works on an illuminated screen.
But honestly, it's not grey text that's the problem. I agree with the author that maintaining high contrast is important, but it is equally important that things aren't too bright. You should avoid using extremes like #000000 and #ffffff unless you're really trying to make something highlight.
#0f0f0f or even #202020 doesn't make an appreciable difference, at least to my eyes. Believe me, as a 50+ year old, I notice when it's hard to read things.
Paper isn't typically a pure "#FFFFFF" white and if you'd bothered to read the article instead of rage quitting after the sub-heading you'd realise that the article is advocating exactly the same point you are. Let me quote it for you:
> On a light or white background, body text should be black. In many cases it is more appropriate to reduce contrast by darkening the background. As an example a white #FFF background is really too bright for comfortable reading, a background such as #e8e2dd provides a less fatiguing background.
Sorry if I come across blunt but if you're going to be critical about an article then at least read more than the sub-heading first.
Paper can be very white and bright if well lit. Much more than a typical LED/LCD screen. If your screen is brighter than a white sheet of paper, it's probably too bright and you are probably tiring your eyes.
The only moment when a sheet of paper is darker than my screen is when I'm in my bed, in a completely dark room watching or reading something, and that's not known as a very good thing to do for the eyes (and for the body posture neither by the way).
I'm not buying the fact we should darken the background of a text. I think we should let people reduce the brightness of their screen instead.
Everything¹ can be brighter than a screen if you just shine enough light onto it. The main issue with pure black and white on screens is typically contrast. Modern screens can have a much, much higher absolute difference between the brightest white and the blackest black.
There is such a thing as too much contrast. Typical ergonomic workspace regulations (like the ASR in Germany for example) will tell you how much contrast any given type of workspace environment should have between the brightest and the darkest point for a reason.
Now someone with an old, washed out TFT might get a much different contrast when viewing a #000 #FFF page of text than someone with a modern HDR display if this is not accounted for in software. Now you could say they need to adjust their screen – but text is not the only thing people view on screens. Why would you throw away image and color fidelity, because some website doesn't fit that setup? We are on computers, why not just support different contrast levels like we do with dark mode?
> Everything¹ can be brighter than a screen if you just shine enough light onto it.
I should have mentioned that I was thinking of a sheet of paper in the same room / with the same lightning, next to the screen we are speaking about. Otherwise, yes, indeed.
> why not just support different contrast levels
So what I understand from this is that we can't get this right (in HTML/CSS) for now because we don't have details about the environment of the user wrt lighting/contrast (preferences/perception).
It seems like something that should be fixed at the browser or the OS level. One should be able to say: "this is some black text on white background that needs to be displayed so as to be comfortable for the user given their environment" (or something). Maybe that needs to be the default by the way.
Until then, any forced value is going to suck for someone.
FWIW, ambient light sensors were present in (high end) devices (and displays) for ages, but they never worked reasonably on desktop hardware: basically, they should let you configure at least two points of comfort in different lightning. Eg. when it's very dark, you set the brightness that is comfortable; when it's very bright around you, you set another level of screen brightness. Finally, display brightness gets set automatically by interpolating (and even extrapolating) from your chosen settings.
Advanced configuration could allow you to tune the curve continuously (or in a sufficient number of discreet steps that it seems to be continuous).
I think I noticed my Android phone at least doing a "I'll remember a relative brightness you want for this much light outside", though I haven't checked if it's really that.
I guess what I wrote about adaptation didn't some across as clearly as I had hoped.
Adapting to the ambient light and reading on paper which is never more than 90% DIFFUSE reflectance (typically 80% for paperbacks, and 70% for newspaper) is not at all like having polarized light beamed straight into your ocular medium to collide with your retina at well over 100% of the ambient adaptation level. Or words to that effect.
> _There is such a thing as too much contrast._
Yes, there is absolutely such a thing as too much contrast, however, I hesitate to say this as it is so often misunderstood—spatial frequency is the key factor to determine first. The contrast needed for small thin body text is very different than that needed for a large bold headline.
The thing that some find confusing is thinking that too much contrast with a light background means making the small thin text lighter grey, when in fact the text should stay darker tha #303030, and lower the luminance of the background to #e6e2dd. I say as much in the article.
Normally I'd agree with all of your points but the article is really clear about lowing the page brightness and not the page contrast. They even had an infographic to illustrate their point: https://miro.medium.com/max/1400/1*xOhOFGLr6o4AsGhlACweSQ.pn...
At no point were they making any of the suggestions the GP are criticising them for.
On the contrary, I find that the "vitriol" was a good balance to the "rage quitting" disclaimer raising the rage level for no reason. It's an article about text legibility. We should be able to take it or leave it or refute it without rage.
(Whether they rage quit or "merely said they almost did" is same difference).
Many people read the headline, maybe subheader and intro paragraph, and then just skip to HN comments – or skip the article entirely and assume the submission title says it all.
So IMO, both of you are contributing constructively here.
> You should avoid using extremes like #000000 and #ffffff
If it's too much contrast for you, maybe your screen is not setup correctly (too bright), or you don't zoom enough. Or your room is not correctly lit. Black on white should be comfortable.
Don't force me to squint or to use way too much brightness sucking too much power to compensate for poor contrast.
People are fine with office suites despite (thanks to?) them defaulting to black on white. We would have known by the time it if was an issue.
I disagree. If you have a screen that is capable of showing high enough contrast that you can have true highlights and true blacks, then why should you make image quality worse just because someone else is unable to reproduce that?
I guess the real problem is that there's no real standard for what #fff means – it has to be interpreted through a colour space, which in turn does not talk about brightness, I think.
Unless you are running with an OLED, reproducing #fff is really hard anyways. Just like unless you have e-ink, active lit #000 is going to basically be a light bulb.
Reproducing #ffffff and #000000 is relatively possible on higher level monitors that have HDR support and full-array local dimming or a dual-layer LCD. While these monitors shine in HDR mode, most of them are also useful for getting a perfect SDR image out of them.
> So, because I'm poor and can't afford such a monitor/screen,
Done properly, moving away from #fff/#000 can be done in such a way that it looks excellent on better monitors and is usable, at very least not entirely unpleasant to read, on less capable ones.
> I will have a harder time reading your site
It not looking as nice for you is fine, as long as it is readable. If we held everything back to making sure it worked on all screens there would be a lot more plain-text-only sites/apps out there. A perfectly good option IMO, but try getting the general screen using public to agree with that!
Even with a bad screen there are usually adjustments you can make to help.
There are of course many pages out there that are too low contrast, or otherwise unpleasant, unless you are using a particularly good monitor setup a particular way for which…
> or just give up and go somewhere else.
… is a perfectly valid option. You don't owe them your attention, though likewise they generally don't owe you anything either.
How about you modify your screen's gamma, calibrate it or install an extension to increase contrast? Why do I have to have my eyes blasted with insanely high-contrast text because my device follows the specs better?
> I use a color-calibrated screen and #000000 to #ffffff is a painful amount of contrast.
This seems highly unlikely if your brightness isn't completely off. What cd/m2 are you at? I'm on a Eizo CG277 with built-in hardware self calibration. It's set to 120 cd/m2 and I have hard time thinking it could be painful to anyone. I much prefer #000 on #fff over lower contrast alternatives.
In pre-press and photography we're used to ISO 3664:2009[0] which I believe establishes whitepoint brightness level between 80 and 120 cd/m2. It should be added that it requires isolation from daylight and ambient illumination level near 80 lux (and a good monitor)... But even at 150 cd/m2 in a room with controlled amounts of daylight, you should not be blinded by #000 on #fff.
My screen is fine, probably as good as or better than what most people have. We can't optimize for the almost 0% of people who have calibrated screens to the detriment of the big majority of people.
The brightness of a screen is also well-defined in the respective DIN norms for workspaces, which I’m following exactly.
Those norms also set a limit for the maximum amount of contrast allowed at a workspace, which #000000 on #ffffff violates if it’s shown on a color-calibrated screen with standard brightness.
> We can't optimize for the almost 0% of people who have calibrated screens to the detriment of the big majority of people.
We can’t just change the meaning of what definitions and terms mean just because it’s easier than making everyone follow the standard.
Create a color profile for your monitor, so your OS can compress contrast if your monitor isn’t powerful enough to reach the SDR sRGB specs.
To help with "making everyone follow the standard", why don't you start describing what those "standard" screen settings are instead of only talking from the point of authority?
Still, any standard prescribing "standard brightness" for office environments is bound to be nothing but a decent average or default. Even if there was biologically optimal display luminance, it would still depend on the environment lightning (which changes during the day if there's a single window in the room), and on the state of the viewers eyes (age, any visual problems or even temporary issues like tiredness), type of display...
>Still, any standard prescribing "standard brightness" for office environments is bound to be nothing but a decent average or default
The purpose of a standard isn't to be most preferred by any given person or "biologically optimal", it's to be...standard. Without a standard, a designer has no ability to pick a particular color and expect anything like that color to be what the end user sees. Without a standard, there's almost no point in discussing what text colors websites are or aren't using.
You might be taking this to an extreme. There are standard definitions of colours, and we've got reasonable ways to compare screens side by side to see how many colours they can reproduce. While humans can differentiate between a large number of colours, we usually think of them only in the terms of named ones (and no, I am not talking of "aubergine").
The GP was talking about using whatever "DIN norms for workspaces" regarding screen brightness are, so I don't see how that relates to colour calibration.
You also sound as if any one end user really cares if they are looking at exactly the right hue of blue when looking at the "hp" logo. If anything, the company and their marketing department care (for subliminal messaging?), but users really don't. I don't think anyone could pick a McDonald's red or yellow out of a given table of similar red/yellow hues.
But even so, if we were looking at any non-light-emitting content displaying colour (eg. a printout), it will look differently to your eye whether you are looking at it in dim light or in a very light setting, so designer can't do anything about that.
Anyone who knows even the most basic stuff about colour perception understands that it can't be decoupled from your environment (enter a darkroom and every colour is suddenly... black).
Colour calibration and standards are done so that you can guarantee that some things will look identical when displayed in exactly the same environment (so your two screens sitting next to each other show the same hues) or to reproducibly transfer between different mediums (eg. screen and paper), but there is no way you can guarantee that it will look identical for another user in a different environment.
Colour calibration is of limited use in general (eg. even different types of paper [think glossy vs matte] will produce different visual results), and while there's more stability with light-emitting mediums (like LCD screens) — because you, essentially, control some of the lightning as well — that breaks down for the average user because they do need to adjust the brightness according to their environment. Those who absolutely require reproducibility, control both their environment and their equipment.
Indeed, it reads like this, but the visually impaired minority is actually mostly part of the majority of people without calibrated screens I was mentioning. So I actually included them.
I'm sure people with calibrated screens can find a setting where black on white is comfortable, even temporarily, while most people just can't fix contrast lowered at the source. Including not visually impaired people in not ideal environments.
But that’s the wrong approach. You can always tonemap low-contrast values into a higher-contrast color range, but not the opposite way. Once you have something at #000000, it’s clipped, there’s no way for any distinction between these values, same at #ffffff.
That’s the real issue, isn’t it? The tooling for this is shitty. You can create an accurate color profile for your monitor, apply it in software and your OS will automatically map the values correctly. This will improve contrast quite a bit, but is complicated, expensive, and you’ll lose a lot of definition in other brightness ranges.
But the same issues apply in reverse if you try to reduce contrast because some idiot thought a 200:1 contrast for text was healthy.
"Screen configuration" means more things. You can optimize for readability, or you can optimize for faithfulness (and more). You should switch according to use.
I don't think this is entirely right although it sounds logical at first. Modern displays can be extremely powerful in terms of back light intensity and contrast; you realize that when you switch on the average model from years ago. They need that power so users can watch videos with intentionally dark scenes and still be able to perceive details in less-than-ideal situations. It does not automatically follow that the maximum contrast is intended or ideal for other purposes such as reading text.
I might add that office-type programs were developed at a time where 14 to 18 inch color CRTs were the latest and greatest. The image that modern flat screens deliver is much more dynamic and has way sharper edges, to the degree that maybe we should consider to artificially blur the entire display ever so slightly just so the higher Fourier frequencies get a bit less dominant.
Then unleash the full brightness when watching videos, and scale it back when reading text.
Until we get HDR on the web, one sRGB size must fit all. At this point, accessibility and readability are top priority. You can always tone down your backlight, while someone else might have it at full blast and still not be able to read without squinting in the sunlight on a cheap display. I know who I'm more sympathetic to.
You can not just tone down your backlight without having to measure the color profile of your monitor again. Which takes hours.
As I’ve said countless times before, we’ve got OS support for tonemapping HDR content onto SDR displays, now we need OS support for tonemapping SDR content onto shitty displays.
I know nothing about color profiles, I'm surprised you can't just turn down brightness to read something comfortably and revert to the original level when you need accurate colors again. Or you want accurate colors all the time? But what for, if you are just reading an average document?
I don't need accurate colors when reading text, but I need it to be comfortable. It seems having color calibration would actually suck for me if I can't adjust brightness depending on the weather, on the hour of the day, on the season, on whether I'm tired or not, or on the location I currently am, or on what I'm doing (reading, programming, or watching a video). I need to be able to adjust brightness without fuss.
I guess I would buy dedicated hardware and put it in a well lit-controlled room if I needed accurate colors.
> I know nothing about color profiles, I'm surprised you can't just turn down brightness to read something comfortably and revert to the original level when you need accurate colors again. Or you want accurate colors all the time? But what for, if you are just reading an average document?
I want accurate colors because setting it up is a pain, and switching between accurate and inaccurate colors takes your eyes quite a while to readjust.
It’s much easier to just have everything in an accurate color mode and have content designed for that than to switch it around.
Proper color profiles are actually even more of a benefit for cheap displays than good displays as cheap displays profit from proper colors even more.
Imagine what colors devs would choose if instead of defining white as "the brightest thing any given monitor can spit out" they would just specifiy some absolute value in e.g. Lumen per mm² and the screen tries to actually reach or maintain that value.
The issue with color on screens is a bit like the loudness wars in audio mixing: everybody tries to use the available bitspace to the max, because this made some sense in the days of 16 bit (or lower) audio. Nowadays much more dynamic delivery would be possible (with dynamic reduction as a user preference), yet there is no real, well designed system for such things in place.
The root cause could possibly be that not all displays are capable of proper contrast in dark mode at a comfortable brightness for also displaying expanses of white.
You would wear out the brightness controls in no time unless you go out of your way to mandate dark mode on everything.
Another factor might be the dark adaptation of the iris, which could be helped by desk lights.
I have never owned a monitor or phone without a brightness control. I challenge you to find any screen capable of displaying a paragraph that does not have a brightness adjustment. Any form factor (other than backlight-free stuff like ePaper and cheap calculators) will do, as long as it had top 100 market share in its segment at some point in this century.
(Brightness is the adjustment that decreases the max white level without also making blacks brighter. So, a display that only has a contrast knob would count as missing a brightness adjustment.)
In my experience with cost-optimized low-end LCD displays, changing brightness settings will more or less alter absolute contrast at the lower end as well.
Even if the ratio stays the same, the darker shades suddenly are a lot more distinct as they just aren't consumed by artifacts and color shifts or even just glare anymore.
If you actually measure the color of printed text, like in novels or newspapers, it is rarely pure black. It’s just really hard to make pure black in real life. It is typically a very dark purplish gray.
In addition, the paper it’s on is almost never pure white. And, as a reflective medium, the perceived colors of paper and ink vary with ambient lighting.
So in digital: should one create sufficient contrast to read? Yes, definitely do that. Stay well inside accessibility guidelines.
But a site absolutely does not need pure black text on white background to do that. And in fact at high screen brightness, that level of contrast risks creating little bits of ghost text in some people’s vision.
But if you measure how #000 is rendered on a screen, you'll also notice that it's not actually pure black too, because as you said, "It’s just really hard to make pure black in real life" and your screen responds to the same laws of physics as anything else. So there's no need to pick something else that #000 to avoid having actually pure black.
I've never understood this argument. If the display had pure black (depending on the definition of pure black here), it would either be an ideal absorber or reflector across the EM spectrum. My phone is not a theoretically ideal mirror, and it also doesn't accidentally cryogenically freeze surfaces when it's face down and displaying a black screen.
Similarly, it cannot boil water or charge my house's solar batteries if I display an all #fff screen.
(If it could do these things, then I'd argue for clamping contrast in the display driver, not in untrusted CSS code!)
Even in the realm of thermodynamically plausible displays, if it is so bright it's burning stuff into your retina, then turn the brightness down before you permanently have an xkcd burnt on to your retina!
Also, I'm reasonably certain such a monitor would fail safety certifications, so maybe don't buy black / gray market hardware, then ruin it for the rest of us?
I don't think things are nearly as clear-cut. Personally, I like things to be near the extremes, I use OLED screens, and then I deal with it by changing my brightness. I prefer having contrast which I can easily control with brightness settings than not having contrast and then there's nothing I can do.
The ideal situation is where people can change stuff to what works for them, which is why I use the Dark Reader extension. It's the best extension in that it not only lets you easily change brightness and contrast, light/dark, but, most of all, has a crowdsourced file that carries special settings for each website over which elements should be inverted, which elements shouldn't, or whether there's an element that shouldn't be touched at all, for instance.
I have used such extensions in the past (and even welcomed stuff like Chrome's automatic dark mode) but unless they come with perfect AI—which they don't—they're not gonna match Dark Reader's crowdsourcing.
>it is equally important that things aren't too bright
That's why your display has a brightness control.
At least as long as we're stuck with implicit sRGB, until the web gets proper HDR support, don't murder the contrast of text. You never know the actual viewing conditions (probably less ideal than a well-lit office), and it's foolish to limit it at the source.
Also, anyone who thinks printed text is actually black hasn't worked with print. And how on earth does someone make this argument while using text and background that are two different shades of purple?
> anyone who thinks printed text is actually black ... worked with print
Not clear. We always normally printed in K - insaturated black. Or, "typographic black", or "sufficiently black black", or "just black". «[A]ctually black» requires a definition.
I guess that's why the OP complains as well. I do wonder if none of the other Medium themes have a better contrast, but the OP obviously felt that they needed to explain their (lack of) choice of non-contrasty colours.
> What worked for printed text has no bearing for what works on an illuminated screen.
I find this hard to believe because in both cases what we actually perceive patterns in the light that enters our eyes. It would seem to follow that only aspects of the reading surface that cause difference in the light patterns (color, intensity, phase, coherence) and the time evolution of those patterns can affect matter when it comes to how well something works for reading.
If we determine, whether from printed text on paper, inked text in tattoos, skywriting in smoke, or anything else that certain relationships that some kinds or combinations of the aforementioned aspects of light matter or don't matter, that should remain true when we are reading from screens or from any other existing or yet to be developed form of reading device.
I've got this exact problem when trying to meet accessibility criteria.
I would have no issue with sticking #000 on #FFF, except for the fact not everyone has e-ink displays and it's like shining an LED torch in everyone's faces. If it's inverted to #FFF on #000 this is pretty much solved - but this is a hard sell for most product teams.
To add to that, article also brings the point of spacing and font weight, which are equally important. Dark backgrounds with light text require heavier font weights (esp with subpixel rendering) for proper contrast.
I really dislike that kind of argument. It's not because it's wrong, but because it's not right either.
A monitor can easily be adjusted so that the contrast between #000 and #fff isn't too much. In fact, most displays have a setting named "contrast" just for that, but what actually makes things too bright is the "brightness" one, that is usually more prominent. People will have opinions all over the place about it, because they do get results all over the place.
Instead, yes, you should avoid using the extrema. But that's because if you use them in a normal situation, you won't have any more extreme values when you need them in a special situation. People should be able to change the color schema anyway, so you are better with a functional choice.
> What worked for printed text has no bearing for what works on an illuminated screen.
This alone almost made me stop reading the answer.
This people is talking about accessibility. So, the more contrast, the better. You want to "highlight" something? Bold uses thicker fonts, underline adds also more pixels. You can add a carefully selected background, like a medium gray or other light color.
But black on white it not to highlight. Is to make it readable. To anyone.
>but it is equally important that things aren't too bright.
That's controllable at the screen end.
Even if people use off-white background on webpages, you'd still get white screen real estate in UIs and other places (default Word and Excel background, for one. textarea boxes for another).
NOWHERE, absolutely nowhere in the article did I suggest using #fff/#000
On the contrary, I highly recommend that for light backgrounds the, background directly under body text be something like #e6e2dd. I explain this in the article.
> Users are fully capable of adjusting the brightness and contrast of their monitors.
It'd be a hack. The buttons are not sturdy enough for it, they're even not designed for it and the colour representation will be very incorrect.
Instead of asking every website to blast every user with the highest amount of contrast, modify your own display to do so if your eyes need it. That way the need and the solution is localized to where it should be.
You should avoid giving "advice". Because of ppl like you I have to constantly mess with CSS and have ton of extensions just to fix colors, just because you knew better.... oh my.
please stop forcing dark themes, reading white text on dark background is less readable so at least default to the user global preference cf https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
I'd be nice to see stats on the level of user engagement on black vs white texts, I assume the user probability to stop reading earlier when white is much higher, for me it is often a no go. Any scientific study out there?
> so at least default to the user global preference
I'm actually kind of annoyed at prefers-color-scheme, and the inability to control it as a user in my browser.
I have my Windows set to dark mode because I prefer how Explorer and the rest of the Windows UI looks in dark mode, and I want my OS chrome to be less distracting and to just "fade away". However, all web browsers see this as a signal to tell every website I would prefer them to be in dark mode also, which is not correct! I wish I could set chrome itself to prefers-color-scheme: light (without having to use the dev tools on every website).
Firefox lets you control that, at least since the latest Developer Edition (101b7). Under Settings, General, Language and Appearance, one can choose between the following:
So change the website theme to light mode? I use dark mode, and am happy when websites are served in dark mode (and I think the majority are this way). I think you're likely in the minority, and the easy fix is just to switch the websites you use to light mode.
> the easy fix is just to switch the websites you use to light mode.
The trouble is that `prefers-color-scheme` is set at browser or system level. In order for a website to use a different colour-scheme, then they need to add functionality with Javascript in order to be able to load different styling at user request.
I wish there were some URL-based rules you could set in the browser settings (I expect there are addons to do this, haven't looked though!).
What if the website does not provide a toggle to control to control this? I wish there was a browser preference to control prefers-color-scheme (which it sounds like new FF does!).
I don't really care that I'm probably in the minority of users who think or care about this. It doesn't make how I feel any less valid.
I have astigmatism and work as a software engineer. All my colleagues use that Dracula theme for everything. I can't, because it makes the writing blurry.
It is likely that this problem can be fixed by changing (by a lot) your monitor gamma. Text anti-aliasing is typically performed on linear brightness space, then adapted to the typical gamma of a monitor for black on white text. Many font renderers show white on black text by doing a simple operation like "255-x". This does not give at all a correct anti-aliasing due to the non-linearity of the gamma, resulting in badly blurry fonts. You may try to mitigate this error by un-doing the bad gamma, at the price of losing some brightness and contrast.
as a counterpoint, this trigger me for natural language text but much less for code on an IDE, I don't know why but yeah prefers-color-scheme should be assumed as human rights in 2022
I'm convinced that most people that complain about light themes being blinding either don't have enough ambient light in the room or have their brightness cranked too high (likely as a counter to the dark theme they use).
I was in student accommodation recently and noticed that it didn't have any reading lights at either desks or beds, neither as part of the standard finishing nor added by the students, at least in for the two or three rooms I saw.
Unfortunately firefox with enhanced tracking protection claims that the user WANTS a light theme instead of indicating no preference - yes, the spec has no no-preference but a) this means the spec is broken because there is no equivalent setting to not implementing the spec and b) web specs are defined by browser vendors and Firefox used to have a no-preference value for this. In general, desktop browsers will also often indicate prefer-color-scheme: light if the user has not actually made an active choice - either as a default in the browser or based on the default system theme. This unfortunately makes prefer-color-scheme: light not actually carry any useful information so there is currently no way to have a dark theme by default but provide a light thome for those users that actually want it (you can only do the reverse).
My problem with prefers-color-scheme is that there's no way to distinguish between “unknown preference” and “prefers light mode”. I'd like my website to be dark unless the user explicitly requests light mode, but the web people decided I can't do that.
I don't think this is technically true. You can do `prefers-color-scheme: light` or `prefers-color-scheme: dark`. IIUC if there is no preference neither of those should evaluate to true.
That being said I think most if not all browsers will always answer true to one of those.
I absolutely hate light text on dark background. There are a few sites I'd really like to follow (hello hackaday), but their insistence on light text on dark background makes them a pain to read. And it kind of feels like the website says "because fuck you".
There is no shortage of "helpful" people who suggest I use all manner of browser plugins to "fix" poor design choices. Eh, no. That is not a solution. If people want to be oddball and weird they can do whatever they want, but I won't be spending much time on their websites.
The author responded to this exact feedback in the comments:
“No, the way medium's designers set things up, the text color follows the background color. The user (me) has no way of controlling that.
The page was set lower than FFF because FFF is also much too bright. In light mode, Page luminance needs to be around 80 to no more than 90.
I've been experimenting to see if there is a way to improve Medium's poor, inaccessible design choices.
Unfortunately, attempting to use web inspector while in design mode, they crash the browser, so you have to publish each iteration to then go and inspect how the text colors end up.
And it's actually worse than I imaginged. Medium actually makes the text worse when you choose a color other than FFF. As as I stated, FFF is much too bright.
Ultimately, I think I am going to leave it in a dark mode, until I move my articles to a better site.”
That's rich: he lambasts people for poor typography and then blames the poor typography of his own blog on someone else. As if he had no choice in the matter. Like using a different blog platform. Or setting up his own website.
As a counterpoint, for me light text on a dark background is easier to read than black text on a white background. Go figure. So much so that I sometimes create dark-mode CSS user scripts for sites that don't offer a dark mode.
For me it depends and I am not entirely sure I understand why.
I use a relatively dark blue/green background in VS Code, with light, low saturation yellowish base color for the code. Before VS Code I used the same dark color scheme for 25+ years in Emacs. But this is for editing code where I have a bunch of colors that have a semantic job to do. The colors are a bit easier to identify precisely against a darker background. And I don't actually read code per se - I scan and orient by shape (formatting) most of the time. So editing code is very distinct from reading.
For prose/text I find it tiring to have a dark background. Not least because people get the contrast wrong because they don't know that it is different for dark backgrounds. And from an aesthetic point of view it strikes me as a bit ... well, demonstrative and perhaps childish. I'm sure this impression isn't shared by everyone, but that's the feeling i get.
And then there's what you can make work on the web.
(Interesting observation: I'm a big fan of what Erik Spiekermann says about typography - yet both the book he wrote for Adobe ("Stop Stealing Sheep & Find Out How Type Works") and a book about him ("Hello, I am Erik") have horribly annoying typesetting. One has horribly ugly guillemets that look like someone has taken a metal file to the type, the other has type in white-on-pink, which ought to qualify for a severe paddlin'. Is there a rule that whenever someone tries to write something about typography, things go wrong? :-).
One possible explanation might be in one of Spiekermann's writings (can't remember where), where he emphasizes that "good tyography" isn't always the best choice because what people are used to plays a really big role. So a poor type can in some circumstances be better than a well designed type, simply because people are more familiar with it, so they'll have less trouble reading text typeset in the bad, but familiar, type)
Thankfully your browser can indicate if you prefer dark or light designs and the website's CSS can adapt to that. Unfortunately desktop browsers do no make that setting accessible for normal users (mobile browsers follow the system theme, desktop browsers might in some cases). Also Firefoxe's enhanced tracking protection means you want light themes instead of the more sensible "no preference".
> 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, ...
The author goes out of the way to mention multiple times, the first at the top of the post, that Medium offers very little control in this regard. I think the post is intended as a criticism of the very platform it's hosted on, among others.
The author goes out of the way to mention multiple times, the first at the top of the post, that Medium offers very little control in this regard.
Maybe true, but this is the first Medium page I've seen with this bizarre color scheme and I hit perhaps 50-60 Medium articles a week in my work. So it's certainly something to do with the theming of his site.
I see. Seems like a factual disagreement, in that case:
> When viewed through the TangledWeb publication, we have set it to a dark mode, which is probably the best contrast possible per how Medium is configured.
I have never used Medium, so I can't comment in this regard.
"True" black on white contrast ratio: 21
Medium's default very-dark-grey on white contrast ratio: 14.54
This bizarre theme-that-makes-it-hard-to-focus-for-non-contrast-reasons contrast ratio: 14.52
If legibility was important to this author, they could have done the bare minimum to improve the legibility on their own site. The bare minimum was to not change the default theme. A bit above that but more honest to their claim: host somewhere else and use a darker grey.
One of Apple's more egregious contributions to technology. Almost every web client I've ever had asks for grey text and sends apple.com as an example of what they like.
> 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.
It is his website in medium, he could have chosen any other color for the background and make it not as horrible as it is for reading. Or he could have chosen another platform to publish his content.
But of course, all "black", "white", "gray", "yellow" etc are fuzzy concepts in nature. And in nature, the quality of the medium and of the environment dominate in the visual effect.
On a display, "black" and "white" are abstract - maximum and minimum. They are a shard of the final effect, that passes through other parameters of the medium and of the environment (especially, "how much light here and there and directed where").
Insisting on comparing "colour on display" vs "colour on book" is strongly misleading in this context.
Idiots are everywhere. Also in web technology workgroups.
I don't see how maximum computed contrast like black (RGB:000000) on white (RGB:FFFFFF) can be any better of a shade of gray on pale yellow or lighter gray. A lot of web frameworks, frontends and apps like these grayish text, fading widgets and the likes. This is deliberate stupidity and nothing can prove the opposite.
I have moderate amblyopia and severe astigmatism. For a frame of reference, I only barely pass the driver’s license vision test when I renew my license (don’t worry I don’t actually drive).
My vision has good days and bad days. My ophthalmologist thinks that I frequently have eye strain from looking at screens which further (temporarily) degrades my vision.
Examples that I’ve run into _in the last 24 hours_.
I rely on hacky tools to get by — e.g. momentarily dropping HIDPI or jail breaking devices. No one would want to use technology the way I have to. It sucks and it’s constantly getting worse.