Understanding 1.4.11 - clarify what does _not_ need such contrast

[shawna-slh]

Updated to clarify that this is a request for information to be added to the Understanding Document. More background in full Twitter thread.

From https://twitter.com/pauljadam/status/1277979852205785088 :

I also see lots of false positives from testers for Non-text Contrast. ... I think the understanding document needs to define more of what does Not have contrast requirements, I see testers going over board on non-text contrast.

Examples I've been asked about:

[patrickhlauke]

at a high-level, when asked about this, i usually tell auditors/engineers "if the 'thing' was completely absent, would it still make sense / be understandable?"

of course that drips with subjectivity, but I usually prefer a more nuanced approach rather than a hard "all border of things must be contrasty enough" edict which in many cases leads to authors having to follow a criterion not because it makes sense, but just as a formalism/formality.

[StommePoes]

I asked about this on the web-a11y Slack, citing a Microsoft Github ticket where buttons (with adequate text-contrast, who were not inline with any paragraph text, had bolded weight compared to nearby paragraph text, and had imperatives as text) had less-than-3:1 contrasted background colour (light grey against white page), and every single accessibility expert on there agreed (with the ticket) that yes, this was a failure of 1.4.11, even though the Understanding page expressly says borders/backgrounds are not required to exist or meet contrast minimums, unless the "visual indicator of the control is the only way to identify the control."

So for this reason I agree with this request, UNLESS as some have said, we change the meaning of this SC to explicitly require sufficient contrast when used to denote (for example) hit areas, or to make them more usable via more recognisable to users with cognitive disabilities. I'd be okay with that too, but that seems less likely.

[pauljadam]

I get a lot of false positives from QA testers where they say the button border or the button background color fails to have more than 3:1 contrast ratio for non-text content but the only thing that needs good contrast in the button is the text against the button background not the button background against the page background. And not the button border against the page background. That's an example of them going overboard with the SC.

[fstrr]

Hi

I'm working on an update to the Understanding document to address @slhenry's feedback and the related #856 issue on cards. A quick question about this comment, which I can work into an example:

at a high-level, when asked about this, i usually tell auditors/engineers "if the 'thing' was completely absent, would it still make sense / be understandable?"

When you say "the 'thing'", what do you mean? To use the examples in this issue, would "the thing" be the borders and shadows around the custom tooltips, and the borders around the radio buttons and card?

Thanks

[patrickhlauke]

it's whatever non-text visual element you're having doubts about whether it needs to have sufficient contrast or not. do you think "hmm, the border around the tooltip, users may not understand it's an actual tooltip...and if they can't understand that, they won't be able to understand the meaning of this at all"? i personally would think no, they'd still understand the meaning of the content that's shown to them. it may look a bit odd/unstyled to them without the border, but they can still get the actual purpose/content here. even without a drop shadow. it will basically just be "some extra text appeared when i clicked the '?' button". they're not getting less content/information for lack of a border/style around it.

radio buttons with adjacent text...it's fairly clear to users that the adjacent text is most likely the label relating to the radio button. even without a border, they can understand what the control is/does.

border around a card...as discussed previously (e.g. https://github.com/w3c/wcag/issues/856) this is also not really absolutely necessary in this specific example - assuming there's nothing around the card/following the card which, if the border wasn't there, could be mistaken (incorrectly) to be still part of that card. basically, it depends (tm) on the specific situation. auditors need to use their judgement if, in the specific context, something is necessary or not. there's no absolute rules about "every border must have 3:1" or similar. it really comes down to a judgement call on the part of the auditor, i'd say.

[fstrr]

Thanks for the reply - that all makes sense, and I have the same thoughts as you about the example components.

[mihkeleidast]

they're not getting less content/information for lack of a border/style around it.

Let's take two examples:

1. A tooltip that closes when unhovered.
2. A popover that closes on outside click.

Given that this makes the boundary of the component sort of interactive, then they are getting less information. If you don't see the boundary you are more likely to accidentally unhover or click on the outside. For example, if you try selecting text in such components, you need to know the "safe area" around such text to know where it is okay to click to start selection.

To me it seems similar to an input boundary, where you need to see the boundary to know where you can click in order to enter information.