https://bugzilla.wikimedia.org/show_bug.cgi?id=66021
Isarra <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |PATCH_TO_REVIEW Ever confirmed|0 |1 --- Comment #15 from Isarra <[email protected]> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
