Last modified: 2014-01-31 20:30:17 UTC
The growing use of grey color in the Wikimedia interface makes it more and more hard to read text on a computer screen (haven't tested other devices yet). Please, don't let Flow take that direction, too: use black font wherever possible (or else feel the despair of those of us with vision impairment). People who fancy grey or pink so much they have to use it everywhere can add proper CSS rules to their Common.css stylesheets; hell, I can even help them do that. Thank you.
The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/639, but people from the community are welcome to contribute here and in Gerrit.
I totally concur. This is problem seems actually to appear in two increments: 1) Text that is actually designed to be gray (somewhere around #666). This is very hard to read and should not used at all. Either the information is important (than it can be colored black) or it is not (then it can be left out or linked to). This nuisance even affects text that is clearly important and should *never* be colored in gray, e.g. the header of Flow pages or text in editboxes (replying is the most important feature of talk pages after all; why is the text gray???). 2) Text that is black by design but colored in a very dark gray for "technical" reasons (somewhere around #333). It is often said black on white would be too harsh to read. This is actually a web developer's myth. Every software uses black on white and also most printed media uses black on white (at least as far at it is technically possible). If real black text on white background actually hurts your eyes, then you should adjust your display (probably turn down brightness). We shouldn't mess with text colors to compensate for users not having their hardware set up correctly. Maybe some users have very dark displays with low contrast - further reducing contrast by using dark gray text will even reduce readability for them.
I agree. Gmail uses black, facebook uses black, linkedin uses black, loomio uses black, wordpress (by default) uses black. This is not a coincidence. I'd really love to see the supporting evidence for dark-grey-on-lighter-grey.
Yes please, nothing brighter than #444 for text. Dark greys on light beige backgrounds do sometimes look better than pure black on pure white, but we need to consider the contrast carefully if we try this.
Hello all, while readability is rather subjective depending on eyesight, brightness of screen, environmental conditions, screen type, etc. Books aren't a great example since they aren't backlit, and most paper isn't "bright white" its cream or off-white. One of the issues with making a blanked statement like "use back everywhere" is that if you follow though with that you can never use true black text as a way of giving emphasis to elements that need it, and you are forced to rely on other things like color fills, italics, bold, etc. Gmail uses black for some, but not all elements for this reason, Facebook does not use black for their main body text (its #333333 if you sample the computed output) You can use a tool like http://www.msfw.com/accessibility/tools/contrastratiocalculator.aspx to see that pure black #000000 on #fffff comes out to a computed contrast ratio of 21:1 where as #666666 on #ffffff is 5.7:1, well above the minimum and approaching the "enhanced" contrast levels. While I'm sure we're all able to find examples of people who's opinions are that pure black on white are either easier to read or more difficult to read I think in many cases it comes down to personal preference and what people are used to. To the flow specific comments, we here you, and flow is still in development, we are working hard to make sure we balance readability with information hierarchy, I believe we'll get to a good place with everyones feedback. The argument about people should just turn down their monitor contrast works both ways, if you find #666666 on #ffffff to be unreadable, perhaps your monitor contrast is set too low. When we made the lefthand navigation links dark grey as part of the first iteration of the typography update beta feature (https://www.mediawiki.org/wiki/Typography_Update) some argured that it was lower contrast, even though it was a measurable increase in contrast from 7.9:1 to 19.4:1 so while we value readablity as one of the most important aspects of designing for the huge ammounts of text on the sites.
@Jared: I read your comment, but I have no idea what it means.
I think Jared is saying to things: 1) He does not want to use black for normal text because he could be using real black for some form of emphasis; 2) He believes that #666 on #fff is still okay, because http://www.msfw.com/accessibility/tools/contrastratiocalculator.aspx shows #666 background contrasts pretty well with white foreground text.
+1 The use of grey is super annoying. (You can cite whatever you want claiming contrast is sufficient, all I can say is I find it annoying, with less contrast being one [but not the only] reason)
When planning color scheme you also need to take into account appropriate contrast between link text and non-link text, including active and visited elements. So, link text needs to contrast not only against the background but also against the non-link text. This article (from another Jared by the way) http://webaim.org/blog/wcag-2-0-and-link-colors/ explains in the easy way that if your primary colours are not white and black the choice for links gets very limited. I also have to take note that relative luminance cannot be the only factor, since for example I feel that #666 text on #fff background vs. #fff text on #666 have different readability, but the same relative luminance according to WCAG definition. (If you are interested, I find #fff on #666 bg more "contrasting" than #666 on #fff). There is an interesting remark herehttp://markboulton.co.uk/journal/five-simple-steps-to-better-typography on the white text on dark background schemes: > When reversing colour out, eg white text on black, make sure you increase the > leading, tracking and decrease your font-weight. This applies to all widths of > Measure. White text on a black background is a higher contrast to the opposite, > so the letterforms need to be wider apart, lighter in weight > and have more space between the lines. Seen many usability consultants and fads come and go I'd be extremely cautious here. For example, when working on the terminal emulator I definitely prefer light on dark while most light on dark websites are more difficult to read? I don't seem to be getting answer from various experts around.
The way this bug is formatted is not actionable: "use black font wherever possible" is not a clear issue that can be fixed/not fixed. Since this is 1) largely about subjective design choices and 2) beyond the scope of Flow, I'd suggest taking this discussion to the design team mailing list.
(In reply to comment #10) > The way this bug is formatted is not actionable: "use black font wherever > possible" is not a clear issue that can be fixed/not fixed. The bug description probably could use better wording, but the issue described here is very real and also very actionable: solving it should be about as simple as giving the desired CSS element(s) color: #000; > Since this is 1) largely about subjective design choices Probably, but users are silly in that they like their features usable, and white-on-white, black-on-black or gray-on-gray in this case doesn't exactly win the Usability Award of the Year or so. > and 2) beyond the scope of Flow How come? Admittedly the initial report's wording ("Wikimedia interface") might suggest that it's a wider issue, but it's definitely happening with Flow as far as I've been able to see. I don't think that "Flow's text is close to unreadable" is not an issue with Flow.
(In reply to comment #11) > (In reply to comment #10) > > The way this bug is formatted is not actionable: "use black font wherever > > possible" is not a clear issue that can be fixed/not fixed. > The bug description probably could use better wording, but the issue > described > here is very real and also very actionable: solving it should be about as > simple as giving the desired CSS element(s) color: #000; > I agree. If you're not going to fix it mark it WONTFIX, but INVALID is for viagra advertisements...
"If you're not going to fix it mark it WONTFIX, but INVALID is for viagra advertisements..." Err, since when? :) This bug report doesn't pertain exclusively to Flow and is formulated in a vague, unfixable way ("use black where possible"). That seems more invalid than wontfix to me, as wontfix implies a fix actually is possible. Quiddity has raised a much more actionable offshoot of this bug, which I believe captures all the relevant Flow-related issues: https://bugzilla.wikimedia.org/show_bug.cgi?id=59933. Let's just continue the conversation there.
The request is for Flow to not use the same more difficult to read gray color. That is very actionable. I'd much rather see a cream colored or gray tinted background with #000 text than #666 text on #FFF background.
(In reply to comment #13) > "If you're not going to fix it mark it WONTFIX, but INVALID is for > viagra advertisements..." > > Err, since when? :) This bug report doesn't pertain exclusively to Flow and > is > formulated in a vague, unfixable way ("use black where possible"). At best that's an argument that this should be a tracking bug. > That seems > more invalid than wontfix to me, as wontfix implies a fix actually is > possible. Trollish answer would be: * {color: black !important}
Oh come on! Since when are you WMF guys meant to be sticklers for principles? You're not exactly sustaining a productive environment with actions like these! Fact is, that essentially *every* text element in Flow is gray (it's not 50 shades of gray but i possibly comes close). The bug by Quiddity only covers the worst (which is really an accessibility problem to almost everybody). All the other usages of gray are however a major annoyance for the majority of users - are we supposed to file a bug report for each and every of those elements? Please apply some common sense when reading this bug report and don't call it invalid for some spurious reasons only to not have to deal with it...
[Please don't say "you WMF guys" when you meant to reply to comments of individuals. Thanks.]
Well, at least it is now clear that it's a WONTFIX and not an INVALID. It tells something about the attitude that's so often shown when it comes to all things Flow.
(In reply to comment #18) > Well, at least it is now clear that it's a WONTFIX and not an INVALID. > > It tells something about the attitude that's so often shown when it comes to > all things Flow. You mean that people from the team engaged and provided a lengthy and rigorous explanation as to why things are the way they are? I'd hope so, yes. In the meantime, now that this bug is closed further discussion is unlikely to be productive; let's please just move away.
(In reply to comment #19) > You mean that people from the team engaged and provided a lengthy and > rigorous explanation as to why things are the way they are? I'd hope so, yes. They did? > In the meantime, now that this bug is closed further discussion is unlikely > to be productive; let's please just move away. Bugs can always be reopened.
