1.4.11 Non-text contrast understanding doc references placeholder as a passing technique, despite it being a transient state

[smhigley]

I have a question on a sentence in the Boundaries section of the Non-text contrast understanding doc:

If text (or an icon) within a button or placeholder text inside a text input is visible and there is no visual indication of the hit area then the success criterion is passed.

The question I have with placeholder text specifically is that, as a function of how it works, it is always possible to remove placeholder text by typing something (e.g. a space character) into the input. My current understanding is that every editable control that relies on placeholder text to be visible can be put into a state where that placeholder text is no longer visible. Is there something that would cause this state to not fail the criterion?:

(e.g. in the above image, where both inputs have the same placeholder markup, and the second input contains a whitespace character)

This is a bit more than an edge case, since it's fairly easy to accidentally press space while on an input, particularly if the controls on the page are hard to perceive, and the user thinks they might be on a button and are trying to activate it. I've observed this exact thing happen more than once in user studies. I've also observed that placeholder text without a contrasting border places enough burden on low vision users that I'm not sure I'd consider it sufficient to identify the control even if it were always visible, but that might be a can of worms that doesn't need opening 😅.

Please let me know if there's something I'm missing here, and if there's something I haven't considered that would allow placeholders to persistently identify inputs.

[mbgower]

Personally, I think that a text input without a visual indicator of the input beyond the placeholder text is an amazingly crappy implementation. And it's not something I've seen in the wild. If there was any visual styling for the input (which there usually is), some part of it would need to meet 3:1 or I'd fail it.

I do not think the author of that example intended it to be an example of a good implementation, but rather a way of illustrating that if there is no visual indicator of a boundary, that doesn't constitute a failure of Non-text Contrast. Everyone is in the same crappy experience. It is not a problem unique (or even more pronounced) in regard to low vision -- which was the primary user intended to benefit from a contrast requirement.

There is this crumb tossed out to that effect:

Note that for people with cognitive disabilities it is recommended to delineate the boundary of controls to aid in the recognition of controls and therefore the completion of activities.

To address your issue, my inclination would be to remove the text input mention entirely. I think we can probably get traction on that.

This success criterion does not require that controls have a visual boundary indicating the hit area, but if the visual indicator of the control is the only way to identify the control, then that indicator must have sufficient contrast. If text (or an icon) within a button or placeholder text inside a text input is visible and there is no visual indication of the hit area then the success criterion is passed....

---

Now, regarding my "if there is any visual indicator, I'd fail it without 3:1 contrast", I'm very tempted to apply the same thing to the button presentation. So I'm also not sure I agree with the second part of the text. I would be inclined to wipe it out too. I think there will be more debate on that.

This success criterion does not require that controls have a visual boundary indicating the hit area, but if the visual indicator of the control is the only way to identify the control, then that indicator must have sufficient contrast. If text (or an icon) within a button or placeholder text inside a text input is visible and there is no visual indication of the hit area then the success criterion is passed. If a button with text also has a colored border, since the border does not provide the only indication there is no contrast requirement beyond the text contrast (1.4.3 Contrast (Minimum)). Note that for people with cognitive disabilities it is recommended to delineate the boundary of controls to aid in the recognition of controls and therefore the completion of activities.

Even on this page, there are some examples that I really wonder about, such as the Close with comment split button

To me, I think you need to see the little grey line between the text and the chevron to distinguish this from a dropdown menu. I think a strong case can be made that that small vertical line needs to be 3:1.

I would also be inclined to argue that if the designer feels like they needed to add the light grey stroke and fill to make it clear this is a button, those should be 3:1. Same thing goes with the edit button in the button pair at the top of the page

If someone felt it needed a bit of visual reinforcement, isn't it fair to say that's how they are distinguishing a secondary button, and it should be distinguishable to all and have 3:1?

The counter argument is that the position of the button's text (its relative isolation from body text; its pairing with a primary button, etc) serves as sufficient indicator that it is a button, and it doesn't need the outline. But given the wording of the SC is "Visual information required to identify user interface components", I'm not a big fan of including wording that excludes all existing outlines of all buttons from consideration.

[TestPartners]

I have seen plenty of text inputs without a visual indicator. By far the most common is where a Search button opens a dropdown or a full screen lightbox containing a Search form. Sometimes the focus is placed in the textbox, so you can see the flashing caret. Other times, it isn't and it's not at all obvious what you're supposed to do. I recall one case where the lightbox didn't even contain a text label - there was just a big white rectangle. This kind of UX idiocy may be more common than you would expect.

It's also possible that the textbox border has been removed unintentionally as a result of modifying some other component that shares some of the CSS rules. This sort of thing is not uncommon as websites are modified throughout their life.

[mbgower]

I have seen plenty of text inputs without a visual indicator.... This kind of UX idiocy may be more common than you would expect.

Thanks for the context, @TestPartners. I'm glad we've got this SC to help address such things.

[smhigley]

Just to clarify here, I was talking about text inputs that do have a visual border, but one that does not meet 3:1 contrast. When taken in context with the rest of the paragraph, the sentence from the understanding doc about placeholders strongly implies that an existing visual border on a text input does not need to meet 3:1 contrast if the input also has a placeholder.

That's the way I read it even though I didn't personally agree, and the way everyone I've talked to has also read and understood it. Based on your comments, was that not the original intent? The conversation about finding inputs with literally no border is confusing me a bit, since I have approximately 5.7 million examples of text inputs with non-contrasty borders and placeholders to reference if needed :D.

@mbgower just to clarify, is the proposed resolution to remove the bit about placeholders from the understanding doc? Is there any chance of clarifying explicitly that placeholders do not allow inputs to meet this criterion? (From my experience, having that clarification would help quite a bit in making the case that borders must meet 3:1 contrast, which designers tend to push back on quite a bit).

Thanks for looking at this!

[fstrr]

I've always read this as having a sufficiently-contrasting placeholder attribute in an input means that the border color can be less than 3:1. The placeholder obviously disappears when the input gets focus, but that's covered by this in the text input focus style entry (which I'm not a fan of):

the cursor/caret which is displayed when the input receives focus does provide a sufficiently strong visual indication.

And, yes, I've also seen massive amounts of text inputs with placeholders and non-contrasty borders. These are not rare things :)

[smhigley]

@fstrr I think the other issue is that typing a whitespace character and then blurring the input will also remove the placeholder, as well as not displaying a focus state or text insertion cursor. That's the failure state I initially wanted to raise in this issue as a blocker for using placeholders as a sufficient technique for 1.4.11 (and one I've seen borne out in user studies, as not just an academic / abstract failure)

[fstrr]

@smhigley ah, yes. The thing that you put in your original post that I apparently didn't read properly…

It's not just placeholders, I think, but it's maybe the state of an input being visually empty (so, actually empty or with just spaces in). That covers your input-with-a-placeholder-and-with-spaces-in example and also something like a text input with a value="foo" attribute that the user then deletes, leaving the input empty.

[mbgower]

@mbgower just to clarify, is the proposed resolution to remove the bit about placeholders from the understanding doc? Is there any chance of clarifying explicitly that placeholders do not allow inputs to meet this criterion?

Yes, to your first question, that's my suggestion, and a big "Well...," to the second :)

As has been done by @fstrr in his follow-up wording (e.g., "sufficiently-contrasting placeholder"), I think there needs to be a bit more context provided about the whole use of placeholders as a way to potentially meet non-text contrast.

I've been leery of tackling this because placeholder text contrast is itself such a big can of works. Until very recently, almost every implementation of placeholder text I've encountered is under 4.5:1, which according to the normative wording of 1.4.3 makes any use placeholder text fail WCAG. In the case where it does meet 4.5:1, how does a user distinguish the placeholder text from an actual value in the text input? It can be done, but there is zero guidance I've encountered that has shown an established way of doing that.

I know this is to a degree orthogonal to your issue, but it is obviously highly relevant. That's one of the reasons I thought I would strip out the placeholder reference for now, and make this an easier thing to address, pariculary given it seems very odd to talk about placeholder text in the Non-text Contrast requirement.

[smhigley]

@mbgower I do think the question of placeholder contrast is a really interesting one, but I do want to make sure this specific issue stays scoped to just the non-text contrast question. (I can be easily distracted, so I'm also resisting the urge to actually talk about placeholder contrast 😅)

The original issue with placeholders I wanted to raise is that by their very design, you can remove them by typing a whitespace character. So even if one were to find a perfect solution for contrasting placeholder text that differs from the value, this issue would still exist since the user could type a space character, blur the input, and then not have any perceivable UI to allow them to interact with the input again apart from the border contrast.

e.g. as in this image of two states of the exact same <input> element:

Considering that, would you / the low vision TF be interested in a more explicit placeholder clarification? If there's anything I can do to help I'd be happy to (including drafting wording to discuss, but I don't know if that's desired from non-members).

Thanks again for taking the time to look into this!

[mbgower]

I'm going to bring this forward to the Task Force for discussion.
Here is my summary of the issue to debrief those who do not want to read the whole thing. Please let me know if I've missed anything:

1. Clarify what the existing wording regarding placeholder text in the Non-Text Contrast Understanding document means.
2. See whether there is consensus on the TF to remove that reference as a poor example.
3. See if there is any agreement on the TF that text inputs that do have a visual border, but one that does not meet 3:1 contrast, fail Non-Text Contrast.
4. See if there is any agreement that said low-contrast text input can use placeholder text (with 4.5:1 text contrast) to be its visual cue to pass Non-Text Contrast.
5. See if there is any consensus on what the decision is when placeholder text below 4.5:1 contrast is used in this situation. (In other words, can text that is recognizable as a cue but not sufficient to meet 1.4.3 be considered sufficient for non-text contrast purposes?

[mbgower]

See also #4343

[GreggVan]

Thanks Mike for trying to summarize so people don't have to read everything! But it would be helpful (ot me at least) if you would quote things you are referring to.

for example

1. Clarify what the existing wording regarding placeholder text in the Non-Text Contrast Understanding document means.

• Could you quote what you are referring to?

2. See whether there is consensus on the TF to remove that reference as a poor example.

• could you quote what "that reference" is?

RE #3

3. See if there is any agreement on the TF that text inputs that do have a visual border, but one that does not meet 3:1 contrast, fail Non-Text Contrast.

• I for one would agree. That border is key to understanding that there is an input field (especially when empty) and most disappear when they are faint and thin. I'm not sure of the contrast value needed and I do think the width is a key factor - not just the contrast ratio -- and I have not seen any research on low vision and contrast (except for reading which is a totally different thing in that you are reading thin stemmed characters and need to do so at high speed. But I agree in principle with your point and position that it has to be sufficient or it should fail. Just not sure what sufficient is. AND WE NEED TO NAIL THIS DOWN FOR WCAG3 -- so thanks for raising this.

RE #4

4.See if there is any agreement that said low-contrast text input can use placeholder text (with 4.5:1 text contrast) to be its visual cue to pass Non-Text Contrast.

• Boy I wrestle with hint or placeholder text every time it comes up. if it is not substantially different than entered text you create a cognitive task that may be higher than the cognitive tasks/tests we forbid in authentication provision.

RE #5

5. See if there is any consensus on what the decision is when placeholder text below 4.5:1 contrast is used in this situation. (In other words, can text that is recognizable as a cue but not sufficient to meet 1.4.3 be considered sufficient for non-text contrast purposes?

• Again - I wrestle with this every time it comes up. If the text is important it needs to be visible. And if not important for people with low vision - then it should not be important for anyone and should be not there at all. HOWEVER -- this does not have to be read at high speed so contrast can be lower. And it has to be different than entered text or you create a cognitive task that is much higher than all our cognitive tasks/tests in authentication provision. SO I am torn. Also it is hard to say that text does not have to follow the text contrast unless we rewrite it overall. Again - thanks for bringing this up. We can't solve it in WCAG2 but we need to for WCAG3.
• some thoughts for WCAG3
  - should we have one contrast level for text that is in running blocks/paragraphs etc. where it has to be read at speed
  - and a lower level for menus buttons and other places where you do not need to read/recognize it at the same speed?
  - if so how much lower. a little or a lot
  - and hint text - is it ok to make it lighter too ? Is so - how much
  - should we have stem width be a factor in choosing contrast/ (we actually already do. when we say large print can have lower contrast - it is largely because it has thicker stems. If large print is just as thin as small print -- it can disappear with low vision quickly as well. and again -- how would we do this
  - for non-text contrast - we have been using numbers from text contrast - which again is for high speed reading. Do we have research for effect of low vision on things like buttons that are huge and broad? and clearly the contrast between a line on a chart (non-text) and a button and its background (also non-text) should be totally different. Is there a width factor we should be deploying here too? Really good questions for improving WCAG3 in this area.
• for WCAG2 I'm not sure what we can do

sorry for no good answers to your very good questions. Hope this is helpful

[smhigley]

@GreggVan the specific text in question is part of the understanding doc, but not the criterion itself. It's specifically this line:

If text (or an icon) within a button or placeholder text inside a text input is visible and there is no visual indication of the hit area then the success criterion is passed. (emphasis added)

I think in all the conversation, the original issue is maybe being lost. The principal issue with using placeholders or visible value text as an identifier is that users can remove both by typing a whitespace character into the input. When one does so, the input no longer has any visible text within it -- neither the placeholder nor the value can be seen. This is possible to do for literally any input that relies on a placeholder, which to me indicates that a placeholder is not sufficient identification, regardless of its contrast ratio.

This may seem like an edge case, but isn't in my observation -- the space key is a common activation key, and I've observed users in a low vision-focused user study accidentally type space characters into an input while trying trying to figure out the UI.

I've made a video narrating this, since I think some confusion keeps getting introduced 😅:

input-placeholder-whitespace.mov

(since I can't add captions, in the video I narrate myself focusing the input, typing a space character, and blurring it. After blurring, the less-than-3:1-contrast border is the only remaining identification)

[GreggVan]

@smhigley Ah - thank you for taking us back to the initial issue.

I agee. Placeholder text should not be the only way. Users might also tab in the hit backspace to clear it and then lose track of where it is.

hmmm -- but wouldn't the text input cursor then be still visible and usually blinking? I guess if it was just a vertical line - and didnt blink....

How many places have text input areas that are not outlined or obvious from the text. E.g. **NAME: ** ?

I havent run into this - but are you saying 'there isnt any indication? or that the indication is not visible enough?

thx