We are generally discouraging arbitrary color usage per complications discussed in T360683. We are planning to expand the color palette (see T360494), but are unlikely to make the entire palette available directly to Codex users. The palette itself would live at the options token level, while Codex users have access to colors through decision tokens. Decision tokens capture the design choices for specific use cases and modes. What you're asking for sounds like you would require access to the options tokens. I don't see how that would facilitate night mode or accessibility, because night mode switching happens at the decision token level and anyone would then still be able to choose to use colors from the palette in an arbitrary and inaccessible way.

The limitation of color choice mediated through decision tokens is what is meant to ensure compatibility and consistency. I think there could be a world where we provide guidelines about color usage for customization in wikitext, but we're a ways off from that right now.

It could improves accessibility by removing arbitrary color uses to be sure to have only WCAG 2.1 AA compliant colors, verified by the WMF, for example.

Depending of the content of the options tokens, I guess wikis could copy/paste their definitions locally... Or we will need to define them by ourselves.

Like I said, on frwiki, I can't think of a near future with colorless infobox for example (some would agree, some wouldn't). So at least we could make them accessible and to harmonize them a little with Codex design decisions (for a globally harmonious interface).

In T361508#9694307, @CCiufo-WMF wrote:

I think there could be a world where we provide guidelines about color usage for customization in wikitext, but we're a ways off from that right now.

😔

In T361508#9694631, @Lofhi wrote:

It could improves accessibility by removing arbitrary color uses to be sure to have only WCAG 2.1 AA compliant colors, verified by the WMF, for example.

I like the spirit of this, but there are no specific WCAG compliant colors. Rather, it's the contrast between colors that make them compliant or not. This is why we lean on decision tokens, since they come built-in with guidelines on how they should be used together, to avoid accessibility concerns.

Like I said, on frwiki, I can't think of a near future with colorless infobox for example (some would agree, some wouldn't). So at least we could make them accessible and to harmonize them a little with Codex design decisions (for a globally harmonious interface).

If infoboxes were standardized (T359644) then we might be able to provide or recommend decision tokens that are suitable, but with the template fragmentation across projects that exists today, this is challenging and outside the scope of current Codex work. I realize this may be disappointing, but we have to focus our efforts and this doesn't seem like the place we can be most impactful right now.

In T361508#9707623, @CCiufo-WMF wrote:

I like the spirit of this, but there are no specific WCAG compliant colors. Rather, it's the contrast between colors that make them compliant or not. This is why we lean on decision tokens, since they come built-in with guidelines on how they should be used together, to avoid accessibility concerns.

The idea is rather as follows: for a proposed text color, also propose a background color with an acceptable contrast ratio.

In reality, there are two major use cases: a dark background color and light-colored text, or a light-colored background and dark-colored text. I say colors because the notion of contrast isn't necessarily obvious to contributors specializing solely in marine biology, for example, who are completely unfamiliar with the problems of the web industry.

But basically, on Wikipedia, you'll more rarely find light color on light color and dark color on dark color. Since for 20 years Wikipedia had a white background... it was generally a dark-colored background and light-colored (white) text, except for a few special cases that weren't accessible, and the weird colors choices, but accessible. The rest was black text on white background. And now there's night mode.

And as for colors, I don't think we need to complicate things. Like some mature CSS framework like Tailwind have a color palette and it's quite small (without the nuances). But since we aim for accessibility, it removes a lot of possibilities. So I think that if the WMF would work on it, you should start by using the base text color token of Codex as a basis for proposing color backgrounds that provide a sufficient contrast ratio.

What's most interesting is that accessibility of the final palette is verified by the WMF and that the colors are not extravagant in relation to the decisions made with Codex. I don't think the community can do this any better than you can. The problem is that we need more feedback from the communities for their needs... but it's difficult to gather. This is a problem for the industry, and of course not everything will appeal to everyone's personal preferences. I've accepted that it's not an obstacle, but I know that some communities are very resistant to any limits... even those posed for a form of standardization.

In T361508#9707623, @CCiufo-WMF wrote:

If infoboxes were standardized (T359644) then we might be able to provide or recommend decision tokens that are suitable, but with the template fragmentation across projects that exists today, this is challenging and outside the scope of current Codex work. I realize this may be disappointing, but we have to focus our efforts and this doesn't seem like the place we can be most impactful right now.

Can't agree more. And I'm not going to mention infoboxes that don't look like infoboxes... But if no one tells WMF the needs, it'll never happen, so we might as well specify them now and hope for progress in a few years' time.

A bit off-topic, but I'm interested in the answer: was APCA studied before Codex was designed? Does it make sense for a community to adopt it instead of the WCAG 2 contrast ratio calculation? It's to eventually set up locally accessible colors on a wiki until (we hope) more solutions from the WMF.

Thanks for the additional feedback @Lofhi, I'll add this as a subtask of T360494 for now.

A bit off-topic, but I'm interested in the answer: was APCA studied before Codex was designed? Does it make sense for a community to adopt it instead of the WCAG 2 contrast ratio calculation? It's to eventually set up locally accessible colors on a wiki until (we hope) more solutions from the WMF.

Maybe @Volker_E can answer this when back from vacation.

Edited the task structure to indicate this is actually a part of T363607: [EPIC] Improve the user experience of using Codex in wikitext and is blocked on T360494: Develop an expanded color palette for Codex.

There is a related discussion in https://fr.wikipedia.org/w/index.php?title=Discussion_Projet%3ACharte_graphique&oldid=215367450#Night_mode - I do think it would make sense for wikis to audit their own color palettes first before we even consider changes upstream.

@CCiufo-WMF, as @Jdlrobson advised, frwiki should plan to work on its palette of colors until.

I'm a not a specialized web designer and I'm not sure we have one in the community. Do you have any public documentation or references used when you specified the colors? The Figma file access displayed on the Colors page of Codex is also restricted. Did you use some criteria? Anything excepted WCAG is welcome (already a problem considered). Thanks.

In T361508#9832966, @Lofhi wrote:

@CCiufo-WMF, as @Jdlrobson advised, frwiki should plan to work on its palette of colors until.

I'm a not a specialized web designer and I'm not sure we have one in the community. Do you have any public documentation or references used when you specified the colors? The Figma file access displayed on the Colors page of Codex is also restricted. Did you use some criteria? Anything excepted WCAG is welcome (already a problem considered). Thanks.

Maybe @DTorsani-WMF can help provide some context on how we select Codex colors as the person working on the revised palette.

The team who builds Codex is currently working on an expansion to our color palette, which would include values for a wide spectrum of colors ranging from very light to very dark. These will be added into our system as option tokens and used within Codex as application or decision tokens to be used across system elements. We are not planning to open up the option tokens, just like we don't currently.

That being said, there may be an opportunity to do a deeper dive into how colors are used for text, backgrounds, etc. across wikis and potentially we could consider creating generic tokens for each color for text, backgrounds, etc. For context, this revised and expanded palette is being constructed with accessibility at the forefront, and aligns values to be more even across colors. For example, a 400 value in blue would have a very similar contrast ratio as a 400 value in red on a 900 value of yellow.

The placeholder task for this work is T360494.

In T361508#9849065, @DTorsani-WMF wrote:

The team who builds Codex is currently working on an expansion to our color palette

Has this been released already?

@Waddie96 yes. We released a broader color palette in Codex last year, which can be found in the Codex style guide. This work was written about on a project page.

One thing we did not do was add new generic color design tokens, like for background, border, and text for all colors. Our designated application design tokens can be found here.

One thing you can take away from the documentation written on the project page is the intention we built into the new color palette that is described in this section. Essentially, it describes the darkest value a background color can be to put text on and still maintain proper contrast for Level AA WCAG 2 accessibility. And the opposite for dark mode. With this, and the hex codes provided in the style guide, anyone should be able to have access to and choose Codex defined colors that span a much broader spectrum.

Please let me know if you have any questions or need any support in choosing colors.

I haven't contributed much since last year on any project, and I'm trying to catch up. Thank you for taking into account the community requests for a more broader color palette. If I understand correctly, the colors were defined, but not the tokens, and they are not yet usable on a project?

In T361508#9832966, @Lofhi wrote:

@CCiufo-WMF, as @Jdlrobson advised, frwiki should plan to work on its palette of colors until. [...]

I'm so late that we could think that I lied!

@Lofhi the colors were defined. Some of the new colors are being used as tokens, but many remain available to eventually use as tokens if we need them. But the hex colors can of course be copied and used as needed. If we determine a need for specific tokens that use more colors, we can make a task and consider doing that on the Codex board.

My initial request for a wider color palette was intended for use with Codex, rather than solely defined in Codex. The aim was to strengthen the link between community-based technical production and professional production by the WMF.

In other words, the community is still free to make its own choices, but would have a stable and comprehensive framework (I know that you prefer design system) to ensure stability and longevity in their technical choices. The community can do whatever it wants on top of MediaWiki base, but it should remain within the guidelines defined by Codex.

Redoing templates every five years, rewriting all the vanilla JS gadgets every five years for the brave, trying to correct past habits is tiring in the long run. That's why you have tickets wishing to use Codex icons directly in wikitext, to use components directly in wikitext, to use the JS part of Codex directly in gadgets. There is a real community need to professionalize community productions and, above all, to avoid yet another OOUI: something good that ended up being abandoned.

I imagine that communities can manage these CSS variables themselves. Except that this adds yet another unnecessary intermediary, which varies depending on each wiki project implementation. Sorry for going a bit off topic in my message, but Codex is really a good foundation now!

In T361508#11073814, @DTorsani-WMF wrote:

Our designated application design tokens can be found here.

One thing you can take away from the documentation written on the project page is the intention we built into the new color palette that is described in this section. Essentially, it describes the darkest value a background color can be to put text on and still maintain proper contrast for Level AA WCAG 2 accessibility.>

Yes, I use these all the time, thank you!

I believe the US government website design system uses the terms magic 70+ or something like to speak of relative luminance, or to describe how "far apart" the two colors are on that scale (in their case they use 5 to 90 or something). Quite a neat idea!

I think they had an open source color tool on GitHub or their website that they used to allow the end-user to get the closest HEX in the pallette to the HEX they input.

• Found it!!