Proposal for a cohesive colour system for Bokeh

[smeragoel]

Summary

Bokeh doesn’t have a cohesive colour system right now, which makes things inconsistent, harder to maintain, and less accessible. This proposal introduces a structured, accessible, and maintainable colour system to fix that.

Problem

Since there's no defined colour system, things have become messy over time. This causes:

• Colours being scattered and inconsistently applied across different components.
• New components often using ad-hoc colours instead of following a structured approach.
• Updating colours requiring manual changes across multiple locations.
• Difficulty enforcing colour guidelines, leading to contributors unintentionally introducing colours that don’t align with best practices.
• Accessibility issues since some colours don’t meet WCAG contrast guidelines.

Proposed Colour System

We put together a colour palette to fix these issues. I'm still in the process of tweaking these colours but these are minor changes. I'll update the image whenever there are changes, but for the latest version it'd be better to refer to the Figma version.

Primary & Accent Colours

• Primary Blue (#478FC1) – A refined version of Bokeh’s existing blue, optimized for accessibility.
• Neutral Grey (#88898C) – A standardized grey for graph components and UI elements.
• Accent Mauve (#B64AA6) – Chosen to stand out from the blue and highlight important elements.

Semantic Colours

• Success (#53993A) – A clear green for positive feedback.
• Warning (#D86750) – An accessible orange for warnings. Yellow was avoided since it’s hard to extend into a full palette without turning muddy or losing contrast.
• Error (#CE4442) – A well-balanced red for errors and alerts.

You can also access this palette on Accessible Palette

Visual Changes

Here’s how components will look with the updated colour system:

There’s not much of a visual difference, but the contrast is a lot better.

Feedback

Would love to hear thoughts on this. If you're giving feedback on the colours, it helps to be specific about potential issues rather than just personal preference.

🚫 "I like a more vibrant colour palette."
✅ "Some colours look muted compared to other visualization tools. Would a slightly higher contrast palette improve readability?"

This is an open discussion, so feel free to share thoughts!

CCing fellow contributors: @trallard @pavithraes @gabalafou

[gabalafou]

I'm not sure if I'm hallucinating but my immediate first thought seeing the two plots side-by-side was that the new colors looked more "Bokeh" branded. Did you take inspiration from the logo colors?

One issue I have is that I cannot very easily distinguish between warning #D86750 and error #CE4442, but perhaps that's intentional or not a bad thing, since semantically the two are not very far apart.

[smeragoel]

Thanks for the context on the logo @bryevdv!

Re: icon stroke - That's a good catch. There was a bug when I was replacing the icons, and it defaulted to the heavier weight. I've adjusted the icon stroke and reduced it, here's how it looks:

[bryevdv]

👍 updated version looks great IMO!

[trallard]

Agree, this weight looks better.

[trallard]

One issue I have is that I cannot very easily distinguish between warning #D86750 and error #CE4442, but perhaps that's intentional or not a bad thing, since semantically the two are not very far apart.

@smeragoel and I discussed this; it is hard to work with reds and oranges due to the small range in the hues. Ideally, we would not use colour alone, so other affordances would provide additional context, even if the colours are a bit similar.
Perhaps shifting the red towards a more coral or a deep-red or the orange to a more brownish... like they do in the GitLab colour system https://design.gitlab.com/product-foundations/color would help with colour visual distinction.

[smeragoel]

Thanks for the suggestion! This is how the updated colors are looking now:

You can also see them here:

• Figma Link
• Accessible Palette Link

I think this feels like a solid checkpoint 📍

I have started applying these colors in Figma and as I've already been tweaking them along the way, I don’t foresee any major changes. That said, we can keep an eye out during implementation and if any color issues pop up we can adjust them as needed!

[jbednar]

I just ran across this, so I'm sorry for chiming in late. I think the updated contrast does look better, but I have one concern that people are more often just looking at a plot than they are actively trying to interact with the plot's tools. Having those icons be muted helps avoid having them distract from the data, which is normally more important than the tools that one might use with the data.

So I'm wondering if this increase in contrast could be combined with having the tools be very low contrast until the user starts hovering over them or interacting with them? Or like Plotly, having the tools not even visible by default, and only appearing when needed? I know that latter capability was added to Bokeh years ago, but at least in the HoloViz ecosystem we've never been able to use it due to some limitations (if those are still present), and in general I don't think most people enable that feature. So my own vote would be to yes, crank up the contrast like this when trying to use the tools, but to have some way enabled by default that the tools are less prominent when not being used.

[trallard]

E.g. would someone consider Plotly to have failed this accessibility requirement, as their tools, by default, are not visible at all (zero contrast) until someone begins to interact with the plot?

They are not accessible, not only/solely due to the lack of contrast or their default behaviour of being hidden but in that they are not perceivable or operable unless a mouse is used to hover over them, making them not perceivable or operable to users relying on a wide variety of assistive technology or keyboard-only users.

So hidden tools does not mean they are inaccessible or accessible by default either.
I am afraid that accessibility can be rather nuanced.

[jbednar]

Sigh. Note that the mouse does not need to hover over the Plotly tools for them to become visible, just anywhere in or near the plot to which they are associated. So presumably the Plotly tools (or Bokeh with autohide) would be usable as long as there is a non-mouse way to select that particular plot for focus. Wouldn't it be necessary to have a way to select focus in any case (which plot are we working with?) for just about any form of keyboard access to work? Assuming that tools become visible once the plot has focus, again I don't see how accessibility would be impacted.

[trallard]

It does not matter if the hover is needed on the tools or the plot; that is the only way to interact with the tools in Plotly, so they are inaccessible.

Enabling alternative ways (to mouse) to operate any auto-hidden tools will be needed to ensure they are accessible in that sense, yes, but there might be other improvements/changes needed to meet other WCAG criteria.

[jbednar]

Sounds good. Hopefully Bokeh can do a better job than Plotly in this respect. Thanks!

[jbednar]

Oh, and @hoxbro has just submitted fixes for auto-hiding the Bokeh tools in HoloViews (so fast!), and so being able to handle hidden tools accessibly will then be important for HoloViz.