A Brief Note on Highlighted Text
TL;DR: If you plan to style text highlighted by the browser, you must give it sufficient contrast — 3:1 for the highlight block against its background and (probably) 4.5:1 for the text within that highlighted block against that background.
CSS Context
CSS provides methods to style the highlights that browsers apply from selected text (::selection), link target text (::target-text), and spelling & grammar error text (::spelling-error and ::grammar-error).
To limit layout shifts, the spec only allows setting background-color, color, text-decoration (and its associated properties), text-shadow, stroke-color, fill-color, and stroke-width.
The CSS Pseudo-Elements Module Level 4 Working Draft specification covers this in § 3. Highlight Pseudo-elements, including the allowed properties.
When using Windows High Contrast Mode / Contrast Themes / forced-colors, ::target-text will use CSS system color keywords MarkText and Mark. While ::selection will use HighlightText and Highlight. Conversely, ::spelling-error and ::grammar-error use text-decoration, not background / foreground colors.
According to Delan Azabani on Mastodon, Igalia is working on bringing find-in-page pseudo element selectors (::search-text and ::search-text:current) to at least Chromium while acting on the CSSWG issue for same. I could not find what system color keywords it would use (though I just asked and it has its own issue as of 14 May).
WCAG Context
WCAG SC 1.4.3: Contrast (Minimum) requires a contrast ratio of at least 4.5:1 for text against its background. Larger or bolder text can get by with a 3:1 contrast ratio.
SC 1.4.11 Non-text Contrast similarly requires a 3:1 contrast ratio to distinguish a UI component’s state (such as selected). This may be against the page background or it may be the background of the container. Which means this highlight color may need to be defined more than once in your page (and the text along with it).
When you pair these two Success Criteria, it means your highlight background needs a 3:1 contrast ratio against its own background and the text will need a 4.5:1 (unless bold / large) contrast ratio against that.
As a curve ball, SC 1.4.1 Use of Color states that color is not the only method used to convey information or distinguish a visual element. The challenge is that the limited styles the CSS specification allows are mostly color, with the obvious exceptions of text-decoration (and its associated properties), text-shadow, and stroke-width. It may be impractical to lean on these in many contexts, but I expect the AGWG will get dragged into it at some point (see the discussion on visited / unvisited links for example)
You may have noticed that default user agent styles regularly have contrast issues. That doesn’t make them ok, but they are outside the scope of WCAG. As soon as you modify the browser’s default styles, you are on the hook for conforming to WCAG. Consider this note for the WCAG definition of contrast ratio (relevant bits highlighted):
WCAG conformance should be evaluated for color pairs specified in the content that an author would expect to appear adjacent in typical presentation. Authors need not consider unusual presentations, such as color changes made by the user agent, except where caused by authors’ code.
Also, 1.4.11 has this carve-out: …except […] where the appearance of the component is determined by the user agent and not modified by the author.
Essentially, if you touch it, you own it.
Related
Other posts of mine about customizing what are otherwise system defaults and are often fine if you don’t mess with them:
Wrap-up
If you plan to style text highlighted by the browser, you must give it sufficient contrast — 3:1 for the highlight block against its background and (probably) 4.5:1 for the text within that highlighted block against that background.
7 Comments
Reply There *may* be possible variations – it may not necessarily be that the highlight block itself must have 3:1 contrast, but the overarching goal would be that you can still tell (without relying just on use of color, for instance) what is and what isn’t highlighted text. So in theory, at least making sure that there’s a sufficient visual difference (of contrast, or other visual styling) between non-selected and selected text.
You could also do things like making sure the *border* of the highlight block has sufficient contrast, but then the actual highlight background is lighter.
But yes, as said on socials … as soon as you (the author) decide to define your own highlight colours, you then can’t just wash your hands of it and say it’s the browser’s (de)fault.
In response to . Reply One of the challenges I see here is the limited set of CSS properties that can be set. The text stroke/fill options and text shadow are meh, but text-decoration can at least offer a non-color visual in lieu of border styles (which are disallowed).
And for readers, Pat indeed called this out on the socials before I wrote this post. Grumpy minds grump alike.
Reply Ah, my bad, missed the fact that border styles are disallowed. They should have at least allowed outline properties though…
Reply I see where you’re coming from with SC 1.4.11 Non-text Contrast, but I’m not sure how it applies to text? That requirement applies to User Interface Components and Graphical Objects. Text certainly isn’t a Graphical Object. Is text a User Interface Component? WCAG defines it as “a part of the content that is perceived by users as a single control for a distinct function”. And the WCAG definition of “state” only applies to User Interface Components.
I’m not saying your position is wrong per se, but I think it’s more nuanced. For example, if you need to support both temporary and permanent highlights, maybe the latter qualifies as a User Interface Component and gets all the contrast, whereas the former doesn’t.
In response to . Reply The highlight is typically defined by a background. That background needs to be visually distinct enough from the page / container background to make it clear which run of text has been highlighted. Selected, targeted, incorrect, and found are all de facto states of the content (certainly as perceived by the user). That content, in the context of selecting, targeting, flagging, and finding, is all part of the user interface. Hence 1.4.11.
Leave a Comment or Response