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.