Open Bug 859577 Opened 12 years ago Updated 10 years ago

text-background contrast ratio is too low

Categories

(www.mozilla.org :: Pages & Content, defect, P3)

defect

Tracking

(Not tracked)

People

(Reporter: bugzilla, Unassigned)

References

()

Details

(Keywords: access)

Color/brightness contrast between text (foreground) color and background color should be maximized in order to promote legibility/readability for everyone, including baby-ageing boomers, people with poor eyesight, lower vision, senior citizens. Some mozilla.org webpages apparently use #666 or #444 or #333 as text (foreground) color. Example given: https://wiki.mozilla.org/Accessibility uses the following: body { color: #444; font: 90% Arial, sans-serif; } found at the stylesheet https://wiki.mozilla.org/extensions/gmo/skins/gmo/style/screen.css at line 4 access keyword added blocking bug 225639 +CC: Fantasai, Felix Miata, Andrei Hajdukewycz, John Slater
" About 8 percent of all men have some form of color deficiency " Can Color-Blind Users See Your Site? http://msdn.microsoft.com/en-us/library/Bb263953.aspx " 8-10% of males see both red and green as brown " Accessibility in Mozilla slideshow by Aaron Leventhal: Other disabilities http://www.mozilla.org/access/slideshow/img5.html http://www-archive.mozilla.org/access/slideshow/img5.html
> Color/brightness contrast between text (foreground) color and background color should be maximized Too high contrast can also be bad. Here is an extension to look for low contrast: https://addons.mozilla.org/firefox/addon/wcag-contrast-checker/
(In reply to Aleksej [:Aleksej] from comment #2) > > Color/brightness contrast between text (foreground) color and background color should be maximized > Too high contrast can also be bad. Sure, but normally it only happens on maladjusted displays, which can and should be corrected to avoid the opposite problem developing prematurely. Too low contrast is much less likely correctable, as it's typically caused by deterioration with age of the display accelerated by running the display at excessive levels when new, and which cannot be increased beyond 100% of whatever sub-100% state it's actually producing when no longer new. IOW, if the stylist makes it too high, usually the visitor can compensate. If the stylist makes it too low, usually the visitor cannot compensate. Too high is clearly the lesser evil.
Some text may actually seem to meet success criterion 1.4.3 Contrast (Minimum) of WCAG 2 http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-contrast but, after a closer look, I realized it can not be the case and that criterion 1.4.3 of WCAG 2 is probably inaccurate, unreliable, flawed. Several mozilla.org webpages use color: rgb(109, 117, 129) font-family: georgia,serif font-size: 13px and color: rgb(109, 117, 129) font-family: georgia,serif font-size: 14px for their text. Now, when I check the color constrast ratio (Luminosity Contrast Ratio), I get 4.65: 1 which, it seems, would meet criterion 1.4.3 of WCAG2... but, you see, the recommandation does not state how large the text is. There is a considerable readability and legibility difference between a font-size of 17px, 16px, 14px, 13px, 12px, 11px and smaller. So, criterion 1.4.3 is based on what font-size of text? The font size for "large text" is well defined in criterion 1.4.3: http://www.w3.org/TR/2008/REC-WCAG20-20081211/#larger-scaledef but not for "text". And this is not the only issue. Those same mozilla.org webpages which use color: rgb(109, 117, 129) font-family: georgia,serif font-size: 13px and color: rgb(109, 117, 129) font-family: georgia,serif font-size: 14px actually have ancestor-containers (eg div#outer-wrapper) which are using background-images that are not entirely white (eg http://www.mozilla.org/img/template/page-background.png therefore should not to be compared with #FFFFFF ) and can even use gradient, linear-gradient ... therefore making the contrast ratio inaccurate. 2 other aspects are also not covered by criterion 1.4.3. Typefaces do not have the same x-height; this can make a legibility difference. And not everyone may have a particular font installed on his/her system. What I mean here is that georgia is not universally installed by default.
If the contrast guideline of 4.5:1 in 1.4.3 of the WCAG guidelines is insufficient, what do you think is sufficient? We need a specific, hard rule that we can apply to every design and page. Ideally it should be as simple as possible. 4.5:1 is simple, and easily enforceable for future work. So far this bug hasn't provided any actionable requests. "The contrast is too low everywhere and WCAG guidelines aren't good enough" is not well-defined. Also I feel that it's necessary to point out that Bug 859556 will likely be fixed(hopefully soon), and if font sizes scale properly with user preferences, you should use your preferences to increase the size if you find the font sizes too small, regardless of contrast. I think that's a reasonable expectation.
(In reply to Andrei Hajdukewycz [:sancus] from comment #5) > if font sizes scale properly with user > preferences, you should use your preferences to increase the size if you > find the font sizes too small, regardless of contrast. I think that's a > reasonable expectation. Not only is reasonable, it's the most rational thing to do. The problem is the most logical way to set the preference is so that sizing is correct on pages that respect browser default size settings. See http://bugzilla.mozilla.org/show_bug.cgi?id=24846#c2 > If the contrast guideline of 4.5:1 in 1.4.3 of the WCAG guidelines is > insufficient, what do you think is sufficient? Looking at the guideline it is clear that less contrast is required if text is "large". It necessarily follows that smaller text should have more contrast than larger text. So, if 4.5 is adequate (IMO 4.5 is closer to half what it ought to be) for normal size text (aka medium, or 100% of default), then more than 4.5 must be required for sub-normal. Reduced to numbers, if for some definition of "large" 1/3 less (3/4.5) is OK going larger, then for some definition of "small" something like 50% more (4.5/3*4.5, or 6.75:1) could logically be required for text more than nominally smaller than medium. If the background contains a more than nominal pattern or gradient, then even more should be required. > We need a specific, hard rule > that we can apply to every design and page. Ideally it should be as simple > as possible. 4.5:1 is simple, and easily enforceable for future work. So far > this bug hasn't provided any actionable requests. "The contrast is too low > everywhere and WCAG guidelines aren't good enough" is not well-defined. The best and simplest rule would be maximize contrast as much as practical without limiting options to black text on white background or white text on black background. For most people using a display correctly adjusted to the viewing environment, black text is better than gray text for every light background hue. Given appropriate display adjustment, sub-maximum contrast can't possibly do more good than bad, for this reason alone if not others: Those who prefer lower contrast can adjust it down, all the way to 0 if it suits them; while short of replacing the whole display, those who need more cannot go past the 100% that likely they have already reached. To make it simple, for all light background hues, no foreground hue where all three rgb values are equal is permissible unless their values equal 0. If the background is white or nearly so, at least one of r, g or b must be zero. For light text on dark background theming or areas, vice versa. Something that would help would be a strong recommendation to end each work day by reviewing all the day's work by doubling the normal viewing distance to the work display, to exercise some empathy for the masses whose corrected visual acuity and/or display size are below 67th percentile.
> If the contrast guideline of 4.5:1 in 1.4.3 of the WCAG guidelines is > insufficient, The contrast guideline was worded at a time (dec. 2008) where properties and features like text-shadow, gradient, linear-gradient, radial-gradient, opacity, rgba, etc... were barely starting to be mentioned in www-style mailing list and elsewhere. By design, the contrast guideline of 4.5:1 in 1.4.3 is also approximate and rough. They explain how they got/reach such 4.5:1 ratio value. Understanding SC 1.4.3 http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html suggests to me that such guideline should *_not_* be considered always reliable, accurate, trustworthy. "Text that is larger and has wider character strokes is easier to read at lower contrast." http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html and this is perfectly understandable and expectable too. The beforementioned declarations 'color: #444; font: 90% Arial, sans-serif;' fit this bug report. We do not even know what's medium font-size according to 1.4.3 to begin with! It could 12px and it could be 16px; there is a significant margin, leeway, latitude here... > what do you think is sufficient? We need a specific, hard rule > that we can apply to every design and page. 4.5:1 ratio value might be sufficient in my opinion if font-size is 16px, if the x-height is equal or over 0.50, if letters are not condensed, not italicisized, no reduced letter-spacing, if there is no opacity, no rgba, no gradient and no text-shadow involved. I beleive such 4.5:1 ratio value was reached while assuming all the other properties were using normal or default values. > Ideally it should be as simple > as possible. 4.5:1 is simple, and easily enforceable for future work. Unfortunately, effective color contrast as calculated by Techniques For Accessibility Evaluation And Repair Tools http://www.w3.org/TR/AERT#color-contrast is *_not_* to be trusted if there is gradient, opacity, text-shadow, etc.. and other cosmetic, decorative, ornemental features. So, unfortunately, I do not have a specific, simple, easily-enforceable-for-future-work ratio value (which will work everywhere for every situations) to propose. > So far > this bug hasn't provided any actionable requests. "The contrast is too low > everywhere and WCAG guidelines aren't good enough" is not well-defined. I have found precise spots where I believe contrast may be too low. I may be able to find more precise spots where I believe contrast may be too low and report these in here. I tried to extend the documentation research and specification research, extend (or pinpoint) the actual results and extend (or pinpoint) the expected results in this bug report and in other bug reports. This is always important to do. After reading a few pages at Lighthouse International http://web.archive.org/web/20070711190923/http://www.lighthouse.org/accessibility/boomers/ http://web.archive.org/web/20070708133853/http://www.lighthouse.org/accessibility/legible/ http://web.archive.org/web/20070709140215/http://www.lighthouse.org/accessibility/effective-color-contrast/ it seems clear that the most important factor of readability/legibility is font-size.
(In reply to Felix Miata from comment #6) > > If the contrast guideline of 4.5:1 in 1.4.3 of the WCAG guidelines is > > insufficient, what do you think is sufficient? > > (...) less contrast is required if text > is "large". It necessarily follows that smaller text should have more > contrast than larger text. So, if 4.5 is adequate (...) for normal size text > (aka medium, or 100% of default), > then more than 4.5 must be required for sub-normal. I agree with this line of reasoning. > The best and simplest rule would be maximize contrast It's the safest policy too, accessibility-wise; it is what I proposed too in #c0 .
Priority: -- → P3
(In reply to Andrei Hajdukewycz [:sancus] from comment #5) > If the contrast guideline of 4.5:1 in 1.4.3 of the WCAG guidelines is > insufficient, what do you think is sufficient? We need a specific, hard rule > that we can apply to every design and page. Ideally it should be as simple > as possible. 4.5:1 is simple, and easily enforceable for future work. This request-comment deserves more answer. WCAG 2.0 documents have very few specific, hard, fully well-defined, simple, easily enforcable rules and trustworthy ones, reliable ones in all situations. This was and still is one of the major criticisms/problems with WCAG 2.0 documents. Very often, it sends the reader/web author to a long list of possible techniques and solutions and to his/her own judgment. WCAG Guidelines 2.0 is the only "normative" document of that spec. It used to have - when printed - 72 pages, 20,800 words and it's still today probably close to such numbers. Understanding WCAG 2.0 is a document that purports to explain WCAG 2. (165 pages, 51,000 words) Techniques for WCAG 2.0 provides "general" techniques. (221 pages, 88,000 words) In other words, WCAG 2.0 documents represents lots of reading and not necessarly clear, well-defined, hard, simple rules to comply with. That's what WCAG 2.0 is to many of us, including myself. To most people (including myself) who want to develop an accessible and WCAG-approved website, we want and prefer "dog-simple" guidelines (technically feasible and verifiable, even automatable if possible) to comply with. Eg. Do this and you've passed guideline X.Y . WCAG 1.0 was more like this and there were online accessibility WCAG 1.0 checkers available to report accessibility issues on automatable guidelines of A, AA, AAA levels and for section 508: Bobby by Centre for Applied Special Technology (CAST), WebXACT from Watchfire Corp., Cynthia says from HiSoftware comp., Accessibility Valet from WebThing, WAVE 3.0 (Web Accessibility Versatile Evaluator) from WebAIM and sponsored by Temple University Institute on Disabilities.
Component: General → Pages & Content
> 4.5:1 ratio value might be sufficient in my opinion if font-size is 16px, if > the x-height is equal or over 0.50, if letters are not condensed, not > italicisized, no reduced letter-spacing, if there is no opacity, no rgba, no > gradient and no text-shadow involved. Here's a live example of what I explained here and in bug 225639 comment 39: http://www.polyform.com/nouvelles-en-details/detail/2015-07-06/recyclage-du-polystyrene-expanse-un-nouveau-point-de-collecte-chez-polyform Even if I set, in that polyform.com webpage, body text color from #666666 to black (#000000), the text is difficult to read for me *_even though the set font-size for body text in that polyform.com webpage happens to match my preferred font-size of 16px_*. Because the font used is "Open Sans Condensed Light" [1] and 'text-align' is 'justify' which is known to be more difficult to read [2] because space between words are inconsistent and irregular in justified text. [1] @import url(http://fonts.googleapis.com/css?family=Open+Sans:700,400|Open+Sans+Condensed:300); http://fonts.googleapis.com/css?family=Open+Sans:700,400|Open+Sans+Condensed:300 @font-face { font-family: "Open Sans Condensed"; font-style: normal; font-weight: 300; src: local("Open Sans Cond Light"), local("OpenSans-CondensedLight"), url("http://fonts.gstatic.com/s/opensanscondensed/v10/gk5FxslNkTTHtojXrkp-xBEur64QvLD-0IbiAdTUNXE.woff2") format("woff2"), url("http://fonts.gstatic.com/s/opensanscondensed/v10/gk5FxslNkTTHtojXrkp-xF1YPouZEKgzpqZW9wN-3Ek.woff") format("woff"); } [2] http://webstyleguide.com/wsg3/8-typography/3-legibility.html
You need to log in before you can comment on or make changes to this bug.