User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 Build Identifier: Mozilla/5.0 (Windows NT 6.0; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 the default color for text in the HTML5 placeholder attribute is 'graytext' this has a hex value of #808080 which has a contrast ratio of 3.9:1 with the default background color. The minimum required is 4.5:1 Suggest making the default color #777777 which is the nearest gray color that passes the color contrast ratio test. results when tested against WCAG 2.0 1.4.3 Contrast (Minimum) below: Foreground:#808080 Background:#FFFFFF The contrast ratio is: 3.9:1 Text failed at Level AA Text failed at Level AAA Large text passed at Level AA Large text failed at Level AAA SC 1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA) Large Print: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1; SC 1.4.6 Contrast (Enhanced): The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following: (Level AAA) Large Print: Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1 Reproducible: Always Steps to Reproduce: 1.open a page http://www.html5tothepoint.com/placeholder.htm which has an input using the placeholder attribute 2. check the placeholder text color using a contrast ratio tool (http://www.paciellogroup.com/resources/contrast-analyser.html) 3. fails contrast ratio test

AFAICT, this is an operating system level theme accessibility bug and Firefox gets the color from the operating system.

(In reply to comment #1) > AFAICT, this is an operating system level theme accessibility bug and Firefox > gets the color from the operating system. the color is set in resource://gre-resources/forms.css input:-moz-placeholder, textarea:-moz-placeholder { color: GrayText; } you pointed out in your tweet (http://twitter.com/hsivonen/status/13206690606354432) that "graytext is a CSS thing that maps to the disabled text color as defined by the operating system." placeholder text is not disabled text and should be readable by default. Is it not possible to override this assignation of the text color in the default style sheet?

(In reply to comment #0) > User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:2.0b7) Gecko/20100101 > Firefox/4.0b7 > Build Identifier: Mozilla/5.0 (Windows NT 6.0; rv:2.0b7) Gecko/20100101 > Firefox/4.0b7 > > the default color for text in the HTML5 placeholder attribute is 'graytext' > this has a hex value of #808080 which has a contrast ratio of 3.9:1 with the > default background color. The minimum required is 4.5:1 Suggest making the > default color #777777 which is the nearest gray color that passes the color > contrast ratio test. > > results when tested against WCAG 2.0 1.4.3 Contrast (Minimum) below: > > Foreground:#808080 Background:#FFFFFF > > The contrast ratio is: 3.9:1 > > Text failed at Level AA > > Text failed at Level AAA > > Large text passed at Level AA > > Large text failed at Level AAA > > SC 1.4.3 Contrast (Minimum): The visual presentation of text and images of text > has a contrast ratio of at least 4.5:1, except for the following: (Level AA) > Large Print: Large-scale text and images of large-scale text have a contrast > ratio of at least 3:1; > > SC 1.4.6 Contrast (Enhanced): The visual presentation of text and images of > text has a contrast ratio of at least 7:1, except for the following: (Level > AAA) Large Print: Large-scale text and images of large-scale text have a > contrast ratio of at least 4.5:1 > > > > Reproducible: Always > > Steps to Reproduce: > 1.open a page http://www.html5tothepoint.com/placeholder.htm which has an input > using the placeholder attribute > 2. check the placeholder text color using a contrast ratio tool > (http://www.paciellogroup.com/resources/contrast-analyser.html) > 3. fails contrast ratio test CORRECTION: the nearest gray color that passes the color contrast ratio test is #776777 NOT #777777

The assumption that disabled text shouldn't be readable by default is bogus. You're also wrongly assuming that "graytext" may only used for strictly disabled widgets. Placeholder text is a perfectly valid instance of "grayed text". The exact color value depends on the operating system, as pointed out earlier, and OS themes are to varying degrees accessible. On Windows, Classic tends to be more accessible than the modern Aero theme. There are explicit "high contrast" variants too. Try changing the theme and you'll see that you're complaint about graytext translating to a certain inaccessible color value is untenable.

Dão, I think we should strive to comply with at least the contrast minimums for our defaults.

What do you mean by "our defaults"? We don't specify the color values, as stated earlier.

But if the OS has flawed defaults, why not go "above and beyond"?

Because the "right" color is subjective and needs to fit the also-OS-dependent background color. If we start hard-coding the text color here, users of explicitly accessible themes lose.

(In reply to comment #4) > The assumption that disabled text shouldn't be readable by default is bogus. > You're also wrongly assuming that "graytext" may only used for strictly > disabled widgets. Placeholder text is a perfectly valid instance of "grayed > text". The exact color value depends on the operating system, as pointed out > earlier, and OS themes are to varying degrees accessible. On Windows, Classic > tends to be more accessible than the modern Aero theme. There are explicit > "high contrast" variants too. Try changing the theme and you'll see that you're > complaint about graytext translating to a certain inaccessible color value is > untenable. looking at the different windows OS themes for Graytext (http://brethorsting.com/blog/2007/12/windows_system_colors-2/) only 1 provides sufficient contrast with #fff. how was the decision made that placeholder text maps to 'GrayText'? why not map it to 'CaptionText' which does provide default readable contrast ratios for the majority of the OS themes listed. reguest the bug be re-opened

Native background and foreground colors need to be combined with caution. CaptionText is supposed to be used on ActiveCaption, on any other background it may not be readable.

(In reply to comment #6) > What do you mean by "our defaults"? We don't specify the color values, as > stated earlier. By default I simply meant what is presented when there is no author override. I guess "the defaults" would have been more appropriate. (In reply to comment #8) > If we start hard-coding the text color here, users of > explicitly accessible themes lose. I agree we don't want hard coded values.

'graytext'is quantifiably not readable by default on the windows OS themes, so if caution is the issue then it should not be used.

"quantifiably not readable" doesn't make much sense. Different users have different needs. Luckily, various OS themes exist to cater for different needs.

here is the rational for the contrast ration algroithm: http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html currently the default color assignation 'GrayText' used for placeholder on the majosity of OS themes falls below the required minimum contrast ratio "to provide enough contrast between text and its background so that it can be read by people with moderately low vision (who do not use contrast-enhancing assistive technology)" This is a built in accessibility failure that requires authors to chnage the colors in order to conform with recognised accessibility standards (WCAG 2.0)

The obvious solution is to pick a theme that doesn't violate recognized accessibility standards if you suffer from moderately low vision. I believe Windows ships with such themes.

no, the obvious solution is to provide a default text color for placeholders that conforms to accessibility requirements so both users and authros do not have work to provide an accessible interaface. BTW why does the placeholder text color require to be set using system colors when the input text suses "color: -moz-fieldtext;"?

(In reply to comment #16) > no, the obvious solution is to provide a default text color for placeholders > that conforms to accessibility requirements so both users and authros do not > have work to provide an accessible interaface. We don't provide colors here. The OS does.

(In reply to comment #17) > (In reply to comment #16) > > no, the obvious solution is to provide a default text color for placeholders > > that conforms to accessibility requirements so both users and authros do not > > have work to provide an accessible interaface. > > We don't provide colors here. The OS does. OK let me rephrase, the obvious solution is to a system color name for placeholders that conforms to accessibility requirements so both users and authros do not have work to provide an accessible interaface. Do you know the answer to this: why does the placeholder text color require to be set using system colors when the input text uses "color: -moz-fieldtext;"?

(In reply to comment #18) > OK let me rephrase, > > the obvious solution is to a system color name for placeholders > that conforms to accessibility requirements so both users and authros do not > have work to provide an accessible interaface. GrayText doesn't imply a concrete value, hence the question of conformity doesn't even arise. There's nothing inherently non-conforming in GrayText. A concrete implementation of a system color can violate a11y requirements, which brings us back to comment 17 and ultimately comment 15. > Do you know the answer to this: > > why does the placeholder text color require to be set using system colors when > the input text uses "color: -moz-fieldtext;"? I'm not sure what you're asking. -moz-fieldtext translates to a system color too.

so suggest using moz-fieldtext for placeholder text as well as it defaults in OS's to a readable text color.

This would make placeholder text look like typed text, which isn't desirable.

>This would make placeholder text look like typed text, which isn't desirable. isn't desirable for who? it would certainly be desirable for users who find it difficult to read. If it isn't desirable to authors they can modify it using CSS.

(In reply to comment #4) > You're also wrongly assuming that "graytext" may only used for strictly > disabled widgets. "GrayText Grayed (disabled) text." https://developer.mozilla.org/en/CSS/color_value

(In reply to comment #22) > >This would make placeholder text look like typed text, which isn't desirable. > > isn't desirable for who? For users looking at placeholder text, wondering when they typed that or whether it will be submitted if they don't replace it. (In reply to comment #23) > > You're also wrongly assuming that "graytext" may only used for strictly > > disabled widgets. > > "GrayText > Grayed (disabled) text." > > https://developer.mozilla.org/en/CSS/color_value "Disabled text" is not identical to "disabled widget" (although the latter usually implies the former). In the former sense, placeholder text actually is disabled, as it doesn't represent the field's actual value.

>For users looking at placeholder text, wondering when they typed that or >whether it will be submitted if they don't replace it. I think you are just grasping at straws to defend a position that is untenable. If this is a genuine concern then why allow authors to change the default color of the placeholder text using CSS. No other text on any control in HTML is displayed using a poor contrast color by default, in any browser, why introduce this for a new HTML5 feature. HTML5 is supposed to be all about built-in accessibility not built-in accessibility failure. Leaving this as is creates an issue that will have to be fixed by any author that desires or is required to have web content that conforms to accessibility standards. reguest the bug be re-opened. with all due respect Dao, I don't think this decision should be left up to you alone.

I agree that hardcoding a color value into the browser's default style sheet is not a solution; user customisation needs to be maintained. However, adjusting the color keyword used can make Firefox's default configuration more accessible while still supporting user customisation and helping web developers to fulfil WCAG. While the system-specified default colours provide poor contrast, there's an opportunity here to improve accessibility with no drawbacks as far as I can identify. Default browser accessibility is equally important as user customisation, especially so for older users who don't necessarily understand or use system or browser configuration, yet are a user group who are particularly affected by poor colour contrast.

I wrote; "why not map it to 'CaptionText' which does provide default readable contrast ratios for the majority of the OS themes listed." this is incorrect, CaptionText is in fact almost always white, which would not help at all.

Steve, would using opacity be better? (bug 556145)

(In reply to comment #28) > Steve, would using opacity be better? (bug 556145) Hi Mounir, I have carried out some tests using color:FieldText opacity:0.54; the results: http://www.html5accessibility.com/tests/placeholder-color.html The upshot is that if the placeholder style is set to color:FieldText opacity:0.54; the resulting contrast ratio would be conforming in all the default schemes provided in windows vista and in each scheme their is a reasonable differentiation between default field text and placeholder text thanks very much for the suggestion!

From the section 508 checklist: (g) Applications shall not override user selected contrast and color selections and other individual display attributes. g.1 Does the software not override the users color and contrast settings? g.2 Can users change colors on the screen to high contrast or any other color combination desired? Reducing the opacity would make us fail this test.

(In reply to comment #30) > From the section 508 checklist: > > (g) Applications shall not override user selected contrast and color selections > and other individual display attributes. > g.1 Does the software not override the users color and contrast settings? > g.2 Can users change colors on the screen to high contrast or any other color > combination desired? > > Reducing the opacity would make us fail this test. I find it surprising that you are trying to use accessibility standards to defend the default presentation of inaccessible text. a. no it does not and b. section 508 is in the process of a refresh which harmonizes with WCAG 2.0 so the requirement for a minimum default contrast will need to be met in the near future, so deal with it now. Furthermore in the new section 508 the browser is considered as a platform so having the browser setting the opacity is perfectly OK as long as it has the required effect of providing legible text.

(In reply to comment #31) > I find it surprising that you are trying to use accessibility standards to > defend the default presentation of inaccessible text. I don't defend "the default presentation of inaccessible text". What I do defend is our delegation of the presentation to the OS. > a. no it does not and b. section 508 is in the process of a refresh which > harmonizes with WCAG 2.0 so the requirement for a minimum default contrast will > need to be met in the near future, so deal with it now. We deal with it by respecting the OS settings. If the Windows default settings have issues, you need to report this to Microsoft. > Furthermore in the new > section 508 the browser is considered as a platform so having the browser > setting the opacity is perfectly OK as long as it has the required effect of > providing legible text. The browser being a platform is irrelevant. The user settings still exist on the OS level, we're not going to duplicate this.

(In reply to comment #32) > (In reply to comment #31) > > I find it surprising that you are trying to use accessibility standards to > > defend the default presentation of inaccessible text. > > I don't defend "the default presentation of inaccessible text". What I do > defend is our delegation of the presentation to the OS. > > > a. no it does not and b. section 508 is in the process of a refresh which > > harmonizes with WCAG 2.0 so the requirement for a minimum default contrast will > > need to be met in the near future, so deal with it now. > > We deal with it by respecting the OS settings. If the Windows default settings > have issues, you need to report this to Microsoft. > > > Furthermore in the new > > section 508 the browser is considered as a platform so having the browser > > setting the opacity is perfectly OK as long as it has the required effect of > > providing legible text. > > The browser being a platform is irrelevant. The user settings still exist on > the OS level, we're not going to duplicate this. You cannot blame the OS for this, there is no rule that says "GrayText" must be used for placeholders is there? You have made a choice "GrayText" to use a system color for text that is meant to be readable, it has poor contrast by default on any of the standard color schemes, it is more than ridiculous to require users to use a high contrast scheme simply so they can read the default placeholder text. So you can choose to defend this position or you can choose to use a default system color "FieldText" that provides legible text. Or find another way to fix thie issue, I haven't as yet seen a single suggestion from you about possible ways to fix this, the only response has been in the negative, that is unfortunate.

(In reply to comment #33) > You cannot blame the OS for this, there is no rule that says "GrayText" must be > used for placeholders is there? The rule would be that text should be legible. There's no exception for GrayText that I know of. So this would still be a bug on Microsoft's side. > I haven't as yet seen a single suggestion from you about possible ways to fix > this, the only response has been in the negative, that is unfortunate. Right, I'm saying we already do the right thing, so I can't really suggest a change on our side.

(In reply to comment #34) > (In reply to comment #33) > > You cannot blame the OS for this, there is no rule that says "GrayText" must be > > used for placeholders is there? > > The rule would be that text should be legible. There's no exception for > GrayText that I know of. So this would still be a bug on Microsoft's side. > > > I haven't as yet seen a single suggestion from you about possible ways to fix > > this, the only response has been in the negative, that is unfortunate. > > Right, I'm saying we already do the right thing, so I can't really suggest a > change on our side. well you are wrong on that count, the rule is that text shoudl be legible unless: "Text or images of text that are part of an inactive user interface component" http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-contrast that is what 'GrayText' is generally used for as it is generally described even in mozilla documentation: "GrayText Grayed (disabled) text." https://developer.mozilla.org/en/CSS/color_value This is sqaurely a browser bug and squarely a decision (by you alone), it seems to build in inaccessibility.

(In reply to comment #35) > well you are wrong on that count, the rule is that text shoudl be legible > unless: > "Text or images of text that are part of an inactive user interface component" > http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-contrast Well then we don't have a problem, as the placeholder is inactive (in other words "disabled", e.g. it won't be submitted; I already mentioned earlier that "disabled" in "Grayed (disabled) text" is not to be read strictly in the HTML 'disabled' attribute sense). However, the rule you're citing is challenged by high-contrast themes, which provide a high contrast for text no matter what.

(In reply to comment #36) > (In reply to comment #35) > > well you are wrong on that count, the rule is that text shoudl be legible > > unless: > > "Text or images of text that are part of an inactive user interface component" > > http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-contrast > > Well then we don't have a problem, as the placeholder is inactive (in other > words "disabled", e.g. it won't be submitted; I already mentioned earlier that > "disabled" in "Grayed (disabled) text" is not to be read strictly in the HTML > 'disabled' attribute sense). > > However, the rule you're citing is challenged by high-contrast themes, which > provide a high contrast for text no matter what. The text is required to be readable: "The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry." http://dev.w3.org/html5/spec/common-input-element-attributes.html#the-placeholder-attribute Disabled fields are not, thus the exception. The rule is not "challenged" it does not say that the text must not be legible it says that it does not have, to meet the requirements. > However, the rule you're citing is challenged by high-contrast themes, which > provide a high contrast for text no matter what. incorrect check a disabled input of any type for example(input type="text disabled, using windows high contrast white:text color: #00FF00 background:#ffffff contrast ratio: 1.4:1 ), it doesn't always provide legible text and does not have to as its disabled.

It depends on whether the placeholder is an example or an explanation. For an example it makes sense to be "disabled", for an explanation less so. But the HTML5 spec also says that a placeholder "should not be used as an alternative to a label", which I think indicates that even if it's an explanation, it shouldn't be required for understanding the input field. Btw, if you insist that placeholder text must not be regarded disabled, the suggested reduced opacity still wouldn't cut it, as the cited WCAG 2.0 defines a stricter minimum contrast ratio for enhanced contrast: http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast7

(In reply to comment #38) > It depends on whether the placeholder is an example or an explanation. For an > example it makes sense to be "disabled", for an explanation less so. But the > HTML5 spec also says that a placeholder "should not be used as an alternative > to a label", which I think indicates that even if it's an explanation, it > shouldn't be required for understanding the input field. > > Btw, if you insist that placeholder text must not be regarded disabled, the > suggested reduced opacity still wouldn't cut it, as the cited WCAG 2.0 defines > a stricter minimum contrast ratio for enhanced contrast: > http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast7 hair splitting does not make the issue go away. It is not disabled full stop. providing a hint is not a substitute for a label. As regards the enhanced contrast (AAA) level the WCAG 2.0 guidleines state: "Note 2: It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content." http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html But enhanced contrast CAN be achieved by the author overriding default styles.

(In reply to comment #39) > hair splitting does not make the issue go away. It is not disabled full stop. > providing a hint is not a substitute for a label. Call it hair splitting or not, but the intended primary use case for placeholder text is dummy text. We need to communicate that this is not the actual value (but a disabled one, say). > As regards the enhanced contrast (AAA) level > the WCAG 2.0 guidleines state: > "Note 2: It is not recommended that Level AAA conformance be required as a > general policy for entire sites because it is not possible to satisfy all Level > AAA Success Criteria for some content." > http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html > > But enhanced contrast CAN be achieved by the author overriding default styles. Err, /individual sites/ should be able to /opt out/ of AAA conformance (and we allow the user to deal with that by disabling custom content colors). We want the default to be highly accessible.

(In reply to comment #38) > It depends on whether the placeholder is an example or an explanation. For an > example it makes sense to be "disabled", for an explanation less so. But the > HTML5 spec also says that a placeholder "should not be used as an alternative > to a label", which I think indicates that even if it's an explanation, it > shouldn't be required for understanding the input field. > > Btw, if you insist that placeholder text must not be regarded disabled, the > suggested reduced opacity still wouldn't cut it, as the cited WCAG 2.0 defines > a stricter minimum contrast ratio for enhanced contrast: > http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast7 Sorry to jump in on this, but placeholder is part of the explanation for the field. If it didn't add to the understanding of what's expected of the field, why even add it? It's not a replacement for label, but that only means that semantically it is not equivalent to label; it doesn't mean that it isn't an important element of ensuring a person understands exactly what's required in the field. However, I also understand what I think was the reasoning behind using disabled text styling: if the value is treated as disabled text, with the same physical characteristics a person associates with disabled text, there is no confusion to the user about whether the value is submitted when the form is submitted. Am I correct in assuming this is why this particular value was chosen?

(In reply to comment #41) > Sorry to jump in on this, but placeholder is part of the explanation for the > field. If it didn't add to the understanding of what's expected of the field, > why even add it? Good question, I don't think the whole placeholder concept is hugely consistent... It's in the odd position of sometimes adding to the understanding, but usually not a lot; quite often it's going to be redundant. > However, I also understand what I think was the reasoning behind using disabled > text styling: if the value is treated as disabled text, with the same physical > characteristics a person associates with disabled text, there is no confusion > to the user about whether the value is submitted when the form is submitted. Am > I correct in assuming this is why this particular value was chosen? Yes, although submission is just one aspect. The user should generally see at a glance that a field with placeholder text is in fact empty.

(In reply to comment #42) > (In reply to comment #41) > > Sorry to jump in on this, but placeholder is part of the explanation for the > > field. If it didn't add to the understanding of what's expected of the field, > > why even add it? > > Good question, I don't think the whole placeholder concept is hugely > consistent... It's in the odd position of sometimes adding to the > understanding, but usually not a lot; quite often it's going to be redundant. > Yes, that's true. Or it should be somewhat redundant, as the label should provide the critical information. > > However, I also understand what I think was the reasoning behind using disabled > > text styling: if the value is treated as disabled text, with the same physical > > characteristics a person associates with disabled text, there is no confusion > > to the user about whether the value is submitted when the form is submitted. Am > > I correct in assuming this is why this particular value was chosen? > > Yes, although submission is just one aspect. The user should generally see at a > glance that a field with placeholder text is in fact empty. This is definitely a conundrum. I can see your point but I can see Steve's point, too. Your point is good in that we want to ensure people know that this isn't "important" text, or a value that is going to be submitted with the form. We can assume people know what placeholder text is, but we can't depend on this knowledge...especially if the text color is quite strong. On the other hand, Steve wants to ensure that everyone has the same access to the text, including those who may be looking at the page in bright daylight, or have other challenges seeing faint text. And one person's redundancy may be another person's clarification: the placeholder may provide just enough of a hint in order to ensure a proper value. If Steve recommends that web authors and designers alter the contrast of the text, then what we'll have is some web page forms with the placeholder text as a faint gray, others with a darker gray, and this could end up creating even more confusion, because we won't have a consistent presentation. I haven't developed in Windows directly in years, but caption text is usually a very dark color, and wouldn't be appropriate. Isn't there any other text color that is typically darker, such as an info text? If not, if the only options we have is the very light disabled gray, and the much darker active text, perhaps the best thing to do is hard code the value regardless of the theme. In fact, from what Steve told me in an exchange on Twitter, it sounds like this is what Chrome/Webkit does. It isn't ideal, but I'm not sure there's any other compromise.

Isn't there an inactive caption text color? It's darker than disabled text, but lighter than active text or caption text. Would something like this be a good compromise?

This really boils down to a simple question - is Mozilla comfortable allowing a default HTML5 element to automatically render content inaccessible and non-conformant with WCAG 2.0? If so, then we'll begin educating the masses of your choice and the complexity required for authors to override this inaccessible behavior so they can meet minimal conformance requirements. We'll also inform them of your decision to render Firefox itself in violation of Section 508 and the W3C's Authoring Tools Accessibility Guidelines. You referenced an existing Section 508 guideline. How about the software requirement in Section 508 §1194.21 (l) that requires that software render forms accessible, "including all directions and cues." What is placeholder text if not a "cue"? This is not to mention likely violations in (d) and (f), nor the several violations of the recommended software requirements in the draft updates to 508. UAAG requires that user agents render content according to acceptable norms, including WCAG. Your suggestion that placeholder text is "disabled" or kinda, sorta allowable to be treated as disabled text is tenuous at best. This certainly does not reflect WCAG's definition of "inactive user interface component", nor is it suggested in any software specification I've seen. It also seems a vast stretch from HTML5's description of placeholder text. I've yet to see a definitive reason why this MUST map to GrayText. If there is an allowance here (which I'm sure there is), several very reasonable alternatives have been provided that maintain system settings, meet the requirements of HTML5, UAAG, and WCAG, and most importantly, provide a minimally accessible user experience.

(In reply to comment #44) > Isn't there an inactive caption text color? It's darker than disabled text, but > lighter than active text or caption text. > > Would something like this be a good compromise? No, inactivecaptiontext is to be used on the inactivecaption background. (In reply to comment #45) > If so, then we'll begin educating the masses of your choice and the complexity > required for authors to override this inaccessible behavior so they can meet > minimal conformance requirements. We'll also inform them of your decision to > render Firefox itself in violation of Section 508 and the W3C's Authoring Tools > Accessibility Guidelines. If you want to participate in bugzilla, you'll need to refrain from making these kind of threats. No decision "to render Firefox itself in violation of sec 508 etc." has been made. > I've yet to see a definitive reason why this MUST map to GrayText. If there is > an allowance here (which I'm sure there is), several very reasonable > alternatives have been provided that maintain system settings, meet the > requirements of HTML5, UAAG, and WCAG, and most importantly, provide a > minimally accessible user experience. No very reasonable alternative has been provided so far. Hard-coding the color is going to hurt various OS themes (it's a strict sec 508 violation). Using the normal text color with a reduced opacity hurts high-contrast settings unless you go for a very high opacity, at which point you'll compromise the user experience for all users, as placeholder text will mostly look like a normal value.

> Using the normal text color with a reduced opacity hurts high-contrast settings >unless you go for a very high opacity demonstrably untrue, using GrayText provides worse contrast in a variety of high contrast modes.

Please don't twist my words. That there are a high-contrast theme with lacking contrast for graytext doesn't change the fact that there are high-contrast themes with proper contrast for graytext. It also does not mean that a 54% opacity magically becomes a good solution for high-contrast themes where graytext also lacks contrast.

Ccing Alex Faaborg for Ux input here. Maybe we could come up with some other affordance to indicate the placeholder text is not actual input... like italicizing?

FWIW, the opacity would make placeholder working very nicely when input/textarea have custom foreground and background colors. However, it might be confusing for authors to change it (they will try to override the color property and might not understand why it doesn't work).

(In reply to comment #50) > FWIW, the opacity would make placeholder working very nicely when > input/textarea have custom foreground and background colors. However, it might > be confusing for authors to change it (they will try to override the color > property and might not understand why it doesn't work). Yeah, there are pros and cons either way. I don't think that's a deciding factor at this point. I agree that italics might be a decent solution, maybe combined with a 70% or so opacity.

In order for this issue to be fixed it would require all browser vendors to fix the issue and that it seems is very unlikely. It may be easier to fix in other browsers such as webkit due to the color being hardcoded, hardcoding is not such an issue for them as they do not support windows high contrast mode (but currently the latest beta of firefox doesn't either, which is a major issue, hopefully fixed soon https://bugzilla.mozilla.org/show_bug.cgi?id=618613) use of italics maybe an alternative, but to prove effective it would have to be standardized across browsers. Give that there is not a practical system color available that provides a differentiation between field text and placeholder text and that opacity does not appear to be considered practical, it would seem that the use of 'GrayText'stays. This does result in an inbuilt accesibility issue which accessibility practioners will need to educate authors about and provide advice on how to fix, unfortunate but not a new situation. It is unfortunate that browser default styles (othe than sytem colors) cannot be set that can be overriden by specific themes.

Since it is obvious we have a bug here we need to deal with, I'm reopening the bug.

Is there some kind of citation trail explaining how the contrast ratio of 4.5:1 was deemed to be the ratio deemed accessible?

see Rationale for the Ratios Chosen http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#visual-audio-contrast-contrast-intent-head

>Ccing Alex Faaborg for Ux input here. Redirecting UX over to Limi since he is on HTML5 controls

Don't think that it has been mentioned that GrayText is being deprecated: http://www.w3.org/TR/css3-color/#css-system So it does seem like a good time to come up with a new, accessible, solution for placeholder text.

(In reply to comment #57) > Don't think that it has been mentioned that GrayText is being deprecated: > http://www.w3.org/TR/css3-color/#css-system This is irrelevant for this bug. System colors are being deprecated for authors, the UA stylesheet still needs them.

Windows User Experience Interaction Guidelines state that placeholders (there called "prompts") should be drawn "in italic gray and the actual input text in normal black. The prompt text must not be confused with real text." http://msdn.microsoft.com/en-us/library/aa511494.aspx#prompts It does seem like there's a bug here in the default Windows theme (I'm not sure there's sufficient contrast in the screenshot in the Guidelines). It will be interesting to see what MSIE does with placeholder text.

(In reply to comment #59) > Windows User Experience Interaction Guidelines state that placeholders (there > called "prompts") should be drawn "in italic gray and the actual input text in > normal black. The prompt text must not be confused with real text." > > http://msdn.microsoft.com/en-us/library/aa511494.aspx#prompts These aren't exactly the same. "Prompts" do in fact replace labels, as the doc states. Placeholder text "should not be used as an alternative to a label", according to the HTML5 spec. That's not to say that "prompts" and "placeholders" should be styled differently...

Would it be possible to find a solution soon to not have Firefox 4 shipping with this a11y issue or that's a very low priority?

I would have been glad to attach a patch but I don't see how to change the opacity of the text with our :-moz-placeholder pseudo-element. The only idea I have would be with ::value (CSS3 UI) implemented...

It doesn't look like ux ever commented. I quickly read over all of the previous comments, and I think this is an accurate summary: the objective of the OS theme designers: create an interface where users don't confuse active and inactive text (self describing fields don't look filled out, etc.) the objective of the accessibility team: Firefox provides users with adequate contrast if they are having trouble seeing graytext So the question is, should we override the OS setting of graytext because we believe they made a mistake with the specific values they selected. (and on a more hypothetical level, does there exist a perfect shade of gray that is higher contrast, but also very clearly inactive?) I recommend that we continue to use the OS defined values for the default case, and add a control to the fonts window that allows users to override this value (just as we allow them to override values for normal text and background page color). The usability impact of users being losing the ability to detect the difference between active and inactive text is a larger concern for the default case. However, there are definitely some users who are going to want to change this value, and these users also don't necessarily need a full high contrast OS theme. They will likely really appreciate having this extra level of control over Firefox.

The color can be changed by setting the ui.graytext pref.

Right, so we just need to expose a graphical way for people to do that in options > content > colors

Unfortunately, I don't see how we could fix that for Firefox 4... :(

I think Alex's summary is comment 63 is reasonable. Can we get an owner for implementing comment 65?