It would be nice since they are advocating for readable text if the font sizes were appropriate on mobile. Even funnier is that lighthouse shows a multitude of accessibility problems in the page including.... low contrast.
Apparently the reason for the awful sizing on mobile is missing the responsive viewport meta tag... IDK, I agree with the content of the website but it's just mind-numbing that it has these issues.
For reference the iPhone 4 had already been released, so mobile design was already a thing. The viewport meta tag wasn't a thing though, or at least not widespread as HTML5 release spec was finalized by W3C in 2014.
I did not see that the website was this old when I first saw it. Still, I've used websites from the 90s that worked better on mobile lol (I also used websites in 2023 that were awful, to be fair).
In a lot of ways 2010ish was about the worst for mobile web. Pages were huge and had tons of JavaScript, etc, but responsive design wasn’t a thing yet.
Well, the reason it shows "low contrast" on the page, is because the purpose of the page is to illustrate the low contrast problem. There are many sections that show the contrasting example of good contrast. What you're doing is running two virus scanners, and the second one finds the quarantine folder of the first one. You then claim the first antivirus is a virus. Nope.
This was not a website designed for mobile - that's why it doesn't look appropriate on mobile. Not every website is designed for mobile - in fact there are usually two completely different websites for mobile and desktop. This one is only for desktop. This complaint is like renting a sports car and complaining it's not doing a good job at transporting your piano.
There is one actually valid issue with the website though, which you do not bring up. It singles out websites for some reason, when the issue has zero to do with websites. Windows itself - all over the place - has ridiculous light gray on white, or light gray on dark gray (in dark theme). It's literally not readable half the time. Android has the same - now with more empty space, and page scrolling through 2 lines of tiny text and a toggle that changes description on toggle, so you don't know what it's doing. Heck, the service tag printed on the bottom of my silver dell laptop, is gray.
then we have things like expensive custom license plates with nature pictures and a tiny font. that all the drug dealers buy. and lastly - faces. the only way to tell a nose from a cheek from afar, is light-tan vs dark-tan (in the shadow). And with some people, the only way you can find them at night at all, is if they smile at your joke.
I do a lot of web development, and a lot of that is stuff designed for desktops. I do my best to make sure it works as well as can be expected on mobile devices as well, but I completely agree that it does make things more complicated, and that often you do need a different design, or at least a very flexible design.
But this is not a complicated web application, this is a web document. If they had just added the right meta tags, it would have probably been enough. I'd be surprised if you really even need media queries for a page like this, just judicious use of `rem` and `%`. It's also very easy to test - just make your browser window thinner. Or open devtools on the side, and drag it around a bit. Or there's even a button in most browsers' devtools where it'll show the page in different common mobile and desktop sizes. I think lighthouse usually defaults to mobile too. (Not that lighthouse is necessarily all that valuable of a metric, but it's there, it's a couple of clicks away.)
The point the website is making is that accessibility is important. Light text on a light background might be aesthetically pleasing, but it's difficult to read for many people, and as developers and designers, we have a duty to make our work accessible. I fully agree. But mobile users - and especially mobile-only users - are also an important demographic, and deserve accessibility considerations as well.
Especially when those accessibility considerations would take at most half an hour of work.
It's not a matter of "deserve" and "right to." What use is having a site, that places an artificial hurdle for no acceptable reason? What use is having visitors rage-close the tab they opened for one's website, in contempt and disgust?
Websites, for the most part, aren't composed and administered by government agencies, to provide beneficial information or services paid for by taxes (and it is instructive that federal agencies have been section 508 (of the Rehabilitation Act) compliant for decades, precisely because they are taxpayer funded and therefore have an obligation to make information and services accessible).
So why shoot themselves in the foot, from the get-go? It's not my right that you make your site readable to me. But if you want me to be a repeat visitor, then why make it a difficult and frustrating experience for me? Any person who produces such a site has misplaced priorities.
You believe some of these sections are _meant_ to be bad contrast, while others are meant to demo good contrast?
Which are which?
I can't understand exactly which sections the lighthouse report is flagging. I also thought I wasn't sure some of those sections were sufficient contrast, but all the ones I tested actually did pass WCAG contrast test.
If the web page has chosen to make some sections intentionally bad contrast but others good contrast, without telling you which are which... that is not the educational strategy I would have picked. But I'm not convinced it's doing that.
Although to be sure, there are a few sections that looked low contrast to me. When I checked them with a WCAG altorithm contrast checker, they all easily exceeded AAA limits.
I concluded that the page might have been intending to show that you still had a lot of flexibility in color choices, while meeting WCAG standards. (The WCAG standards are mentioned on the page).
Of course, it's possible the WCAG algorithm/standard is at fault -- it is hard to totally capture human perception in a measurement (not to mention different humans are different), and there are other times I have had color combinations that I find hard to read but which pass the WCAG measurement.
But the WCAG standard is, again, mentioned on the page, with no disclaimers.
I think there may be something worth talking about going on, but I'm definitely not convinced it's what you think.
There are sections of the page that _say_ they are showing you screenshots of _other_ people's pages that are too low-contrast, that part is clear. But you are convinced sections of the page itself with the authors words are supposed to be obviously hard to read due to contrast?
Maybe. I guess we'd have to ask the authors. Seems a weird choice to me, to do that without mentioning you are doing it.
But either way I still am curious if you wanted to identify which sections of the page you are identifying as deliberately too-low-contrast. I'm curious if they are the same ones that looked hard to read due to contrast to me, and I'm curious how they do on the WCAG metric (I didn't look for every single section myself).
> This was not a website designed for mobile - that's why it doesn't look appropriate on mobile. Not every website is designed for mobile - in fact there are usually two completely different websites for mobile and desktop. This one is only for desktop. This complaint is like renting a sports car and complaining it's not doing a good job at transporting your piano.
This is a very problematic take, and is simply inaccurate when it comes to the web.
If you write zero CSS, a web page will render just fine on any display. Text will auto-wrap and be legible. The web is "responsive" by default. It's the designers who try to rigidly align things with specific widths, explicit sizes, and absolute values that make web pages harder to read and use.
Meaning, any given element shouldn't have a `width`, it should have a `max-width` instead. Text should have a relative font size to headings or other text. Alignment should take into consideration overflow, as it will by default with flexbox and grid. Everything by default will flow in some way and try to make it onto the page.
It's all the violence of designers that makes things both less device friendly and less accessible, just like these poor contrast decisions.
> Well, the reason it shows "low contrast" on the page, is because the purpose of the page is to illustrate the low contrast problem.
No, those parts are done as screenshots. The places it’s complaining of low contrast are in the actual document and supposed to be high enough contrast.
> Not every website is designed for mobile - in fact there are usually two completely different websites for mobile and desktop.
This was never true. Websites that split desktop/mobile completely were always a tiny minority across the entire web, though a decade or so ago it was certainly absurdly common among big players. But fortunately those days are past, and the considerable majority of sites that ever had a hard split have unsplit.
No, in this case it’s just a badly-implemented website from an era where that didn’t matter quite so much, and they haven’t fixed it in the decade since.
> in fact there are usually two completely different websites for mobile and desktop
Only if your designer is too clever for his own good.
Plain HTML works fine on mobile (with the meta tag added to tell mobile browsers no to be stupid) so if your website doesn't then it's because something YOU deliberately added.
I'm not sure why those sections were flagged for low contrast. Manually checking the contrast for those colors at https://webaim.org/resources/contrastchecker/ shows that they are all WCAG AAA compliant.
They use the "desaturated" hn text as an infringing example. Shots fired!
I'm totally on board with their thesis and was about to come here and sing their praises, but then I found that they've annoyingly conflated page links and anchor links so the back button didn't do what I expected it to.
In any case playing whack-a-mole with modern web design flaws seems worthwhile to me so I'm in favour.
Yeah the desaturated text on HN is confusing. It is for example, applied to flagged posts, so I first associated the lower contrast with being flagged, but then I noticed it is also applied to self posts like Ask HN or Show HN, and I kept wondering why are all these people getting flagged? Turns out it is just the way it is.
One of the worst offenders is Obsidian. Users on hn keep praising the UI, but by default the menu text is borderline unreadable under less than ideal lighting conditions.
I don't complain too much about VS Code and Obsidian as there are so many themes that are just a click away... I even have matching themes for them, which is nice since I use them together a lot.
But in general, I have issues with site font sizes and contrast as well. I'm extremely near sighted, and getting older - I have no idea how people can actually read long form content on cell phones with the tiny screens...
Not only text... take Whatsapp, used by all people with a cellphone in the world, whose sent and read check marks are distinguished only by a subtle change of color instead of having different icons.
I work with graphic/UI designers and I have to be the one to advocate for using more than color to differentiate states, and to meet acceptable contrast ratios. And don't get me started on hiding things behind hard to discover hover states. The managers who are supposed to oversee the development of these products don't give a shit about accessibility. Sad state of affairs.
> The managers who are supposed to oversee the development
Yeah, I can understand kids wanting to play with whatever's new in HTML5 etc. But I don't get why the manager in charge of the project doesn't say "Yes, very cool; but it's unreadable if there's sun-glare. Fix it, please."
Well, I do sort of get it; the manager's a kid too, and he likes custom controls and "distinctive" typography as much as the developer, and doesn't know anything about accessbility. I'm not talking about real accessibility; I just mean ordinary people being able to access the content.
Yeah, you can say "fuck it, I'll go somewhere else". But a lot of sites that I rely on have unique content.
This site flips between dark-on-light and light-on-dark, at least one of which is a visual encumbrance to some people — see ‘astigmatic halation’ — and the other of which may well be to others. (In my experience, switching between the two, as too many sites do for code display, is the worst.)
If you're not using browser default colors, respect `@prefers-color-scheme`.
For paper you'd like the maximum contrast, but screens emit light, and maximum contrast puts additional strain on the eyes. There's a big but, though. This is for people with normal eyesight. As far as I understand, some people require this hurtful (to me) level of contrast just to be able to read. Additionally, you can significantly lower contrast just adjusting your monitor's brightness, but there's a limit on how far can you go in the opposite direction and it doesn't help if there's not enough contrast to begin with.
If you can't solve it with CSS presets, I think it's better to stick with higher contrast for these reasons. For my blog I just use black-on-white, even though for me personally it's too much if it's more than just a couple of paragraphs. I tend to lower my display brightness while checking my own blog. :)
Another nuance I don't see discussed is at least not keeping the empty background around the content div at the maximum value level. It's just emitting pure light around the main content for no use.
> but screens emit light, and maximum contrast puts additional strain on the eyes
Depends on the screen. You don’t know if the viewer is using e-ink or something like that (or even printing to paper—though in that case especially, colours specified in your stylesheet are more likely to be just ignored). If they’re using an LCD or similar, you also have no idea about their brightness settings. They might be ridiculously overbright, as is stupidly common, or “maximum contrast” may actually be delightfully pleasant because they’ve got sensibly-set brightness. Certainly for me in my current lighting circumstances, simple black on white will look delightful, matching the ambient lighting neatly.
I tend to think the "sensible" setting for the hardware is to afford the maximum dynamic range. This way no loss occurs if the material requires it, but if not, it needs to be limited it in software. This, of course, would lead to "ridiculously overbright" text, and limited contrast solves this problem more or less completely (this is why I override the background colour for my PDF viewer). My opinion is influenced by working with graphics, though.
I also believe the most common display technology used for desktops should be this baseline, and currently it's LCD.
However, this creates problems for people with different hardware and different eyesight and light sensitivity. Perhaps it's the OS that should provide some tooling to display the colours differently for different displays and different modes (image/text/other). The changes must be informed by the software, so for example, you could mark you site's colourscheme as "for reading" and the dynamic range would adapt properly.
The way the OS adapts that I saw is atrocious, perhaps because optimized for a different metric. My laptop changing the display brightness and contrast when I use Windows on battery looks bad regardless of what's on display.
> but screens emit light, and maximum contrast puts additional strain on the eyes.
That's just a problem with manufacturers putting displays with high dynamic range into devices and not putting decent HDR software implementations in.
Some apple devices are smart about it though. When you open up an HDR video, it cranks the backlight to make those highlights pop, but dims the LCD by lowering the contrast in software. This means high contrast websites don't sear your retinas while your media can still take better advantage of your display.
Weirdly, this site uses `color: #1b1b1b` instead of black.
Why? The difference is barely noticeable, but black provides more contrast and IMO looks better than #1b1b1b.
I've seen many designers assert that being slightly off-black is "better" for some reason, but isn't this the same argument that eventually leads to low-contrast designs? Why is a little bit of contrast reduction good, but a lot is bad? Pure black always looks (slightly) better to me (I commonly open the inspector and toggle the color to test this). And anyway, the variation in people's monitor settings is probably much wider than the difference between #1b1b1b and black, so what is even the point? Why waste brainpower trying to decide exactly how much contrast reduction is good, and risk going too far for some people while creating an imperceptible difference for others?
(To be clear, if it's not obvious, I'm a big fan of this site's message... but apparently I'd go even further.)
First time I read an argument against all black in design was this 2012 article. Something about it not being a color found in nature. Then, yeah, some people seemed to interpret it as “use gray on gray”.
There is a theory that the reason those glyphs (in most languages, whether characters or ideograms) tend to have a similar, conservative aspect ratio is that they use a part of the early visual system that was useful in finding/tracking footprints (evidence of prey or threats)
In the case of characters, especially hanzi/kanji, ones that are hard to recognize/distinguish either evolve (simplify and/or develop disambiguating features) or fall into disuse. Clearly “hard to recognize” is driven by physiological structures that are by definition “natural”
I wrote “in most languages” specifically thinking of Arabic-derived scripts, but don’t know of any others.
Older scripts, and those descended from other roots, seem to have this property.
Of course in practice Arabic writing is as easy or hard for humans to learn as any other system, so the evolutionary pressure/affordance to get rid of hard parts still applies.
But the theory of early visual system affordance could in principle be studied (though I don’t think fmri is really solid enough yet). Any historical implications of course will always have to remain theoretical.
Writing has technological constraints as well; look at cuneiform vs, say, Pali. Since Arabic evolved after predecessor systems already existed, technological affordances clearly had a, or the, major influence.
Edit: I read your comment again, and just to be clear: your question is really “why is Arabic different”. Latin, Georgian, Aramaic, Brahmic, Chinese, Egyptian Hieroglyphs, Maya pictographs, all have roughly the same form factor.
What this argument overlooks is that pure black also isn’t found on computer displays. Even for OLED, black is really dark gray if you have any amount of ambient lighting. Displays are a part of nature in that sense.
A few things are truly black, because you don't get to see their color. But "nothing" has actually the color black.
Anyway, even for painting, the fact that they have a paint for it means it happens on nature. It's just very rare, so everybody has to learn the lesson that no, you don't use black paint for that black thing you are seeing.
For computer interfaces the entire thing is obviously bullshit since the beginning. But well, our area has a thing for accepting obvious bullshit.
It's funny, because I've never really thought hard about this, but I made a similar decision on my personal site.
My site has a "dark mode" style theme - dark background and "white" text.
When I was initially designing the theme, I opted for a slightly-less-white text color, and as I've spent more time on it, I ended up bumping that color to be closer to pure white. (I'm using Tailwind, so this change amounted to "text-neutral-400" -> "text-neutral-300".)
I think I did this because the "more white" color seemed... sharper (very insightful, I know)? Like it was "an assault on the eye" to have the color be so bright. As I continued working on the site, I decided, in short, that that was stupid, and that I should have more contrast.
This was a good reminder for me that some of my pages need that styling updated, but it works out well for demonstrating the difference:
After skimming through these again as I linked them in this post, I think I could even bump it up to be even closer to white.
I also have a pretty bright monitor (it's an Apple Thunderbolt Display that I got for a pittance from my old office when they switched to Dell monitors). So that may be influencing me towards slightly less contrast.
Anyway, not to ramble, but I guess my point is - design is hard! It's not easy to take into account all the myriad different factors that need to be considered to make designs that look aesthetically pleasing while maintaining readability at various brightnesses and screen sizes and so on and so forth.
Edit: One other consideration - I wanted some color contrast between elements like text, headings, and the post date - so that's another thing I was trying to take into account. For example, if you want your headings to be a bit brighter than your text, you're left using (for example) text-neutral-200 for headings and text-neutral-300 for text. Again, as I continued tweaking, I realized that the size difference between headings and text does enough work establishing contrast that this was unnecessary - but it's just one more factor in a long list of things a designer has to think about to make things look right.
> I also have a pretty bright monitor (it's an Apple Thunderbolt Display that I got for a pittance from my old office when they switched to Dell monitors). So that may be influencing me towards slightly less contrast.
This part of your problem: if you're doing any design work, understand the specification you're designing for. This goes for any photographer, print designer, or web dev.
sRGB, bt709, rec2020, and SDR content in rec2100 contexts define the brightness of white as 100 nits, and is generally considered acceptable to be between 100 and 120 (as you often need to offset for ambient lighting to maintain perceptual white).
Your perception of both luma and chroma contrast, but also your perception of color itself, changes over the range of brightness your eye can perceive; the organic gamma curve of your eye also changes. Example: sRGB gamma and bt1886 EOTF are intended to be used with content that has a 2.4 gamma and a near-D65 whitepoint at around 100 nits; the same content at "theater darkness" (48 nits) will be encoded with a warmer/yellower white point, at 2.6 gamma, to maintain perceptual similarity.
And why is this? The rods (low light vision) and cones (bright light and colors vision) in your eye have different organic gamma curves (incl. each of the three cones have different curves in-of themselves), and the rods do not respond to all visible light equally and have a broad "color" of their own and rods continue to function and influence perception in bright light situations.
You can argue, "but Diablo, most people do not calibrate their displays", which is absolutely true; most displays, however, are manufactured with defaults that mimic the intended use of sRGB and bt709 content, and users, left to their own devices, generally will choose a brightness that approximates 100 nits plus an appropriate offset for ambient.
However, even for your own personal website, buy a colorimeter, whip out the DisplayCal software, set your profile to "Video (D65, BT1886)" (not "sRGB" due to modern content being mastered entirely for displays manufactured in the past 15 years; BT1886 handles perceptional similarity and better in dark values than sRGB's weirdly defined ramp), and then enjoy being able to author content for a wide range of displays.
The irony is that “pure black” (#000) is already off-black on non-OLED displays. IPS displays in particular are relatively low contrast and have poor black levels, often further worsened by IPS glow.
On TN panels, #000 looks horrible from bad angles (mostly below, from memory—it’s years since I’ve had to endure a TN panel), and #1b1b1b would actually look much better and even darker.
I'm not a designer, but personally I like to reserve the extreme colors for the rare occasions you need something "blacker than black" or the equivalent with your color.
It's a holdover from color printing processes. Rich Black (100% K over another color) and Registration Black (full everything) can look bad or even damage the paper.
It's like design's equivalent of not ending sentences with prepositions.
The difference is probably more noticeable on OLED screens that have "true" black.
For personal themes I do use a bit of off black, althought usually it's something like very dark gray. It just makes screen not a complete black hole late at night
Dark reader[0] has been a godsend when it comes to readability. Sure the content isn't how the creator intended it but most of the pages don't have a dark mode option so Dark Reader's rendering suits my eyes and I find that to a certain extent, it also improves readability, especially for those low-contrast texts.
Just a heads up to everyone complaining about the (valid) issues on mobile and elsewhere with this site. It doesn't appear to have been updated in 12 years. In 2011, the newest iPhone was the 4s.
They don't work on every site, but they're a good start. 'Reader mode' bookmarklets like https://github.com/lordastley/readable can often be configured for simple white on black text too.
This is a huge pet peeve for me. Shouldn't this be a “solved” style problem in 2023! I'd gladly fire every tenth web designer responsible for this problem regardless of their other merits.
Small fonts are one thing. There are browser hot keys to change the font size. And I'm a huge fan of the "Zoom Text Only" option in Firefox where the rest of page doesn't go flying off the edge of my viewing area. But low contrast text is hugely annoying. What are my options? Open the developer tools and tweak the CSS every time? Try to find a good browser extension that solves the problem? Write my own? And some of these solutions are inconvenient or impossible on mobile.
I understand using low contrast text (and small fonts) for tedious but necessary legal disclaimers. But if you use it elsewhere, I'll move on—either you have nothing to say and don't really want people to read the text, have a poor designer, or are generally incompetent.
> Shouldn't this be a “solved” style problem in 2023!
Grey-on-grey text is idiotic. It's everywhere. So is scroll-jacking; so is weird animations on text articles (The Guardian does this from time to time). So is web-pages that come up as a sheet of whiteness, if you don't want to run javascript indiscriminately (REACT, I think). So is megabytes of script, just to display a page of text.
This kind of stuff is weenie web-developers, showing off. I used to do that - in 2001. It's fun. But I wasn't designing high-profile websites with important text content.
Angry old man take: people that do HTML are young people that don't mind doing fairly complex technical work for peanuts, because they can get visual satisfaction more quickly.
"Design" is something that is after a one or two trick pony. It is intended to disrupt known patterns (often loaded with decades of collected wisdom, sometimes legitimately backward).
Since the UI footsoldiers are all underpaid interns being churned on a yearly basis, collected wisdom won't be transferred unless it was provided in education.
It's not just HTML. There's a reason the same IT mistakes occur over and over and over. IT ages out all the people that achieve "wisdom". They either move above the point where "progress and wise refinement" would occur into the world of enterprise visio diagram engineering, or out of the industry period.
Set your browser to open every website in reader mode by default. It takes one week to get used to and then you will never want to go back. You can without hassle add exceptions for those websites that are not good in reader mode. This solution works great on desktop and mobile.
> What are my options? Open the developer tools and tweak the CSS every time? Try to find a good browser extension that solves the problem? Write my own? And some of these solutions are inconvenient or impossible on mobile.
I wrote a bookmarklet a few years ago that doesn't always work, but does work most of the time.
I find this a good compromise between "the original design" and "reader mode", which I find often changing too much.
Biggest downside is that it doesn't work well for "dark mode" websites, where low-contrast seems the most prevalent, but I find "dark mode" very hard to read even with good contrast so I typically tend to just not read those sites unless I really need to.
Buy an OLED monitor/tv and an OLED smartphone. The issue is still there, but to a much lower degree. Also, black is black (off). "Once you go black, you can't go back."
I'm always amused by HackerNews being presented as this awful, unreadable, low-contrast atrocity, when it is the most user-friendly, easiest-to-read, most seamlessly customizable thing I access on literally any given day.
That being said, yes; awful low-contrast sites exist. But it's not, hah, black and white. There's certainly such a thing as too high of a contrast - depending on the person, monitor, and background light.
The comments in lower contrast are ones that have been downvoted. The more it is downvoted the less and less visible it becomes. It's clever but it makes the site less accessible.
But other elements, including submission text like in an Ask HN thread are also too low contrast.
That's what happens with flagged posts. The point of graying posts is to leave a chance for redemption when snowflakes brigade those who post worthwhile comments that don't align with the groupthink. Enable flagged posts and you'll also find some that never deserved to be eliminated so vouch for them.
Arguably the best feature of the web is that any content can be zoomed in and out as much as one pleases without problems. It does break on some websites, but as someone who zooms in most content I find it's relatively rare.
If you make text large you will have people complaining the text is too large. If you make text small you will have people complaining the text is too small. You you make text somewhere in-between you will have people complaining from both ends. So as long as you ensure it can be zoomed it doesn't really matter.
It's 9pt text, if that's unreadable the issue is with your user agent. I know a lot of browsers behave poorly on larger displays, but having each website guess how big a typical monitor is and use a treadmill of increasing font sizes is not an answer; you should demand better behaviour from your browser.
My understanding is that there is no "right" thing.
There will be cases where you want font sizes to be absolute and not vary depending on the system. For instance if it's text that comes with specific graphics of fixed size, or there are strong layout concerns bound to it.
In other cases you'll want relative sizing and adjust to the user's system preferences as much as possible.
That's a decision that has to be made site by site, element by element, which is why em are a recommandation, and couldn't blanket replace absolute units.
The fonts on HN are a bit small. I have my browser set for HN to get a 125% magnification.
The comment text is a nice #000000, but the rest of the text is #828282, which is insufficiently contrasty. Lighthouse flags this, as well as some other accessibility issues.
I notice that on mobile the front page will sometimes have tiny text and if I reload then it will be larger. I'm not sure why the non-deterministic behavior there.
The line length of about 144 is uncomfortably long. It should be about half that. Line height of 1.5 would improve readability as well.
I do not think people in general need maximum contrast. What they need is near optimal contrast and there are objective recommendations on how to achieved it.
What we often have instead is barely readable light gray text in the name of "clean" design. Well it is not clean, it is moronic. If creators disrespects potential readers that much they might as well present blank screen and be done with it.
Normal comment text on HN is fine, but the title and description text on a post page is absolutely awful low-contrast.
It's medium gray on light gray. It's #828282 against #F6F6EF, a contrast ratio of 3.54:1 which is a fail. WCAG 2.0 level AA requires at least 4.5:1 for normal text. This isn't subjective or aesthetics, it's an objective measurement.
It's genuinely uncomfortable to read when it's a long "Tell HN" or similar.
> There's certainly such a thing as too high of a contrast
Not really, as long as you can adjust your screen brightness. That's what screen brightness is for. You can always decrease contrast that's too high, but you can't increase it much if it starts too low.
> This isn't subjective or aesthetics, it's an objective measurement.
I’m going to push back against this slightly (I’m not disagreeing that the HN contrast is bad, but I am challenging the WCAG ratios). It’s objective, but it’s not a good measurement. WCAG computes contrast in sRGB, which is not perceptually uniform. As such there are cases where WCAG will give better scores to worse contrast. For example, the WCAG math prefers black text on a medium blue background to white text on a medium blue background, which is the exact inverse to what most people feel is most legible.
Aren’t 99% of users going to be on some random sRGB display, though? How many of us have wide gamut displays that are actually properly calibrated? Looking at the examples from your link is illustrative… several of their 4.5:1 passes are basically unreadable. What I suspect needs to happen is an additional penalty if the background isn’t what would be considered a typical paper color (white, ivory, tan, etc. blues, purples and oranges are right out. )
It's not that it's wrong to focus on sRGB but the computation itself does not use linear gamma (which is not excusable - incorrectly assuming that 2.2 gamma is how people perceive light results on overemphasis on brighter spots)
> This isn't subjective or aesthetics, it's an objective measurement.
Its an objective measurement, but whether the standard is correct or not is a subjective question of aesthetics. Or it could be empirical question if there qas a performance goal tied to it, and it was a testable proposition whether the objective measure corresponded to the performance goal optimally (sibling comment addressing perceptual uniformity suggests that for any given performance goal, that probably is not the case.)
That's more statement due to how terrible other sites are; for example's HN utterly fucking idiotic idea of making any "Show HN" posts text body light gray
HN's page styling is simple and stable enough that if someone comes here often and has any sort of visual or readibility complaints they can just fix their own issues by modifying the CSS in my opinion.
I didn't say so - I said it's easy for the user to fix in case people haven't. Practicality > theory. Obviously the website fixing it is the best option.
But it’s a bit ironic that this website is impossible to read on mobile because the font is TINY - my other massive pet peeve as a person without particularly good vision.
149 comments
[ 201 ms ] story [ 3357 ms ] threadhttps://pagespeed.web.dev/analysis/https-contrastrebellion-c...
Apparently the reason for the awful sizing on mobile is missing the responsive viewport meta tag... IDK, I agree with the content of the website but it's just mind-numbing that it has these issues.
How ironic.
I did not see that the website was this old when I first saw it. Still, I've used websites from the 90s that worked better on mobile lol (I also used websites in 2023 that were awful, to be fair).
Apple first invented it for the iPhone 1, published it in 2007, and other manufacturers of mobile browser then copied it.
https://developer.apple.com/library/archive/documentation/Ap...
At the time for iPhone 4 the viewport meta thingy was an old thing, but of course a lot of websites hadn’t updated in the previous four years.
The CSS Working Group has for some years specs in preparation which would make the viewport thingy official:
https://drafts.csswg.org/css-viewport/#viewport-meta
This was not a website designed for mobile - that's why it doesn't look appropriate on mobile. Not every website is designed for mobile - in fact there are usually two completely different websites for mobile and desktop. This one is only for desktop. This complaint is like renting a sports car and complaining it's not doing a good job at transporting your piano.
There is one actually valid issue with the website though, which you do not bring up. It singles out websites for some reason, when the issue has zero to do with websites. Windows itself - all over the place - has ridiculous light gray on white, or light gray on dark gray (in dark theme). It's literally not readable half the time. Android has the same - now with more empty space, and page scrolling through 2 lines of tiny text and a toggle that changes description on toggle, so you don't know what it's doing. Heck, the service tag printed on the bottom of my silver dell laptop, is gray.
then we have things like expensive custom license plates with nature pictures and a tiny font. that all the drug dealers buy. and lastly - faces. the only way to tell a nose from a cheek from afar, is light-tan vs dark-tan (in the shadow). And with some people, the only way you can find them at night at all, is if they smile at your joke.
But this is not a complicated web application, this is a web document. If they had just added the right meta tags, it would have probably been enough. I'd be surprised if you really even need media queries for a page like this, just judicious use of `rem` and `%`. It's also very easy to test - just make your browser window thinner. Or open devtools on the side, and drag it around a bit. Or there's even a button in most browsers' devtools where it'll show the page in different common mobile and desktop sizes. I think lighthouse usually defaults to mobile too. (Not that lighthouse is necessarily all that valuable of a metric, but it's there, it's a couple of clicks away.)
The point the website is making is that accessibility is important. Light text on a light background might be aesthetically pleasing, but it's difficult to read for many people, and as developers and designers, we have a duty to make our work accessible. I fully agree. But mobile users - and especially mobile-only users - are also an important demographic, and deserve accessibility considerations as well.
Especially when those accessibility considerations would take at most half an hour of work.
Websites, for the most part, aren't composed and administered by government agencies, to provide beneficial information or services paid for by taxes (and it is instructive that federal agencies have been section 508 (of the Rehabilitation Act) compliant for decades, precisely because they are taxpayer funded and therefore have an obligation to make information and services accessible).
So why shoot themselves in the foot, from the get-go? It's not my right that you make your site readable to me. But if you want me to be a repeat visitor, then why make it a difficult and frustrating experience for me? Any person who produces such a site has misplaced priorities.
Which are which?
I can't understand exactly which sections the lighthouse report is flagging. I also thought I wasn't sure some of those sections were sufficient contrast, but all the ones I tested actually did pass WCAG contrast test.
If the web page has chosen to make some sections intentionally bad contrast but others good contrast, without telling you which are which... that is not the educational strategy I would have picked. But I'm not convinced it's doing that.
But you are?
but yours do not?
yes, i'm convinced that an article that talks about good and bad contrast, gives examples of varying contrast. because, again - eyes.
Although to be sure, there are a few sections that looked low contrast to me. When I checked them with a WCAG altorithm contrast checker, they all easily exceeded AAA limits.
I concluded that the page might have been intending to show that you still had a lot of flexibility in color choices, while meeting WCAG standards. (The WCAG standards are mentioned on the page).
Of course, it's possible the WCAG algorithm/standard is at fault -- it is hard to totally capture human perception in a measurement (not to mention different humans are different), and there are other times I have had color combinations that I find hard to read but which pass the WCAG measurement.
But the WCAG standard is, again, mentioned on the page, with no disclaimers.
I think there may be something worth talking about going on, but I'm definitely not convinced it's what you think.
There are sections of the page that _say_ they are showing you screenshots of _other_ people's pages that are too low-contrast, that part is clear. But you are convinced sections of the page itself with the authors words are supposed to be obviously hard to read due to contrast?
Maybe. I guess we'd have to ask the authors. Seems a weird choice to me, to do that without mentioning you are doing it.
But either way I still am curious if you wanted to identify which sections of the page you are identifying as deliberately too-low-contrast. I'm curious if they are the same ones that looked hard to read due to contrast to me, and I'm curious how they do on the WCAG metric (I didn't look for every single section myself).
This is a very problematic take, and is simply inaccurate when it comes to the web.
If you write zero CSS, a web page will render just fine on any display. Text will auto-wrap and be legible. The web is "responsive" by default. It's the designers who try to rigidly align things with specific widths, explicit sizes, and absolute values that make web pages harder to read and use.
Meaning, any given element shouldn't have a `width`, it should have a `max-width` instead. Text should have a relative font size to headings or other text. Alignment should take into consideration overflow, as it will by default with flexbox and grid. Everything by default will flow in some way and try to make it onto the page.
It's all the violence of designers that makes things both less device friendly and less accessible, just like these poor contrast decisions.
"violence"? seriously? You should maybe dial back the hyperbole a bit.
No, those parts are done as screenshots. The places it’s complaining of low contrast are in the actual document and supposed to be high enough contrast.
> Not every website is designed for mobile - in fact there are usually two completely different websites for mobile and desktop.
This was never true. Websites that split desktop/mobile completely were always a tiny minority across the entire web, though a decade or so ago it was certainly absurdly common among big players. But fortunately those days are past, and the considerable majority of sites that ever had a hard split have unsplit.
No, in this case it’s just a badly-implemented website from an era where that didn’t matter quite so much, and they haven’t fixed it in the decade since.
Only if your designer is too clever for his own good.
Plain HTML works fine on mobile (with the meta tag added to tell mobile browsers no to be stupid) so if your website doesn't then it's because something YOU deliberately added.
I'm totally on board with their thesis and was about to come here and sing their praises, but then I found that they've annoyingly conflated page links and anchor links so the back button didn't do what I expected it to.
In any case playing whack-a-mole with modern web design flaws seems worthwhile to me so I'm in favour.
Not to mention it's also hard to read. While this website works well and has a great community, it is kind of the embodiment of this meme: https://twitter.com/TheProgrammerMe/status/16528824903596810...
But in general, I have issues with site font sizes and contrast as well. I'm extremely near sighted, and getting older - I have no idea how people can actually read long form content on cell phones with the tiny screens...
Yeah, I can understand kids wanting to play with whatever's new in HTML5 etc. But I don't get why the manager in charge of the project doesn't say "Yes, very cool; but it's unreadable if there's sun-glare. Fix it, please."
Well, I do sort of get it; the manager's a kid too, and he likes custom controls and "distinctive" typography as much as the developer, and doesn't know anything about accessbility. I'm not talking about real accessibility; I just mean ordinary people being able to access the content.
Yeah, you can say "fuck it, I'll go somewhere else". But a lot of sites that I rely on have unique content.
If you're not using browser default colors, respect `@prefers-color-scheme`.
Not to mention the deplorable scroll-hijack.
I think we may need a whole series of rebellions.
If you can't solve it with CSS presets, I think it's better to stick with higher contrast for these reasons. For my blog I just use black-on-white, even though for me personally it's too much if it's more than just a couple of paragraphs. I tend to lower my display brightness while checking my own blog. :)
Another nuance I don't see discussed is at least not keeping the empty background around the content div at the maximum value level. It's just emitting pure light around the main content for no use.
Depends on the screen. You don’t know if the viewer is using e-ink or something like that (or even printing to paper—though in that case especially, colours specified in your stylesheet are more likely to be just ignored). If they’re using an LCD or similar, you also have no idea about their brightness settings. They might be ridiculously overbright, as is stupidly common, or “maximum contrast” may actually be delightfully pleasant because they’ve got sensibly-set brightness. Certainly for me in my current lighting circumstances, simple black on white will look delightful, matching the ambient lighting neatly.
I tend to think the "sensible" setting for the hardware is to afford the maximum dynamic range. This way no loss occurs if the material requires it, but if not, it needs to be limited it in software. This, of course, would lead to "ridiculously overbright" text, and limited contrast solves this problem more or less completely (this is why I override the background colour for my PDF viewer). My opinion is influenced by working with graphics, though.
I also believe the most common display technology used for desktops should be this baseline, and currently it's LCD.
However, this creates problems for people with different hardware and different eyesight and light sensitivity. Perhaps it's the OS that should provide some tooling to display the colours differently for different displays and different modes (image/text/other). The changes must be informed by the software, so for example, you could mark you site's colourscheme as "for reading" and the dynamic range would adapt properly.
The way the OS adapts that I saw is atrocious, perhaps because optimized for a different metric. My laptop changing the display brightness and contrast when I use Windows on battery looks bad regardless of what's on display.
That's just a problem with manufacturers putting displays with high dynamic range into devices and not putting decent HDR software implementations in.
Some apple devices are smart about it though. When you open up an HDR video, it cranks the backlight to make those highlights pop, but dims the LCD by lowering the contrast in software. This means high contrast websites don't sear your retinas while your media can still take better advantage of your display.
https://prolost.com/blog/edr
Why? The difference is barely noticeable, but black provides more contrast and IMO looks better than #1b1b1b.
I've seen many designers assert that being slightly off-black is "better" for some reason, but isn't this the same argument that eventually leads to low-contrast designs? Why is a little bit of contrast reduction good, but a lot is bad? Pure black always looks (slightly) better to me (I commonly open the inspector and toggle the color to test this). And anyway, the variation in people's monitor settings is probably much wider than the difference between #1b1b1b and black, so what is even the point? Why waste brainpower trying to decide exactly how much contrast reduction is good, and risk going too far for some people while creating an imperceptible difference for others?
(To be clear, if it's not obvious, I'm a big fan of this site's message... but apparently I'd go even further.)
https://ianstormtaylor.com/design-tip-never-use-black/
In the case of characters, especially hanzi/kanji, ones that are hard to recognize/distinguish either evolve (simplify and/or develop disambiguating features) or fall into disuse. Clearly “hard to recognize” is driven by physiological structures that are by definition “natural”
Older scripts, and those descended from other roots, seem to have this property.
Of course in practice Arabic writing is as easy or hard for humans to learn as any other system, so the evolutionary pressure/affordance to get rid of hard parts still applies.
But the theory of early visual system affordance could in principle be studied (though I don’t think fmri is really solid enough yet). Any historical implications of course will always have to remain theoretical.
Writing has technological constraints as well; look at cuneiform vs, say, Pali. Since Arabic evolved after predecessor systems already existed, technological affordances clearly had a, or the, major influence.
Edit: I read your comment again, and just to be clear: your question is really “why is Arabic different”. Latin, Georgian, Aramaic, Brahmic, Chinese, Egyptian Hieroglyphs, Maya pictographs, all have roughly the same form factor.
A few things are truly black, because you don't get to see their color. But "nothing" has actually the color black.
Anyway, even for painting, the fact that they have a paint for it means it happens on nature. It's just very rare, so everybody has to learn the lesson that no, you don't use black paint for that black thing you are seeing.
For computer interfaces the entire thing is obviously bullshit since the beginning. But well, our area has a thing for accepting obvious bullshit.
My site has a "dark mode" style theme - dark background and "white" text.
When I was initially designing the theme, I opted for a slightly-less-white text color, and as I've spent more time on it, I ended up bumping that color to be closer to pure white. (I'm using Tailwind, so this change amounted to "text-neutral-400" -> "text-neutral-300".)
I think I did this because the "more white" color seemed... sharper (very insightful, I know)? Like it was "an assault on the eye" to have the color be so bright. As I continued working on the site, I decided, in short, that that was stupid, and that I should have more contrast.
This was a good reminder for me that some of my pages need that styling updated, but it works out well for demonstrating the difference:
This page has the old, less contrasting color for the body text (text-neutral-400): https://epiccoleman.com/posts/2023-03-07-how-i-built-this-si...
This page has the new, "whiter" color (text-neutral-300): https://epiccoleman.com/posts/2023-04-05-svg-circle-of-fifth...
After skimming through these again as I linked them in this post, I think I could even bump it up to be even closer to white.
I also have a pretty bright monitor (it's an Apple Thunderbolt Display that I got for a pittance from my old office when they switched to Dell monitors). So that may be influencing me towards slightly less contrast.
Anyway, not to ramble, but I guess my point is - design is hard! It's not easy to take into account all the myriad different factors that need to be considered to make designs that look aesthetically pleasing while maintaining readability at various brightnesses and screen sizes and so on and so forth.
Edit: One other consideration - I wanted some color contrast between elements like text, headings, and the post date - so that's another thing I was trying to take into account. For example, if you want your headings to be a bit brighter than your text, you're left using (for example) text-neutral-200 for headings and text-neutral-300 for text. Again, as I continued tweaking, I realized that the size difference between headings and text does enough work establishing contrast that this was unnecessary - but it's just one more factor in a long list of things a designer has to think about to make things look right.
This part of your problem: if you're doing any design work, understand the specification you're designing for. This goes for any photographer, print designer, or web dev.
sRGB, bt709, rec2020, and SDR content in rec2100 contexts define the brightness of white as 100 nits, and is generally considered acceptable to be between 100 and 120 (as you often need to offset for ambient lighting to maintain perceptual white).
Your perception of both luma and chroma contrast, but also your perception of color itself, changes over the range of brightness your eye can perceive; the organic gamma curve of your eye also changes. Example: sRGB gamma and bt1886 EOTF are intended to be used with content that has a 2.4 gamma and a near-D65 whitepoint at around 100 nits; the same content at "theater darkness" (48 nits) will be encoded with a warmer/yellower white point, at 2.6 gamma, to maintain perceptual similarity.
And why is this? The rods (low light vision) and cones (bright light and colors vision) in your eye have different organic gamma curves (incl. each of the three cones have different curves in-of themselves), and the rods do not respond to all visible light equally and have a broad "color" of their own and rods continue to function and influence perception in bright light situations.
You can argue, "but Diablo, most people do not calibrate their displays", which is absolutely true; most displays, however, are manufactured with defaults that mimic the intended use of sRGB and bt709 content, and users, left to their own devices, generally will choose a brightness that approximates 100 nits plus an appropriate offset for ambient.
However, even for your own personal website, buy a colorimeter, whip out the DisplayCal software, set your profile to "Video (D65, BT1886)" (not "sRGB" due to modern content being mastered entirely for displays manufactured in the past 15 years; BT1886 handles perceptional similarity and better in dark values than sRGB's weirdly defined ramp), and then enjoy being able to author content for a wide range of displays.
It's like design's equivalent of not ending sentences with prepositions.
For personal themes I do use a bit of off black, althought usually it's something like very dark gray. It just makes screen not a complete black hole late at night
[0]: https://darkreader.org/
https://web.archive.org/web/20111006171723/https://contrastr...
Just adding some context.
https://www.squarefree.com/bookmarklets/zap.html
They don't work on every site, but they're a good start. 'Reader mode' bookmarklets like https://github.com/lordastley/readable can often be configured for simple white on black text too.
Small fonts are one thing. There are browser hot keys to change the font size. And I'm a huge fan of the "Zoom Text Only" option in Firefox where the rest of page doesn't go flying off the edge of my viewing area. But low contrast text is hugely annoying. What are my options? Open the developer tools and tweak the CSS every time? Try to find a good browser extension that solves the problem? Write my own? And some of these solutions are inconvenient or impossible on mobile.
I understand using low contrast text (and small fonts) for tedious but necessary legal disclaimers. But if you use it elsewhere, I'll move on—either you have nothing to say and don't really want people to read the text, have a poor designer, or are generally incompetent.
Grey-on-grey text is idiotic. It's everywhere. So is scroll-jacking; so is weird animations on text articles (The Guardian does this from time to time). So is web-pages that come up as a sheet of whiteness, if you don't want to run javascript indiscriminately (REACT, I think). So is megabytes of script, just to display a page of text.
This kind of stuff is weenie web-developers, showing off. I used to do that - in 2001. It's fun. But I wasn't designing high-profile websites with important text content.
"Design" is something that is after a one or two trick pony. It is intended to disrupt known patterns (often loaded with decades of collected wisdom, sometimes legitimately backward).
Since the UI footsoldiers are all underpaid interns being churned on a yearly basis, collected wisdom won't be transferred unless it was provided in education.
It's not just HTML. There's a reason the same IT mistakes occur over and over and over. IT ages out all the people that achieve "wisdom". They either move above the point where "progress and wise refinement" would occur into the world of enterprise visio diagram engineering, or out of the industry period.
Now get off my lawn.
Set your browser to open every website in reader mode by default. It takes one week to get used to and then you will never want to go back. You can without hassle add exceptions for those websites that are not good in reader mode. This solution works great on desktop and mobile.
I wrote a bookmarklet a few years ago that doesn't always work, but does work most of the time.
I find this a good compromise between "the original design" and "reader mode", which I find often changing too much.Biggest downside is that it doesn't work well for "dark mode" websites, where low-contrast seems the most prevalent, but I find "dark mode" very hard to read even with good contrast so I typically tend to just not read those sites unless I really need to.
But to be fair this page was better than most pages that dare to do it, it was almost not buggy on this page.
That being said, yes; awful low-contrast sites exist. But it's not, hah, black and white. There's certainly such a thing as too high of a contrast - depending on the person, monitor, and background light.
Not quite sure what the point of some comments being in lower contrast.
But other elements, including submission text like in an Ask HN thread are also too low contrast.
I think making them unreadable is the point?
It's a bit off though, since it e.g. also applies to the "officially selected" Launch HN: posts.
For the designer it might be "a bit inconvenient to read", and for somebody else it might be "literally impossible to read".
As for downvoted posts, eh, it would be better to collapse them by default or something instead of showing them but making them unreadable.
E.g. https://news.ycombinator.com/item?id=35852495
Arguably the best feature of the web is that any content can be zoomed in and out as much as one pleases without problems. It does break on some websites, but as someone who zooms in most content I find it's relatively rare.
If you make text large you will have people complaining the text is too large. If you make text small you will have people complaining the text is too small. You you make text somewhere in-between you will have people complaining from both ends. So as long as you ensure it can be zoomed it doesn't really matter.
There will be cases where you want font sizes to be absolute and not vary depending on the system. For instance if it's text that comes with specific graphics of fixed size, or there are strong layout concerns bound to it.
In other cases you'll want relative sizing and adjust to the user's system preferences as much as possible.
That's a decision that has to be made site by site, element by element, which is why em are a recommandation, and couldn't blanket replace absolute units.
There's something ironic about the fact that I am reading your statement, then.
The comment text is a nice #000000, but the rest of the text is #828282, which is insufficiently contrasty. Lighthouse flags this, as well as some other accessibility issues.
I notice that on mobile the front page will sometimes have tiny text and if I reload then it will be larger. I'm not sure why the non-deterministic behavior there.
The line length of about 144 is uncomfortably long. It should be about half that. Line height of 1.5 would improve readability as well.
What we often have instead is barely readable light gray text in the name of "clean" design. Well it is not clean, it is moronic. If creators disrespects potential readers that much they might as well present blank screen and be done with it.
It's medium gray on light gray. It's #828282 against #F6F6EF, a contrast ratio of 3.54:1 which is a fail. WCAG 2.0 level AA requires at least 4.5:1 for normal text. This isn't subjective or aesthetics, it's an objective measurement.
It's genuinely uncomfortable to read when it's a long "Tell HN" or similar.
> There's certainly such a thing as too high of a contrast
Not really, as long as you can adjust your screen brightness. That's what screen brightness is for. You can always decrease contrast that's too high, but you can't increase it much if it starts too low.
I’m going to push back against this slightly (I’m not disagreeing that the HN contrast is bad, but I am challenging the WCAG ratios). It’s objective, but it’s not a good measurement. WCAG computes contrast in sRGB, which is not perceptually uniform. As such there are cases where WCAG will give better scores to worse contrast. For example, the WCAG math prefers black text on a medium blue background to white text on a medium blue background, which is the exact inverse to what most people feel is most legible.
https://github.com/w3c/wcag/issues/695
It’s the biggest thing I wish would be changed in the WCAG.
Its an objective measurement, but whether the standard is correct or not is a subjective question of aesthetics. Or it could be empirical question if there qas a performance goal tied to it, and it was a testable proposition whether the objective measure corresponded to the performance goal optimally (sibling comment addressing perceptual uniformity suggests that for any given performance goal, that probably is not the case.)
Outdoors on a sunny day is no time to read HackerNews! Get offline and enjoy your day.
Fear not downvoters, I speak as a fellow addict.
I've been thinking the same thing.
[0] https://news.ycombinator.com/newsfaq.html
But it’s a bit ironic that this website is impossible to read on mobile because the font is TINY - my other massive pet peeve as a person without particularly good vision.