SC 1.4.11 and highlighted colour in highlighting a text

[sarasuri]

Hi,

I can’t seem to find any reference about highlighted colour in text and Web accessibility. In the screenshot below, the search term is highlighted using yellow background. In this case, the text passes the contrast ratio (SC 1.4.3) over its background. However, I am not sure should the yellow against its adjacent background white have at least 3:1 contrast to meet SC 1.4.11 Non-text contrast?

The highlighted search term is coded using the element.
<p>if you develop <mark>flu-like symptoms</mark> while travelling</p>

Any feedback would be appreciated.
Thanks

[patrickhlauke]

I can’t seem to find any reference

there are so many different variations of content, and how it's presented, out in the wild...don't be surprised that things aren't all explicitly referenced.

in answer to your question, if the yellow background there was the only thing that was visually highlighting the <mark>, yes it would need to have sufficient contrast, or you'd need some additional/other visual indicator to complement it. but in this case it looks like it's also differentiated through font weight/bold styling. as long as there are no other bold text elements, which may confuse things, that then means the background colour is not "required to identify" it, so exempt.

[bruce-usab]

@sarasuri -- if you do not have a follow-up question about this, please close this issues.

[giacomo-petri]

Please, keep this open.
I've got a few updates that could initiate an engaging discussion.

Assigning this issue to myself.

[giacomo-petri]

The 1.4.11 Non-Text Content success criterion applies to:

User Interface Components
Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
Graphical Objects
Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

The example doesn't qualify as a User Interface Component, nor does it represent a state (being a specific semantic tag). Hence, it doesn't meet the first condition for applicability.
Regarding the second condition, if we hypothetically consider that the bold property isn't set, the normative portion specifies "Parts of graphics required to understand the content...". Is the highlight essential for understanding the content? It's arguable, but in this case, one might lean towards it not being truly necessary.

Furthermore, if the tag remains uncustomized, browsers take charge of its handling. If the author refrains from customizing the background, foreground, and the mark itself, what outcome should we expect?

While the "User Interface Components" section provides clear guidance on this, what about the "Graphical Objects" category?
Adhering to the guidelines set forth for "User Interface Components" and taking into account the 1.4.3 Contrast (Minimum) success criterion, which provides a sufficient technique when both foreground and background colors are unspecified by the author, my viewpoint indicates it shouldn't result in failure.
However, concurrently, the mark lacks the minimum required contrast with adjacent colors and, in normative terms, might fail if the highlight is pivotal for comprehending the content.

Below is the example in Chrome without any CSS set:
<p>This is a <mark>test</mark>.</p>

Another pertinent aspect, in my view, involves clarifying the intent of the statement "where the appearance of the component is determined by the user agent and not modified by the author." Hypothetically, altering the font-size of the entire body could change the component's appearance, while the relevant CSS properties for evaluating 1.4.11 remain unaffected.
While I think we're in consensus about focusing solely on relevant properties impacting the success criterion, the normative aspect remains somewhat ambiguous.

[fstrr]

This issue is labelled as a discussion, so we’re moving this to Discussions. There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list.