Clarifying 1.4.11 Understanding: border contrast when labels within input fields

[Blackbaud-MattGregg]

I was hoping to clarify a variation of what is called out in the Understanding 1.4.11 guidance for an additional case where there are labels inside of text fields. (See example attached)

I'm referring to this section -

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)).

This case of label within a field isn't called out explicitly but seems to potentially be the same situation though it seems like this ends up passing as long as there is text. Placeholder text only is called out. Basically it seems like if there is text (which passes its contrast SC) within user interface component, then 1.4.11 is passed and the border doesn't need to meet the contrast ratio? Similarly, if an icon or some other identifying icon/graphic that can identify the control, the same is true?

[detlevhfischer]

@Blackbaud-MattGregg Yes, that is my reading of the Understanding text too. Text inside button, input etc would have to have a contrast of 4.5:1 or better. Where the text is provided via placeholder which disappears on focus, the blinking cursor would still ensure minimal conformance (clearly having contrasty borders would be a recommended best practice, though).

[mraccess77]

I'm not sure how this would be different from an input with the label on the outside - which fails when the indicator does not have sufficient contrast. Just because the label is inside doesn't visually change identification of the control if you were to remove the low contrast areas.

This is worth a discussion with a larger group.

[mraccess77]

Related to proposed response in Clarity on 1.4.11 as it applies to "Cards" #856 which indicate placeholder text in input is sufficient.

[patrickhlauke]

@mraccess77 I think the issue here is likely that if the spec/understanding says that it's allowed for button-like controls (i.e. the shape/perimeter/border of a button doesn't need to necessarily contrast against its background, as long as its text/icon label is contrasty enough), then it needs a solid rationale to explain why it's then NOT acceptable for input fields where the label is also contrasty enough.

i mean an argument could be made that for button type controls, usually the text label/icon is clearly more of an "action verb" type thing, so might be clearer to a user even if they can't see that it's in a button. but that argument gets a bit strenuous.

on the other hand, i can see how normatively requiring that buttons and all other controls like that need to have a strong contrast against their background is counterproductive/will just not be followed (and leaves a giant gap for borderless/transparent backgrounds...do they fail then or what?)

[patrickhlauke]

as with the cards issue #856 it comes down to how draconian the SC can realistically be ... requiring everything that has a "perimeter" as such to have at least 3:1 contrast ratio is just not going to fly / will lead to the majority of the web today to fail. there's certainly nuance, but it's difficult to normatively pin down when it is or isn't necessary

[mraccess77]

It seems odd that we'd fail an input with a label above it but pass an input with a label inside of it - if you can't see the border what's the difference? If it's not about the hit area then should the SC pass all inputs then? The logic used seems to be inconsistent.

[mraccess77]

@patrickhlauke ", but it's difficult to normatively pin down when it is or isn't necessary" and I think that means we will get different results from different testers.

[patrickhlauke]

It seems odd that we'd fail an input with a label above it but pass an input with a label inside of it - if you can't see the border what's the difference?

while not guaranteed, it's more likely that clicking/pressing on where you see the label text you're setting focus on the input at that point (of course, not always guaranteed, depending how it's implemented)

for a label outside of the text box, it depends if it's a "proper" <label> or if the "clicking on this sets focus to the actual input" logic has been otherwise implemented in JS or similar.

it's not a particularly strong argument of course. but i think it's conceptually consistent with the idea that for buttons without a contrasty perimeter/background, the user can at least click on the bit they can see that has sufficient contrast, and be guaranteed that this will execute/work.

[patrickhlauke]

I think that means we will get different results from different testers.

the joys of WCAG, part 2042

[bruce-usab]

requiring everything that has a "perimeter" as such to have at least 3:1 contrast ratio is just not going to fly / will lead to the majority of the web today to fail.

3:1 allows a number of distinct hues against white, with a few (e.g. blue and green) which can also be 3:1 against each other.

Magenta is 3:1 against white, and is not popular with designers, so that seems like a hue with as an option for temporary border contrast.

[patrickhlauke]

everything is an option, but that doesn't detract from the fact that requiring this normatively for every button, input field, etc will likely be veto'd as it will result in the majority of the web today failing WCAG AA