Last modified: 2014-09-24 05:34:20 UTC
Vector currently uses grey text on a white background, which while usually fine on high-end monitors, sometimes results in issues on more consumer-grade models where the contrast can display as significantly less. This should not be the case; the content text should be black, a colour which can be expected to remain black, and thus clearly legible, even on lower-end displays. Given that Wikipedia and other projects using the Vector skin are intended to be universally accessible regardless of socio-economic status, we should be supporting low-end displays as well as high.
*** Bug 66022 has been marked as a duplicate of this bug. ***
Change 148548 had a related patch set uploaded by Isarra: Restore content text contrast https://gerrit.wikimedia.org/r/148548
Black on white is not "clearly legible", it causes eye strain in normal people and for dyslexic people causes bluring of text that makes reading difficult.
(In reply to Daniel Friesen from comment #3) > Black on white is not "clearly legible", it causes eye strain in normal > people and for dyslexic people causes bluring of text that makes reading > difficult. I'm sorry, but that's a fallacy. The idea with lower-contrast text is to simulate print media - with the softer contrast of not entirely black text on not particularly bright paper - but that simply does not work with uncalibrated monitors, which will display greys completely inconsistently. Given that any monitor that costs under $1000 is probably going to be one of these (generally only visual designers, medical professionals, and college students in coffee shops use the nice ones), you can understand why this would be an issue - the vast majority of our end users are never going to see the exact contrast we specify for them. The aim in good design is to make the interface usable to the widest span of users possible, and despite the common trend, this means setting the base contrast for important elements as high as reasonably possible. For most users, the high contrast will be fine out of the box, and for those on displays where that causes eye-strain or with disorders where it causes other problems, a fix lies in the display itself: turn down the contrast. This solves the problem not only for a single website, but for the entire internet and every other application on their computer as well. With low base contrast on the interface, however, there is no reverse option for users with the opposite problem (washed-out text) to increase the contrast, because there is simply no way to make greys black on the display-end without seriously screwing up the overall display. This is because greys aren't supposed to be black. They're supposed to be grey.
Created attachment 16032 [details] Screenshot with a gamma adjustment of 3.0 to simulate what a crappy monitor would look like for those who don't have one So google suggests monitors in the real world have gamma settings that can vary anywhere between 1.8 to 3.0 (Correct value being about 2.2) [Can anyone actually verify that? I could only find really sketchy old looking sources]. So I removed my custom css making everything black (I like being able to easily read the site :P), took a screenshot, and adjusted that gamma to 3.0 to see what people with bad monitors would see. I adjusted by using convert screenie.png -gamma .454545 tmp.png; convert tmp.png -gamma 3.0 Screenshot-gamma3.png See attached screenshot which is quite light. [FWIW, really not an expert on visual perception, colour, physics, monitors, gamma, etc. So If I made any mistaken assumptions about how gamma correction works, please let me know].
(In reply to Isarra from comment #4) > (In reply to Daniel Friesen from comment #3) > > Black on white is not "clearly legible", it causes eye strain in normal > > people and for dyslexic people causes bluring of text that makes reading > > difficult. > > I'm sorry, but that's a fallacy. Please do not jump onto the "it's a fallacy" argument. What I said was not a fallacy. And the lone assertion was pointless anyways, since rejecting something on the basis the argument has a fallacy is itself a fallacy, the only point of pointing out something is a fallacy is when you are identifying what type of fallacy it is and explaining the failure in reasoning. ((Btw, thanks for giving me a reason to read through the Wikipedia article on fallacies and the definitions of fallacies other than those on https://yourlogicalfallacyis.com/ ;])) ---- It's difficult to look up actual studies to extract information from, with the internet is so full of simple advisory posts and few of the studies online, but I did find one useful study with some useful information: http://www.w3.org/WAI/RD/2012/text-customization/0 That along with some of the other material I found [0][1] suggest that changing the default background color might be more useful than changing the default text color. It would be nice to get someone from the team that did the typography refresh in here. I'd like to know if they didn't mess with the default content area background color because of the difficulty of doing so. [0] http://essay.utwente.nl/63321/1/Pijpker,_C._-_s1112430_%28verslag%29.pdf [1] http://books.google.ca/books?id=PTg0fVYqgCcC&pg=PA616&lpg=PA616&dq=dyslexia+black+white+text&source=bl&ots=O9JOwHfDt1&sig=GUL2avkVBP7mAUNru2t-DuQHeIs&hl=en&sa=X&ei=EabQU9KkEurGiwKrzIGYBw&ved=0CDUQ6AEwAzgK#v=onepage&q=dyslexia%20black%20white%20text&f=false
(In reply to Bawolff (Brian Wolff) from comment #5) > Created attachment 16032 [details] > Screenshot with a gamma adjustment of 3.0 to simulate what a crappy monitor > would look like for those who don't have one > > So google suggests monitors in the real world have gamma settings that can > vary anywhere between 1.8 to 3.0 (Correct value being about 2.2) [Can anyone > actually verify that? I could only find really sketchy old looking sources]. > > So I removed my custom css making everything black (I like being able to > easily read the site :P), took a screenshot, and adjusted that gamma to 3.0 > to see what people with bad monitors would see. I adjusted by using convert > screenie.png -gamma .454545 tmp.png; convert tmp.png -gamma 3.0 > Screenshot-gamma3.png That screenshot looks very similar to the grey (#252525) text to me (on the same monitor). That's the main problem I'm trying to get at, though - gamma is an issue, but there's a lot more to it than just the gamma. Even with differences in gamma, defined black and white do tend to look pretty similar across devices (some may be brighter or more black than others, but it is basically still black and white), but how the contrast is handled in between those colours may be completely different, resulting in the appearance of greys varying wildly. They can potentially show up as anything between black and white, or even just AS black or white. Examples: * #444: Looks like a good dark grey background colour for displaying images against (because it won't distract from the image, but will still result in enough contrast to make out any black elements) on one screen. Just looks black on another. #888, on the other hand, looks the same on both. So does #eee. * #f6f6f6: Used, along with some light blue, to make the gradients in the vector skin. Completely indistinguishable from white on one monitor. Tabs are only distinguished by a small visible part of the blue gradient and the borders, and even those are hard to make out. * #222: Looks the same as #444 on one monitor. Obviously not the same colour. These are monitors I have and use. Out of six, six are kind of crappy, just in different ways (dead pixel, off red intensity, the above examples of weird contrast; it varies), but these are also fairly standard consumer models (three of them were apparently top-rated on newegg, or got labelled with some sort of award there). Unfortunately, while monitors are adjustable, because the hardware/software of/for the device itself generally isn't very good in the first place, solving for one problem usually just winds up with another. Some problems, of course, are much more preferable to others (such as an overall level of contrast that doesn't hurt the eyes, or a level of darkness that makes playing <insert popular game title here> the most enjoyable), but there will always be problems. Here's the thing, though - we don't CARE if the subtleties of the vector skin are getting lost for some people, or that the background colour a lightbox uses just looks black on some displays. That doesn't really matter, because that stuff is really just decoration. It'd be nice if people could see it, but if not, whatever. Text, though, we need people to be able to see well. Always.
Change 160481 had a related patch set uploaded by Isarra: Restore content text contrast (black) https://gerrit.wikimedia.org/r/160481
Change 148548 abandoned by Isarra: Restore content text contrast (black) Reason: I guess this is now at https://gerrit.wikimedia.org/r/#/c/160481/ https://gerrit.wikimedia.org/r/148548
I have no clear preference between #000000 and #252525. In fact, I see little difference between the two (on a properly set CRT). I do have a problem with the arguments that we need to fix our presentation for people that do not know how to set up their monitor. That, I think, *is* a fallacy. Most monitors sold under $1000 -- even sub $500 ones -- are perfectly adequate out of the box. Those still using older monitors are very few. You need proper statistics about the penetration of bad monitors. In my field as internet installer, I have seen very few -- less then 1% in my best estimate -- bad or badly set-up monitors. We should accomodate for most readers, but we cannot accomodate *all* readers; that is simply an impossible task.
(In reply to Erwin Dokter from comment #10) > I have no clear preference between #000000 and #252525. In fact, I see > little difference between the two (on a properly set CRT CRTs tend to have much higher contrast than LCD monitors, so either colour would probably look exactly the same there. Those are a whole different monster. > I do have a problem with the arguments that we need to fix our presentation > for people that do not know how to set up their monitor. That, I think, *is* > a fallacy. Most monitors sold under $1000 -- even sub $500 ones -- are > perfectly adequate out of the box. Those still using older monitors are very > few. I would consider $500-1000 monitors to be fairly high-end as well. They're not the best you can get, but they tend to be good. Even those vary, of course, but that's fine, normally. Normally the only problem is when they're set up with too much contrast, and that's what tends to lead to eye-strain and other problems, and which was apparently the reason for using non-black colours in the first place. And you're right, fixing the presentation for improperly-set up monitors doesn't make sense. > You need proper statistics about the penetration of bad monitors. In my > field as internet installer, I have seen very few -- less then 1% in my best > estimate -- bad or badly set-up monitors. While that may not be the most representative sample, I think an important question here is what is bad? I consider my monitors bad, but that's when including medical-grade monitors in the scale. Those are the sort of monitors where the colours have to be completely exact so a doctor can tell if an organ is discoloured, or if something is a shadow or a real problem, etc. For normal use, nobody cares about that sort of thing. Mine, like most others, are perfectly fine, despite all their minor variations. The problems only really arise when designers have closer to medical-grade and then expect everyone else to also have that, and greys are dangerous only when you try to use them for things that are conceptually not supposed to be grey. Conceptually, text is black. We print with black ink. It may wind up appearing as grey depending on the type of ink and how the light falls, but the exact same thing applies to monitors. We shouldn't be mimicking the process before it even happens. > We should accomodate for most readers, but we cannot accomodate *all* > readers; that is simply an impossible task. Yes.
(In reply to Isarra from comment #11) > Conceptually, text is black. We print with black ink. It may wind up > appearing as grey depending on the type of ink and how the light falls, but > the exact same thing applies to monitors. We shouldn't be mimicking the > process before it even happens. Except the white paper that black ink is printed on is not pure white and does not emit white light itself.
(In reply to Daniel Friesen from comment #12) > (In reply to Isarra from comment #11) > > Conceptually, text is black. We print with black ink. It may wind up > > appearing as grey depending on the type of ink and how the light falls, but > > the exact same thing applies to monitors. We shouldn't be mimicking the > > process before it even happens. > > Except the white paper that black ink is printed on is not pure white and > does not emit white light itself. Doesn't matter. Bouncing light is exactly the same to our eyes as directly emitted light, and background/ambient light makes a huge difference in our perception of individual objects. The only thing that really matters is how light amounts are balanced. For example, though a computer screen usually emits its own light for the whites, other light still bounces off it, and if the white is not bright enough compared to the dark, the bouncing light can significantly decrease the apparent difference between the white and the dark. Even if there is no outside light bouncing off a screen, though, our eyes adjust to the overall brightness of everything in view, which also affects how we see individual objects (like a screen). This becomes particularly apparent in the dark. When white on a screen appears too bright, it's because the screen is emitting too much light for the environment it's in. Don't do computing in the dark unless you can turn down the brightness; otherwise that really will hurt your eyes.
In the simulated images I'm not seeing any legibility issues, in general we strive to not recreate browser or OS functionality, in both windows, os x, and I hope linux the user is able to increase contrast via display preferences. As is mentioned in this thread by others, there is a "sweet spot" when it comes to contrast, too much or too little is a problem. Our goal is to have AAA compliance on primary text by WCAG 2.0 standards, our body color of #333 on FFF passes this easily. I won't close this bug, but based on the current state of the site, I don't find sufficient proof that an issue exists.
(In reply to Jared Zimmerman (WMF) from comment #14) > In the simulated images I'm not seeing any legibility issues, in general we > strive to not recreate browser or OS functionality, in both windows, os x, > and I hope linux the user is able to increase contrast via display > preferences. If you strive to not recreate such functionality, why was the colour changed from black in the first place? Shouldn't the browser or OS be handing contrast issues? > As is mentioned in this thread by others, there is a "sweet > spot" when it comes to contrast, too much or too little is a problem. Our > goal is to have AAA compliance on primary text by WCAG 2.0 standards, our > body color of #333 on FFF passes this easily. That's a nice goal, but it's not taking things far enough. The standards are made on assumptions that just do not necessarily hold in the real world, be they LED backlights (which result in much better contrast and significantly darker blacks), high-resolution displays (better edges and anti-aliasing for the characters), or a specific type of font rendering (comparing the same colour text between how it's rendered on windows and linux, the linux one looks grew where the windows one doesn't even on the same monitor just because of how it was antialiased). I get that you can't see the issue on a mac, because that's the kind of display the standards were initially created for in the first place, but that's not what everyone else is using.
(In reply to Isarra from comment #15) > That's a nice goal, but it's not taking things far enough. The standards are > made on assumptions that just do not necessarily hold in the real world, be > they LED backlights (which result in much better contrast and significantly > darker blacks), high-resolution displays (better edges and anti-aliasing for > the characters), or a specific type of font rendering (comparing the same > colour text between how it's rendered on windows and linux, the linux one > looks grew where the windows one doesn't even on the same monitor just > because of how it was antialiased). Grey, not grew.
We define the default color, this is required, and we've defined a color which complies with the highest standards with a an agreed metric for contrast and readability. At this time I do not want to make an additional change to this value since insufficient evidence that a higher contrast value provides more benefits than drawbacks.
Please stop changing the status.
I think "At this time I do not want to make an additional change to this value since insufficient evidence that a higher contrast value provides more benefits than drawbacks." was a clear statement and a sufficient reason to close this ticket as RESOLVED WORKSFORME for the time being. Bugzilla allows adding comments without changing the bug report status. Furthermore, the patch has a -2 so currently there isn't a PATCH_TO_REVIEW left...
Thank you Andre, and thank you Issara for bringing this to everyone's attention. In the future I'll try to make an effort to add my notes, and let the original poster close the bug themselves if that is more in-line with best practices.
(In reply to Andre Klapper from comment #19) > I think "At this time I do not want to make an additional change to this > value since insufficient evidence that a higher contrast value provides more > benefits than drawbacks." was a clear statement and a sufficient reason to > close this ticket as RESOLVED WORKSFORME for the time being. Is a user closing a bug that doesn't even apply to them as WORKSFORME really how this is supposed to be used? Of course it works for them. This bug is here because it doesn't work for OTHER PEOPLE. I don't know what you want for sufficient evidence, either, considering I've provided more evidence for this bug than was ever provided to make the original change in the first place. If I could I'd just take my damn computer over there and SHOW you all what it looks like, but that's not really a viable option. Proper testing on a wider spread of hardware is really what we need, though, when it comes to accessibility and design-related things, but apparently that doesn't happen. > Bugzilla allows adding comments without changing the bug report status. > Furthermore, the patch has a -2 so currently there isn't a PATCH_TO_REVIEW > left... Um... it doesn't have a -2?
Oh, sorry, I was looking at the wrong patch. If you'll read what Jon said, he put the -2 there pending consensus on the bug. If the bug is closed because of a -2 on the patch, how in the world is it supposed to get any consensus on it?
It's actually fairly well proven that human eyes endure greater strain when the contrast is perfect (e.g., #000 on #fff). There's links and documentation someplace on mw.org; I can try to find it later. We're not in the business of accounting for badly-configured, worn-out, or broken monitors. We just aren't. In the year 2014, the use of CRTs is in rapid decline; in fact, I'm not sure when I last saw one in use - not even in poorer parts of the world. Accordingly, I don't think we need to spend a lot of time hashing over this and we should just move on.
This has nothing to do with CRTs, nor how monitors degrade over time in general. I already explained that. Nor is there any such thing as 'perfect' contrast. You can have blacker blacks and brighter whites, but overdoing that is up to the monitor, and as far as I can tell (which at this point isn't saying much), I think we all agree that poorly-configured monitors are not what we're supposed to be accommodating?
Some actual papers and things: * http://www.w3.org/WAI/RD/2012/text-customization/2 seems to indicate that lower contrast is better for dyslexics and worse for normal users, which is no better a trade-off than the other way around. * https://en.wikipedia.org/wiki/Wikipedia_talk:Flow/Archive_9#Design includes a response that covers several different things which shed further doubt on lighter text being an overall improvement, but I'll just paste the entire comment here for convenience: A reference on black on white and dyslexia would be [http://www.ra.ethz.ch/CDstore/www2012/W4A/01%20-%20Technical%20Papers/rello.pdf this] - "we found no guidelines about gray scales and readability for dyslexics apart from the suggestion of using a light gray as background [39]. Most of our participants said that grey actually did not help them. For the font (using pure white in the background) 16 users (72.73%) preferred a pure black font instead of the three options of gray scale for the font." or [http://books.google.es/books?id=PTg0fVYqgCcC&pg=PA616&lpg=PA616&dq=black-on-white+can+cause+problems+for+dyslexic&source=bl&ots=O8SLEAjvx-&sig=SJ-MSJELeYBq2pUr9ArRPIkruzw&hl=es&sa=X&ei=B3kVU9TRCory7AbZzoG4Aw&ved=0CE8Q6AEwBA#v=onepage&q=black-on-white%20can%20cause%20problems%20for%20dyslexic&f=false this] - "What visual dyslexic readers need to do is to configure the computer environment so that they can see comfortably what is on the screen". Light grey on the background seems to work better than dark gray for text; a guideline recommends a #FFFFE5 page color [http://ra.ethz.ch/CDstore/www2012/W4A/01%20-%20Technical%20Papers/santana.pdf]. It looks like this is a more complex beast that merely using a washed out grey font to automatically help dyslexic readers. If you want to support them, the most important thing seems to be allowing end-user customization. [[User:Diego Moya|Diego]] ([[User talk:Diego Moya|talk]]) 07:25, 4 March 2014 (UTC)
(In reply to Isarra from comment #21) > (In reply to Andre Klapper from comment #19) > > I think "At this time I do not want to make an additional change to this > > value since insufficient evidence that a higher contrast value provides more > > benefits than drawbacks." was a clear statement and a sufficient reason to > > close this ticket as RESOLVED WORKSFORME for the time being. > > Is a user closing a bug that doesn't even apply to them as WORKSFORME really > how this is supposed to be used? Of course it works for them. This bug is > here because it doesn't work for OTHER PEOPLE. > FWIW, based on the comments made above (particularly Jared's) I respectfully suggest WORKSFORME is inappropriate, and WONTFIX reflects the actual status of this bug. The change requested (Which is ultimately change the text colour), was refused. WORKSFORME generally means "we can't do anything about the bug because we can't figure out how to make it happen, which we need to do in order to fix it". [Or to actually quote: "problem can not be reproduced, when missing information has not been provided, or when an acceptable workaround exists to achieve a similar outcome as requested"] In my opinion, such a resolution is entirely inappropriate when the issue is reproducible by a developer; its crystal clear what would be needed to resolve the bug, should we decide that it should be resolved and furthermore there's even a patch pending to resolve the bug.
