Token @color-placeholder was chosen recently in T367432 by @bwang.

In T369667#9987026, @DLynch wrote:

Token @color-placeholder was chosen recently in T367432 by @bwang.

For extensions we are not familiar with, the web team picked the closest token to the current color in order to ship dark mode quicker.

I think the ask here is to now to re-evaluate the color here from a semantic perspective alongside Codex's design tokens. If a suitable token doesn't exist, please work with the design systems team to create or find the right one.

hey @CCiufo-WMF – a question for you (we think!) emerged in a meeting between @DLynch, @Jdrewniak, @ovasileva, and I just now about how to make comment/topic permalinks appear in dark mode in a way that passes accessibility contrast checks.

DiscussionTools currently uses the color-placeholder design token for styling comment/topic permalinks in dark mode and light mode. Should we continue doing so?

Why we're asking...

1. Through QA (T365509#9965955) we came to learn (T369667) the color-placeholder design token styles links in a color that does not pass accessibility contrast checks
2. color-placeholder does not seem to have a dark mode value

In T369667#9987110, @ppelberg wrote:

hey @CCiufo-WMF – a question for you (we think!) emerged in a meeting between @DLynch, @Jdrewniak, @ovasileva, and I just now about how to make comment/topic permalinks appear in dark mode in a way that passes accessibility contrast checks.

DiscussionTools currently uses the color-placeholder design token for styling comment/topic permalinks in dark mode and light mode. Should we continue doing so?

Why we're asking...

1. Through QA (T365509#9965955) we came to learn (T369667) the color-placeholder design token styles links in a color that does not pass accessibility contrast checks
2. color-placeholder does not seem to have a dark mode value

Thanks for the context! I assume we should be using color-subtle here instead. @DTorsani-WMF would be curious to get your input.

To answer the question from @CCiufo-WMF, yes, we should use color-subtle here instead. This is the lightest color that readable text should be. Since placeholder and disabled text does not need to technically pass contrast ratio standards in the same way, they do not need to be accessible. This text also does not seem to be "placeholder" text, so it should not use that token.

Demonstration of the change requested from the original design review in T275729:

color-placeholder	color-subtle
gray-500 / #72777d	gray-600 / #54595d

For myself, I'll miss the lighter color because the dark gray is so indistinguishably close to body text that it no longer lets me filter the timestamps out while I'm reading, but I acknowledge that accessibility may trump personal taste here.

In T369667#9994838, @DLynch wrote:

For myself, I'll miss the lighter color because the dark gray is so indistinguishably close to body text that it no longer lets me filter the timestamps out while I'm reading, but I acknowledge that accessibility may trump personal taste here.

I agree, I'll revert to using @color-placeholder in my user script designs and set my custom color for dark mode that would fit AA.

In T369667#9994715, @DTorsani-WMF wrote:

Since placeholder and disabled text does not need to technically pass contrast ratio standards in the same way, they do not need to be accessible.

While this is true, note that #72777d was seemingly chosen precisely to fit the AA criteria for white background. If the dark mode doesn't have a matching color (there is a huge gap between gray500 = #72777d and gray400 = #a2a9b1), so much the worse for it.

Thanks for this note @Jack_who_built_the_house. Since it can be very challenging to control what background color all text colors could potentially appear on, something we are trying to do as a part of T360494 is to determine and define the lightest potential text colors on the darkest potential background colors (darkest potential text colors on the lightest potential background colors for dark mode) to help make text color and background color decisions more uniform and ensure visual accessibility.

In T369667#10019239, @DTorsani-WMF wrote:

Since it can be very challenging to control what background color all text colors could potentially appear on, something we are trying to do as a part of T360494 is to determine and define the lightest potential text colors on the darkest potential background colors (darkest potential text colors on the lightest potential background colors for dark mode) to help make text color and background color decisions more uniform and ensure visual accessibility.

I'm wondering whether it's possible and/or worth it to try and "drag" @color-placeholder into the AA zone on any light background (dark in the dark mode). You, of course, rightly pointed out that "This text also does not seem to be "placeholder" text, so it should not use that token", but as @DLynch argued, the use case here is to make the text color as far from the body text color as possible to let users "filter the timestamps out while they're reading" (while keeping them accessible), so maybe another token is needed for such cases.

While we're at it, there are problems with DiscussionTools when the text is on a slightly darker background in light mode, e.g. #f8f9fa of the preview:

• "Preview" (.ext-discussiontools-ui-replyWidget-preview::before) is #808080.
• The signature has opacity: 0.6 which, together with gray for timestamps, pushes the contrast of the timestamp even lower.

The slightly-complex situation where it is, indeed, a little hard to read. But it's deliberately so, by design, because being hard to read is what lets it fall out of the flow of the text unless you deliberately focus on it. 🤔