Page MenuHomePhabricator

Broader color palette to facilitate wiki Codex adoption
Open, Needs TriagePublicFeature

Description

Feature summary (what you would like to be able to do and where):
Adding tokens for a broader color palette.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Some wikis might use arbitrary colors in creative ways. For exemple, the wikiproject biology on frwiki could use the green color as main color of its main page. Meaning it could break on night mode or just not being accessible (WCAG AA). It's complicated to propose to the community that colors should disappear altogether, so an alternative and perhaps intermediate solution would be to propose an accessible broader color palette defined by the WMF.

Benefits (why should this be implemented?):
This would make it possible to manage the addition of night mode easier. Facilitate accessibility. It doesn't mean that the new colors should be used in the Codex components. The target is to regain control over color choices within projects and inappropriate uses (not using media queries, using inline static css rules, not defining a background and a color at same time, etc.).

Event Timeline

Lofhi updated the task description. (Show Details)
Lofhi updated the task description. (Show Details)
CCiufo-WMF subscribed.

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).

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.

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.

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.

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.