Follow

Reasonable Colors is an open-source colour system for making accessible colour palettes.

It uses an intuitive system of shades to help you select colours which meet the appropriate WCAG contrast rating, even if you're mixing and matching base colours:

reasonable.work/colors/

@chriswood Looks like they forgot #colorblind people.

My usual approach to colors is to start with the palette of Paul Tol: personal.sron.nl/~pault/

@ArneBab This is fascinating - thank you!

What do you use Paul Tol's colour palette for? Graphs and technical diagrams, or something esle?

My visual design work is in producing user interface designs. I think I'd struggle to use his palettes as I couldn't see anything about how to create lighter and darker colour variants.

Going by the WCAG 2.1, as long as any information conveyed by colour is also accessible via another means (e.g. text or icon), it meets the criteria for my UI work.

@chriswood I mostly use the palettes for displaying data (diagrams, maps, …). The main challenge I see is that once you need more than 12 distinct colors that work well for colorblind people *and* look good, you’re pretty much lost.

I worked with our UX team at work to build colorschemes, and the only approach that actually turned out to be viable is to choose a main color and then to adapt the palettes from Paul Tol to match it without losing recognizability for colorblind (i.e. use kmag).

@chriswood If your goal is to meet the acessiblity *requirements*, then just providing an alternate way to distinguish controls is enough. But if you want your UX to be enjoyable to use for colorblind (5% of the population), you can go further and ensure that the colorcoding also works for them.

@ArneBab That is wonderful insight, thank you for sharing it.

Accessibility in my team is often talked about as a series of requirements to tick off, rather than as a human being's experience. It's really helpful to hear about your experience producing diagrams for colourblind colleages and how they've received them. I'm happy to hear they enjoy your work!

@chriswood It also started as requirement for me, but that was years ago with my first paper ( acp.copernicus.org/articles/15 ).

I learned a lot more when I published a draft for a purely text-based game in the browser for which I thought that it would be trivial to make it fun for blind people, too. It worked in the end, but have a look at the source to see what fraction of the UI is accessibility.

dryads-wake.1w6.org/

@blindscribe and @FromtheAbyss helped a lot in making that enjoyable.

@chriswood I think the most important takeaway is: When you’re going to spend serious time on acessiblity, use some of it to talk to people for whom you do that and ask them what’s missing.

In case of dryads-wake, one change I would have never thought off is to add a first sentence (appears line by line) and actual written clues for controls.

Another point was to actually use a screenreader — that’s what I did before asking anyone else. It was so horrible that I’m glad I tried before asking ☺

@chriswood nice, would it make sense to integrate this into some colorpicker in open source tools like gimp @Krita or @inkscape etc?

@chriswood There is a lot of "wrong" in UI designs nowadays... Especially the tendency to put dark gray text on light gray background, making it near impossible to read on mobile phone for me, especially when the stupid phone insists on dimming the background light in dark rooms...
(sorry, for ranting)
Your palettes are almost fine for me on the computer monitor, no idea what happens on phone display, which is where most my problems are. Thanks for trying!

@niclas I can't take credit for this I'm afraid - it's the work of Matthew Howell at Reasonable Company. You can find out more about his work on his company's website: reasonable.work/

I do agree with your point about inaccessible design. As someone with good vision, it can be aesthetically pleasing to scroll through a app design showcase website like Dribbble with designs that have low contrast text, but it would be exluding to implement choices like that (not to mention a pain to use)

extra notes on color contrast: don't use WCAG, use APCA 

@chriswood while I absolutely love this, I want to point out to the folks who may not know that WCAG's simple contrast algorithm is actually not necessarily the best tool for determining what colour combinations are best, for a couple reasons:

it doesn't distinguish between foreground and background colours, when this actually makes a big difference
it doesn't make that big an effort to distinguish between what contrasts are appropriate for what situations, beyond the vague idea of "large text"
it isn't really as friendly since it's not perceptually uniform, meaning that a contrast of 4.5 seems like half 7, but there's actually a big difference

right now there's a big project to create a separate system that does fix these problems and it also works as a percentage rather than a weird number between 1 and 21: github.com/Myndex/SAPC-APCA

in case anyone else also finds this helpful!

extra notes on color contrast: don't use WCAG, use APCA 

@clarfonthey @chriswood very helpful thanks for sharing

re: extra notes on color contrast: don't use WCAG, use APCA 

@clarfonthey @chriswood Important to note that the APCA is still being refined. Best to pick a palette that meets both the WCAG 2.2 and the APCA guidelines, for now.

On top of that: yellow has great contrast against dark colors; however, yellow and red are autism-unfriendly colors that can trigger overstimulation. They’re fine if you de-saturate them by darkening them (brown/brick-red) or lightening them (pale yellow, pink).

Furthermore, remember that you don’t actually want your APCA contrast to be too high on dark themes (unless you’re making a high contrast theme for users who explicitly request one, e.g. using a prefers-contrast media query). White text on a black background can trigger halation in astigmatic users. Lighten the background ever so slightly to create a soft “glow” capable of minimizing the halos, and make your foregound colors no brighter than #eee (#feb is about as bright, for instance).

I wrote about this in more detail in the “about custom colors” section of a post of mine.

re: extra notes on color contrast: don't use WCAG, use APCA 

@Seirdy @chriswood fwiw, you do not want to choose colours that fit both criteria because it seriously limits your options. there's the standard Bridge-PCA specifically designed for this: github.com/Myndex/bridge-pca

but here's an excerpt from the readme:

No Free Lunch: while BridgePCA corrects the many false passes and improves readability, the cost is that there is reduced design flexibility due to the fact that to maintain backwards compatibility, some contrasts are forced higher than they actually need be.

...

But if you need a standards compliant method that also improves readability this is it. If on the other hand you do not need to abide by the letter of any particular standard, you may want to consider the more flexible full APCA solution.

basically, unless you're legally or otherwise obliged to follow WCAG 2, you're 100% better off just using the proper APCA algorithm. and while it can change, again, unless you're legally obliged to follow the standard, you should be fine just following the numbers as they show up, since the changes that will happen at this point are rather small and won't really affect your values more than a few percentage points

@chriswood on my iPhone the yellow text link seems a bit hard to read, is that just me?

Sign in to participate in the conversation
mastodon.design

A Mastodon instance for and by people who make things!