1.4.3 Contrast (Minimum), 1.4.11 Non-text Contrast and ::selection pseudo-element

[giacomo-petri]

Issue #3250 brought to mind a topic I previously discussed with my colleagues: the "highlighted" state triggered by the ::selection CSS pseudo-element. This element applies styles to the portion of a document that the user has highlighted, such as by clicking and dragging the mouse across text.

I have created a few examples to facilitate a better understanding of the topic: https://codepen.io/Giacomo-Petri/pen/GRLPjOM

While it's not something I come across often, I've stumbled upon websites where they've personalized the "highlighted" text using custom color combinations that don't meet the minimum contrast ratio standards. Just recently, I encountered a page where the highlighted text was displayed in red on a yellow background.

At first glance it appeared to be a clear 1.4.3 Contrast (Minimum) failure, since the contrast ratio between text and background was insufficient.

In an effort to achieve a more impartial standpoint, I revisited the success criteria and definitions, aiming for an objective outcome. However, this reevaluation, in my view, underscored some lack of clarity surrounding related subjects.

Quoting the 1.4.3 SC:

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:

Large Text
Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;

Incidental
Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

Logotypes
Text that is part of a logo or brand name has no contrast requirement.

The highlighted scenario doesn't align with either the definition of incidental or that of logotypes, leading me to conclude that it would likely be subject to the 4.5:1 or 3:1 ratio requirements (depending on font size and weight properties).

Within the Understanding Document, there is an interesting paragraph which states:

The minimum contrast Success Criterion (1.4.3) applies to text in the page, including placeholder text and text that is shown when a pointer is hovering over an object or when an object has keyboard focus. If any of these are used in a page, the text needs to provide sufficient contrast.

Does "text highlighted/selected by the user" apply to this sentence? Moreover, upon reviewing this sentence multiple times, I find myself questioning the intent behind "including placeholder text and text that is shown when a pointer is hovering over an object or when an object has keyboard focus". Is it meant to convey "including, but not limited to..." or "including and limited to..."?

While the ::selection scenario may seem trivial and confined, I believe it holds significant implications for the outcome of the results of an accessibility test.

When I mention that it could have significant implications, it's because there are situations where users customize "voluntarily," creating a clear barrier for some users. However, in other cases, when the highlight color is the default one provided by the browser or user agent, it could potentially lead to unexpected outcomes.

Listing the examples I provided in the first link:

• Example 1: The author didn't apply any CSS, leaving the colors to be managed by the browser or user agent; minimum contrast ratio is met.
• Example 2: The author specified a custom style for the ::selection CSS property; minimum contrast ratio is not met.
• Example 3 (concerning scenario): The author utilized custom foreground and background colors, achieving a contrast ratio of 4.5:1 and complying with 1.4.3. Although the author didn't customize the ::selection property, the contrast ratio between the text and the "default ::selection" state fails to meet the minimum requirements.

Essentially, in numerous scenarios where the contrast ratio hovers just above 4.5:1, the contrast ratio between the highlighted text and its background tends to fall below the 4.5:1 threshold.

If this property is not applicable for the 1.4.3 SC, then it doesn't matter. However, if it is included, when does it become the responsibility of the author?

It could be worthwhile to note that there are also "states" which do not fall under the author's responsibility, like the browser's search functionality that highlights (using different colors) the search results found. For instance, Chrome employs an orange "found state" for the active result and a yellow "found state" for the other results.

To sum up:

• In my opinion, first of all would be great to clarify wether the 1.4.3 applies to other status/states such as the ::selection one. And if it's included wether it's an author responsibility:
  • I would really like to make 1.4.3 failing if the author customised the ::selected pseudo-element using non-accessible combination of colours (conscious author choice);
  • At the same time, I don't want to make passing scenarios failing due to the highlighted text scenario (if we decide to go ahead with this maybe we can say something like "if the CSS property is not customised by the author).

---

And what about the 1.4.11 Non-text Contrast success criterion?

The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

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.

About User Interface Components:
The ::selection is a pseudo-element, not strictly a state, although it may appear as such in non-technical terms (highlighted state?). Additionally, the highlighting also extends to user interface components like links, despite not being a property inherent to user interface components but rather more aligned with content properties.

About Graphical Objects:
In various user contexts and scenarios, the action of "selecting" text may be essential for comprehension and task execution.

With that being said, I lean towards viewing it as not applicable for 1.4.11 SC, though I acknowledge that not everyone may share this perspective.
If it is deemed applicable, how should authors address this? I'm hesitant to advocate for mandating authors to customize highlighted colors, as I don't believe it would be beneficial.

[patrickhlauke]

admittedly, i only skimmed over your very thorough issue here, but generally my take has always been:

• IF the author has customised the selection colour, they're on the hook for meeting colour contrast requirements for both text (1.4.3) and images (1.4.11) - if images can also be highlighted/selected
• IF the problem comes from the browser's own choices (default highlighting colour, the colour that the browser uses when doing in-page search, etc), then it's not the author's responsibility

Does "text highlighted/selected by the user" apply to this sentence?

I'd say yes (with the above caveat). It's not surprising that WCAG doesn't mention selection/highlighting explicitly, since back in 1999 or whenever this stuff was written, authors had absolutely no control over selection colours (via CSS or otherwise)

I'd say it's worth expanding the understanding to cover this scenario explicitly.

[patrickhlauke]

Example 3 (concerning scenario): The author utilized custom foreground and background colors, achieving a contrast ratio of 4.5:1 and complying with 1.4.3. Although the author didn't customize the ::selection property, the contrast ratio between the text and the "default ::selection" state fails to meet the minimum requirements.

Unless I'm mistaken, browsers generally force both a foreground and background colour to their highlighting, always ensuring the same contrast ratio regardless of what the in-page colours are set to (e.g. Chrome/Windows always goes for dark blue background and white text, regardless of what the unselected text/background is like). The one case that I've seen where things get really funky is when an author has assigned text shadow, which browsers don't - or didn't use to - override. But that probably goes outside the scope here.

[patrickhlauke]

Lastly, I'm wondering if the case of images may need some laxer rules though, as browsers seem to apply a semi-transparent overlay over images that are selected (since they can't do things like forcing a particular foreground colour). So you generally end up with a low-contrast end result, and that's outside of the author's control. (taking an example from the id24 website, with the logo highlighted)

So perhaps adding the clause about "selected still need to have sufficient contrast" just to text, maybe...

[patrickhlauke]

also, not sure if your initial post here covers it, but there's also a need for the highlight background to contrast sufficiently (under 1.4.11) with the page background (so a user can actually see/perceive what is/isn't highlighted). here again, it makes sense to distinguish between the browser's default selection/highlighting, and when an author has customised it - in the latter case, the author is on the hook to ensure that there's sufficient (3:1) contrast of the highlight background and the page background

[giacomo-petri]

I'd say it's worth expanding the understanding to cover this scenario explicitly.

I agree.

Unless I'm mistaken, browsers generally force both a foreground and background colour to their highlighting, always ensuring the same contrast ratio regardless of what the in-page colours are set to (e.g. Chrome/Windows always goes for dark blue background and white text, regardless of what the unselected text/background is like). The one case that I've seen where things get really funky is when an author has assigned text shadow, which browsers don't - or didn't use to - override. But that probably goes outside the scope here.

In example 3, the contrast ratio between text and background both set by the author is 4.5:1. However, the contrast between the text and the highlighted background color is 3.02:1, even though the author didn't set any ::selection property (it's the default one).

So perhaps adding the clause about "selected still need to have sufficient contrast" just to text, maybe...

I agree; maybe, generally speaking, I believe that the default "::selection" property should not be the responsibility of the author, whether it pertains to an image or text.

also, not sure if your initial post here covers it, but there's also a need for the highlight background to contrast sufficiently (under 1.4.11) with the page background (so a user can actually see/perceive what is/isn't highlighted). here again, it makes sense to distinguish between the browser's default selection/highlighting, and when an author has customised it - in the latter case, the author is on the hook to ensure that there's sufficient (3:1) contrast of the highlight background and the page background

I cover this aspect in my considerations, especially when determining its applicability to 1.4.11 :D

[patrickhlauke]

I cover this aspect in my considerations, especially when determining its applicability to 1.4.11 :D