Update 1.4.11 Non-text Contrast with additional boundary examples

[Blackbaud-MattGregg]

This PR contains a couple of additional image examples of boundary cases that aren't clear from the new explanation text alone. It's intended to help clarify for testers the current understanding guidance is similar for controls (buttons, text inputs) that have text or icons within boundary. Those are currently described as sufficient for identifying the presense of a control.

It's meant to be a clarification for a couple of open issues:
#1091
#5304

Preview: https://deploy-preview-5362--wcag2.netlify.app/understanding/non-text-contrast
Diff: https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwcag2.netlify.app%2Funderstanding%2Fnon-text-contrast&doc2=https%3A%2F%2Fdeploy-preview-5362--wcag2.netlify.app%2Funderstanding%2Fnon-text-contrast

[netlify]

✅ Deploy Preview for wcag2 ready!

Name	Link
🔨 Latest commit	93595b4
🔍 Latest deploy log	https://app.netlify.com/projects/wcag2/deploys/6aa2fe3d45c9ef0008f59b7a
😎 Deploy Preview	https://deploy-preview-5362--wcag2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[detlevhfischer]

I hope I interpret the PR correctly without seeing the new images in context in a preview. While I can follow the logic of your addition, it seems counterintuitive to pass the example of the loupe inside an input with insufficiently contrasting border and to fail nearly the same thing where the adjacent button with the loupe is separated from the input by a low-contrast line.

I think the ambiguity hinges on the fact that the Understanding text (I believe) does not spell out that a text or icon label inside an insufficiently contrasting input is fine while the same thing immediately above or beside the input is not. This ambiguity is not helped by the text of

Figure 33. Fail: The text input lacks any form of label to hint at its presence. The border color (#AAA) has contrast lower than 3:1

...because the was this is formulated allows the interpretation that possibly, a label adjacent instead of inside the input might also conform.

If you would reduce the contrast of the input border in your examples to something ridiculous like 1,1:1 (we've all seen that kind of thing), the difference between your example with a vertical line visually separating input from button and the one where the loupe sits inside the input would for all practical purposes disappear. Why then call one a FAIL and the other a PASS?

I am not sure where exactly to draw the line here. I just note that realizing something like the button without border in figure 1 is a control is typically reinforced by the visual context and conventions; if the button text said "Send", it would likely sit underneath a contact form on a separate line, so both visual context and conventional position convey its nature. When looking at your search field example, the conventional arrangement of the loupe button is to the right and sometimes to the left of the text input, creating an expectation supporting perception and guiding interaction. The same is true for text fields with a label immediately above. When borders of inputs are low contrast, is there really a significant difference beween a label immediately above and a floating label within that would allow us to call the former a FAIL and the latter a PASS?

[Blackbaud-MattGregg]

@detlevhfischer
These were intended to help clarify or possibly spark more discussion on the boundary explanation as written. I agree the difference between the pass/fail examples with the loupe could seem at odds, but that is how at least I am interpreting the boundary explanation. Each control needs a visual indication that has sufficient contrast. Spelling out 'inside' boundary explicitly would be useful as well.
The examples I added are similar to the Example 1 in Technique G167
In Example 2 in G167, there is a case I just looked back to which seems to support even passing the text input + button with one loupe icon for the button and insufficient contrasting border I’d included in this PR. If what is shown in Example 2 is passing (i.e., 1 icon can be considered a visual label for both text input and button - ‘dual purpose’), then what I had added as failed example, could be a pass if that is correct, no?