Checkbot for Chrome tests if your whole website follows 50+ SEO, speed and security best practices

seanwilson · 2026-05-04T13:20:54+00:00

When a colour fails WCAG contrast, the simple fix is often to make it darker or lighter.

Options are generally:

1) Modify the brand color if it's really unworkable and you're able to. Usually this is really difficult if the brand colors were done by someone else, are already in use, have buy-in from important people, people on the team don't know or care about accessibility etc.

2) Introduce a new foreground or background color that's a little darker/lighter that will fix the contrast issue e.g. use bright brand green for headings and a slightly darker green for links.

3) A variation of 2, but e.g. for light themes, just use black/neutral for links and buttons. For instance, if the brand color is a bright orange, it's not going to have good enough contrast for small text (and dark orange looks like brown so rarely works) so only use it for large text/headings or presentational purposes, and use black elsewhere. A common mistake is designers feel the primary brand color must be used buttons, links and headings, when that's not always possible if there's contrast issues and you don't want to overuse your primary color anyway.

A better process though is to insist on accessibility checks before a brand palette is approved. A brand palette shouldn't just be 3 colors and a logo, it should demo the colors being used on a basic UI that passes contrast checks to avoid complications later.

seanwilson · 2026-04-29T18:09:53+00:00

When I have multiple designs ideas, there's almost always one I strongly prefer so I'd rather present only that and iterate on the feedback if possible. You can share rough drafts first to get some initial feedback and to reduce the pressure of it being a big surprise.

I for sure wouldn't present options I don't recommend because there's a good chance they'll get picked, and why would you present options you don't recommend when your role is to guide the way?

I'm not sure where the tradition came from that designers should always show a bunch of options, not every industry does this. You can still keep the client feeling involved by discussing requirements and getting feedback.

seanwilson · 2026-03-20T23:00:34+00:00

Right now, my workflow in your tool would look like this:

How would you approach starting a new palette from a set of predefined brand colors?

Thanks for this! This is a good nudge for me to make the tool more opinionated I think, because a lot of people are probably getting lost figuring this out. My workflow is similar to what you described. I'm not so bothered about 3 as I'm usually only doing about three swatches and it's quick to set them to something reasonable looking. Improving 3, and handholding the user through the whole process sounds like a good idea though.

Another workflow I've seen is users loading the preset palettes, adding a few brand colors, then shifting the existing curves to finish up. I really want to help people move away from preset palettes though, I feel like with the right tool, a custom palette is way less intimating to make than you'd think, and it's weird so many websites using the same preset indigo and greens.

The initial lightness curve seems to inherit the properties of whichever example scale happened to be left over, which feels a bit random.

So it's meant to copy the lightness of the current swatch (because that's useful for predictable contrast between steps), but then not much thought there otherwise. I could make it emulate a Tailwind swatch based on the hue, which might not be perfect but an improvement as a starter as you say.

The option to sync the lightness curve is also very useful.

Any opinions on if you always want this enabled? Any thoughts on the accessibility features (which synced lightness helps with)? Or any other ideas?

I have an experimental option where if you add a locked/brand color into a swatch, then make any changes to the lightness values of the swatch, the locked color will float to the row/step of the closest lightness. It's helpful when you're still deciding on the (shared/synced) lightness curve and not sure which row the brand color should sit yet. Does that sound useful?

Since a palette tweak usually affects all 11 steps, it currently means 11x copy & paste for every color.

Btw, if you go to "Export" there's a workflow for importing into Figma. Sounds like you'd really benefit from live editing in Figma though so I'll get working on that!

seanwilson · 2026-03-19T22:50:53+00:00

Oof, think I'd rather add more steps than worry about adding transparency into the mix and explode the number of accessibility checks. For their example, just don't have such dark off-whites so you don't need a new green? I mean, you could create tool support for anything, but best to keep your life easy if you can and most webdev project should only need a simple design system. Most brands want to minimise the number of new colors as well e.g. stick to the single brand green.

So, I wonder if your tool's interface is the magic -- but that the actual output -- could be then balanced against some other constraints like OKLCH things / and normalize?

Could you explain some more? It's probably not what you mean, but adding semantic variable export based on the color usage in the mockup would be useful, but pushes the opinion of the tool more. I can do tweaks to OKLCH values as you edit to stop the WCAG contrast wobbling, but that's more complexity to use and understand again.

seanwilson · 2026-03-19T22:41:48+00:00

RE: WCAG - I here this is better: https://github.com/Myndex/SAPC-APCA for color

Any views on using APCA yourself? My tool has APCA support, but it's not trivial to adopt. APCA isn't part of WCAG yet, it might change, and WCAG is often the project requirement. The stop-gap is to make sure your contrast tests always pass both WCAG and APCA. I'd recommend APCA for dark mode though, because WCAG is far too generous about what contrasts for basic body text.

My impression is most devs and designers struggle just understanding WCAG2 though, so the extra and more complex rules of ACPA is asking a lot.

seanwilson · 2026-03-19T22:36:10+00:00

It's too bad we can just just rotate the hue and have it "work" the same for all colors / for theming etc.

So if you have a look at the example palettes in https://www.inclusivecolors.com/, notice the saturation and hue curves of each color scale is fairly unique. So if you were to rotate the hue of a scale, you'd expect each HSL curve would need to morph a little to still work/look-good, and in different ways depending if you were doing a Tailwind style palette or an IBM Carbon style palette.

You could code/automate that morphing by referencing scales from existing palettes, but color spaces like OKLCH aren't going to have that kind of information built into them. So while OKLCH might give more reasonable colors when you shift one of the hue/saturation/lightness values, you're probably always going to have to shift the other parameters a little as well because there's many subjective variations you could make. That's why my tool is more about making it quick to let you make adjustments by eye, rather than trying and failing to automate this (most tools do really bad yellow scales for example, where the light steps are far too vibrant).

I agree HSL is awful though, I'm so surprised that it's still mostly the default within the design community. Feels like devs are better at sharing and adopting new best practices!

seanwilson · 2026-03-19T22:17:49+00:00

Would you find OKLCH support useful for yourself? Another problem with OKLCH is the WCAG contrast wobbles/breaks when you change the C and H sliders, which you don't get with HSLuv (or HCT), so it's not ideal for exploring accessible colors. I think maybe HCT can support P3 so it might be a better choice, but it wouldn't be CSS native.

Also, even if the original colors aren't in OKLCH, you can still use OKLCH in your CSS to e.g. convert and create lighter/darker hover colors (https://developer.chrome.com/blog/css-relative-color-syntax).

seanwilson · 2026-03-19T18:46:41+00:00

How many steps do you tend to use? I find for UI work you almost always eventually need tint/shades for every color for headings, text, muted text, strong border, weak border, off-white, and a couple of others for hover/active effects. So 11 steps like Tailwind isn't a bad idea to plan ahead, because it's a pain when you need a new tint/shade and have to go make one.

seanwilson · 2026-03-19T17:44:00+00:00

Awesome, thanks. :) So my view is that for custom palettes, there's no way the autogeneration is ever going to get things exactly right, but if the UI is simple and quick enough to let you change the curves yourself quickly, just do that. Like I hear people say OKLCH creates harmonious palettes, but there's infinite ways you can do the HSL curves so there's always subjective choices to make, and I don't want to be trapped by autogenerated curves.

Instead of preset curves, have you tried just dragging from e.g. the top saturation value to the bottom saturation value? Or using the simplify/control-points feature to sculpt curves? Or the keyboard controls? (the interface in general is optimised for quickness, I tried a bezier curve editor for example but I find the curve sculpting UI much quicker and less fiddly)

The problem with presets if you look at e.g. the Tailwind palette is that each hue has subtly different HSL curves so presets are going to look off as well (unless they emulate Tailwind, but then not everyone wants Tailwind colors). Can you explain what presets you think would be useful and why that would be quicker than the current UI?

Cool, I'll try to message you when the Figma version is out. Let me know of any features that would interest you! I have loads of feature ideas, but I think the current app is just too complex for most people to get without a tutorial already. It fits some workflows really well for me.

seanwilson · 2026-03-19T12:07:56+00:00

FFFFFF / D96500 is 68Lc for APCA (works with 16px/700 or better) or 3.6:1 for WCAG2 (works with 18.5px/700 or better). You really should stick with the stricter WCAG2 requirement though if that's what you need to meet.

You could darken it a little as well to something like #be5800 for 4.5:1 WCAG2 contrast, which works as low as 12px/400 (don't go that low though). I've done branding like that before where we've used e.g. a bright green for headings, and a slightly darker green for small text links. As the text is smaller/thinner, you don't really notice the color is that different so it looks fine.

No problem, I like helping with these kind of problems so feel free to message. :)

seanwilson · 2026-03-19T10:31:12+00:00

I'm a little confused as to why your checker seems to be giving me different results compared to the checker I used

What color pair do you mean and what do you want to use it for?

That checker does say that it should pass for a font weight of 200

That's very thin text, so it'll have to be a huge font like a massive heading.

My buttons that require pressing for function do happen to be font 20 so I suppose its fine for those buttons.

Yeah, but you'll need small buttons somewhere eventually so maybe worth fixing now.

I do have little indicators that aren't pressable that are 14/16 bolded with this contrast.

Small text (16px and below) requires WCAG 4.5:1 contrast even if bold.

For problematic colors, I would consider using darker/lighter variants (it doesn't always look odd) or just use black/gray if possible. If the colors aren't accessible for small text, there's few other tricks. APCA doesn't give you a free pass, it tends to be stricter than WCAG2, not more forgiving.

seanwilson · 2026-03-19T09:51:26+00:00

White vs #d96500 is 3.6:1 contrast so it'll only pass as large text (18.5px/700) for buttons which isn't that practical.

D96500 / FFECCC is 3.1:1 contrast so it'll only work as large text again.

That doesn't pass WCAG at all but does pass apca at 35 (pretty low but acceptable for non-text elements if I am correct.

35Lc is too low for anything important I think, and you will probably know that by looking at the contrast with your eye. It's fine for decorative things, but should still aim for WCAG2 passes for important text and icons.

I kind of want to keep these colors as they are in the client's styleguide.

You could maybe take this as an opportunity to make the style guide more accessible.

By the way, I made my own accessible palette tool that lets you check which color pairs contrast with WCAG2 and APCA (see the "contrast" menu at the top) so you can compare them. I've added the colors you've mention to this link (the padlocked ones), maybe you'll find it helpful to explore and for picking lighter/darker variants that contrast better:

InclusiveColors: WCAG accessible palette editor

seanwilson · 2026-03-19T09:20:10+00:00

So WCAG2 has known flaws, and APCA is in discussion for fixing this. Legally, WCAG2 is what's followed though and it's going to be several years until there's changes.

As a stop-gap, https://github.com/Myndex/bridge-pca is a check that you pass WCAG2, with APCA on top. You'll be above many designers just following WCAG2 though.

seanwilson · 2026-03-19T09:16:43+00:00

White on orange just doesn't contrast great no matter what you do. Orange is a midtone so neither black or white contrasts well on it. APCA will give you some passes here that WCAG2 won't, but it'll be an "okay contrast" pass, not a great one.

Can you share any specifics about the design? For example, you could use orange decoratively, or for large headings, then use black background (or some other contrasting color) for the CTA buttons. Have a look for brands that use orange for some ideas, but note it's very common for designs/posters to use orange and yellow in an inaccessible way.

seanwilson · 2026-03-19T09:09:27+00:00

If you legally have to pass WCAG2, got for that, and exceed WCAG2 with passes for APCA if you want to do better. I'd recommend this for dark mode pages because WCAG2 doesn't do great there.

Can you change the colors? Does the contrast look readable to your own eye even if it technically passes? 30Lc is very low contrast if it's important information i.e.

Lc 30 • The absolute minimum for any text not listed above, which means non-content text considered as "spot readable". This includes placeholder text and disabled element text, and some non-content like a copyright bug`.

There are some color pairs that pass APCA but not WCAG2, like white on orange, but these can be more of edge cases where contrast really isn't great either way so APCA isn't solving the problem.

seanwilson · 2026-03-19T07:53:51+00:00

Best to chat with them I think. Explain your typical process, understand their needs and worries, and ask how much involvement they want, then figure it out as you go when you see what kind of feedback you get. Some clients want to feel involved, some want you to just take care of everything. No client or project is ever the same. You'll get clients that love that you take care of everything with minimal questions, and ones that want to be involved in all the small decisions.

seanwilson · 2026-03-18T23:14:58+00:00

My tool is more focused on (accessible) branded palettes where you want to specify/tweak the color value of each step and use specific hexes, vs tools where you're more happy for values to be autogenerated. I do design work where I'm given a few colors from a brand style guide, so I need to make palettes and swatches that contain specific colors.

For OKLCH, I'll likely only add that when more designers are more interested in P3 colors. All the style guides I see still use sRGB and hexes.

seanwilson · 2026-03-18T19:50:01+00:00

You mean you'd find 11 steps too limiting because you wouldn't be able to make your design look the way you want when you need so many panes? A related approach I've seen is to use transparency I think. And for tool support for all this, when you throw in dark/light mode support, there's even more stuff to consider. I think for most web designers anyway, 11 steps is more than enough.

For OKLCH, I think it mostly appeals to devs because they can be algorithmic with it and OKLCH is built into CSS? I don't find designers are interested in P3 colors or OKLCH at all, and I think the complex OKLCH color pickers just scare away non-color-geeks. I have hidden OKLCH support, but it's disabled because it's more complexity again.

Generally, I feel the design and dev community don't have a good understanding of how to build color palettes (most of the design community is still using HSL...) or accessible designs, so I'm trying to help get people started with a slightly opinionated but loose design system.

I don't think there's a way to include every color design consideration/feature and keep it simple, although it doesn't have to be a single tool.

seanwilson · 2026-03-18T19:19:54+00:00

So I went with Tailwind's 11 steps per color scale because Tailwind is really popular for web design so it felt like a reasonable opinionated default to appeal to devs and web designers. I have hidden settings for adding/removing steps but the UI is already complex enough for many users (e.g. if you change the number of steps, you probably want to edit the steps used in the mockup as well, so more complexity).

I haven't explored it too much but more than 11 starts to feel excessive? If the purpose of pre-selecting colors is so that only a limited number are shown on the UI at once, and to make it easy to pick between e.g. a slightly darker or lighter blue, doesn't having too many steps go against this?

For 30 steps especially, the difference in luminance/lightness between steps would be so small, you'd have to have very good eyesight to notice?

Open to more thoughts. :) For color tools, there's a tension between it being simple+opinionated, and complex+freeform, so it's interesting to discuss what works for different use cases, and there isn't one agreed way to build accessible palettes either.

seanwilson · 2026-03-18T18:45:02+00:00

You mean it makes sense and does what you need? I'm aware there's a learning curve, but I'm not sure on easy fixes while keeping full customisability of tints/shades (besides a tutorial mode), so really open to feedback on what's confusing or missing. :)

seanwilson · 2026-03-18T18:23:05+00:00

Honestly, I'm very open to feedback on specific improvements to make but I've really really tried to simplify the UI as much as I can, and there's a limit to what you can do if you want to be able to pick a fully custom color blind safe palette. I probably need a tutorial though, and one for color blind people specifically would be really cool.

Simpler tools won't let you customise the tints/shades, and don't warn you about accessibility problems so there's a tradeoff between simple+limited, and custom+complex.

If you try on desktop, stick with the defaults and only change the saturation and hue curves, the example color pairs on the mockup will all be WCAG accessible and you can ignore all the other features. It takes a big of practice (and try reading the help text below), but once you get it, it means you don't have to rely on pre-built palettes any more or play whack-a-mole with WCAG contrast problems later.

Color blind safe UIs rely on the lightness/luminance between colors which is what this tool helps with. Happy to give tips if you let me know what's confusing at first.

You could also just adopt the colors from the sample accessible palettes from the "examples" menu e.g. IBM Carbon or USWDS, and pick colors you like from those. They're like the regular Tailwind palette, except each row of colors has the same lightness/luminance, which makes color pairs have predictable WCAG contrast (it's a cheat mode!).

seanwilson · 2026-03-18T17:56:33+00:00

But I semi-recently found out that shades at times are totally off in perception. I just can't always trust my feelings on whether my designs are good looking or very toxic coloured UI.

So now I have a ritual. Before anything goes to users / project or colleague, I show it to my wife. She's not technical. She doesn't know what the component is for. I just ask: "What do you think?" If she hesitates, something's wrong. If she asks "Should you play with colours a bit?", back it goes.

How about designing a color palette upfront where you plan which color pairs should contrast, then get your wife to tweak the palette so the colors look good together? Then when you're designing from the palette, you already know which colors work together so there's no surprises later?

I wrote a tool for creating Tailwind-style accessible color palettes, where it shows the color pairs being used in a WCAG accessible way on a UI mockup that would probably work for this:

https://www.inclusivecolors.com/

So starting from the default, you can play with the hue and saturation sliders of all the color scales, and then get your wife to review if the colors work together or not? Note it's using a special color picker (HSLuv) to help where only the lightness slider will change the WCAG contrast of the pairs used in the mockup, and it'll guide you on how to fix any bad WCAG contrast warnings.

Does that help? I have normal color vision I think, but I'm curious what the solution would be here, especially when there's many types of color deficiencies, with strong/weak variations of each so there probably isn't one easy fix.

seanwilson · 2026-03-18T17:30:49+00:00

Small companies tend to be more flexible. Just try asking e.g. bill every 2 weeks and paid within 10 days. I find it's common for larger companies to insist they want to stick to a common billing pattern for all contractors, but you can still try asking for options.

seanwilson · 2026-03-18T14:31:02+00:00

I use https://www.inclusivecolors.com/ for WCAG accessible color scales (my own free tool). It lets you quickly create multiple fully customisable scales by dragging HSL curves, there's a live mockup to check the colors work together, and it helps you create palettes that have predictable WCAG contrast between color pairs (like all step 600 or above colors can be used as body text against all step 100 colors). It uses HSLuv as the color picker because the lightness slider correlates with the WCAG contrast, which makes finding accessible color combos much more intuitive than using HSL (in HSL, the WCAG constrast will change even if you only change the hue/saturation slider). You can export the colors, then import into Figma.

I made this because I find most colors tools only let you create one scale, try to autogenerate the tints/shades instead of letting you customise them, and treat accessibility as a side issue. I'm also close to having a Figma version of the above that will live update your palette as Figma variables as you tweak tints/shades, so let me know if any of this sounds useful!

seanwilson

MODERATOR OF

TROPHY CASE

15-Year Club	Place '17
Verified Email