DEV Community: Avishek Dhimal

Your color palette probably fails accessibility. Here's how to check it in 30 seconds

Avishek Dhimal — Sun, 05 Jul 2026 11:46:44 +0000

Here's an uncomfortable stat: most color palettes that look great fail the most basic accessibility test — text contrast.

I learned this the hard way. I built a landing page with a palette I loved: soft coral text on a warm cream background. Beautiful in a screenshot. Then someone told me they literally couldn't read my hero heading on their phone in daylight.

The palette wasn't the problem. The pairing was.

The 30-second check

Text readability is measured by contrast ratio — how different your text color is from the background behind it. The WCAG standard is simple:

4.5:1 minimum for normal body text (AA)
7:1 for the stricter AAA level
3:1 for large text (24px+)

Black on white is 21:1 — maximum contrast. My coral-on-cream disaster? About 2.1:1. Nobody with less-than-perfect vision (or a sunny day) had a chance.

The fastest way to check: any contrast checker tool, or the one built into Chrome DevTools — inspect a text element, click the color swatch in Styles, and the contrast ratio is right there with AA/AAA badges.

The formula, if you're curious

The math behind it is relative luminance:

function luminance(r, g, b) {
  const a = [r, g, b].map(v => {
    v /= 255;
    return v <= 0.03928 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4);
  });
  return a[0] * 0.2126 + a[1] * 0.7152 + a[2] * 0.0722;
}

function contrast(rgb1, rgb2) {
  const l1 = luminance(...rgb1);
  const l2 = luminance(...rgb2);
  return (Math.max(l1, l2) + 0.05) / (Math.min(l1, l2) + 0.05);
}

contrast([255, 255, 255], [17, 17, 17]); // ≈ 18.88

That's the exact formula Chrome, Lighthouse, and every checker uses. No magic.

The workflow fix

The real lesson wasn't "run a checker at the end" — it was choosing pairings up front. Now when I pick a palette, I decide immediately: which color is text, which is background, which are decoration-only. The vivid middle tones that fail contrast? They become borders, accents, and illustrations — never words.

A pattern that always works:

:root {
  --bg: /* your lightest color */;
  --text: /* your darkest color */;
  --accent: /* the vivid one — buttons, badges, never body text */;
}

If your lightest-on-darkest doesn't hit 4.5:1, the palette needs a darker dark or a lighter light. Adjust lightness, not hue — the palette keeps its character.

I ended up building this check into PaletteCSS, a free palette tool I work on — every palette page shows a WCAG contrast table for all color pairings, so you can see which combos are safe for text before you commit. No signup, if you want to sanity-check your current palette.

TL;DR

Body text needs 4.5:1 contrast minimum
Check in DevTools — it's built in
Assign roles when you pick colors: text, background, accent
Vivid mid-tones are for decoration, not words

Your design isn't done when it looks good. It's done when everyone can read it.

Color theory for developers who can't design

Avishek Dhimal — Sun, 28 Jun 2026 16:49:51 +0000

You can center a div, optimize a query, and ship a feature — but the moment you have to pick colors, you freeze. Same. Here's the small bit of color theory that gets you 90% of the way, no design degree required.

Rule #1: Start with ONE color

Don't pick five colors. Pick one you like — your accent/brand color — and build everything else around it. Say your accent is:

--color-accent: #6366f1; /* indigo */

Now generate the rest from it using the color wheel.

The 3 relationships you actually need

Complementary — the color directly opposite on the wheel. Maximum contrast. Use it sparingly for one highlight (a button, a badge).

#6366f1 → complement ≈ #f1c46a (warm gold)

Analogous — the colors right next to yours. Calm and cohesive. Great for backgrounds and gradients.

#6366f1 → #8b5cf6 and #5c8bf6

Triadic — two colors evenly spaced around the wheel. Vibrant but balanced.

#6366f1 → #f16366 and #66f163

Rule #2: Most of your UI is neutral

Beginners color everything. Pros use one accent + lots of neutrals:

--color-bg:     #f7f7f8; /* off-white, not pure white */
--color-text:   #1f2937; /* near-black, not pure black */
--color-muted:  #9ca3af;
--color-accent: #6366f1;

Pure black on pure white is harsh. Pull both back and everything instantly looks more intentional.

Rule #3: Check contrast before you ship

A palette can look great and still fail accessibility. Aim for a 4.5:1 contrast ratio for body text (WCAG AA). Test your text against your background — if it's borderline, darken the text.

The shortcut

If you'd rather not do the wheel math by hand, I built a free tool — PaletteCSS — that shows the complementary, analogous and matching colors for any base color and lets you copy them as CSS variables or Tailwind. But honestly, the three rules above get you most of the way.

What's your go-to for colors when there's no designer on the team? Drop it in the comments — always looking to steal good ones.

Building a "Mate-in-One" Chess Puzzle Solver from Scratch

Avishek Dhimal — Fri, 26 Jun 2026 04:19:12 +0000

Chess puzzles are incredibly addictive, but have you ever wondered how software instantly verifies if a move is a genuine checkmate?

While full chess engines like Stockfish look dozens of moves ahead using complex neural networks and alpha-beta pruning, writing an algorithm to detect a simple Mate-in-One is actually a fantastic, approachable exercise in graph theory and data modeling.

Here is a look at the exact step-by-step logic required to build a lightweight, fast mate-in-one puzzle detector.

1. Representing the Board: The FEN String

Before your code can calculate a move, it needs to understand the current state of the board. In computer chess, we use a standard string notation called FEN (Forsyth-Edwards Notation).

A typical FEN looks like this:
r1bqkbnr/pppp1ppp/2n5/4p3/4P3/5N2/PPPP1PPP/RNBQKB1R w KQkq - 1 3

This single string tells your program exactly where every piece is, whose turn it is (w or b), castling rights, and move counts. To parse this, our code converts the string into an 8x8 matrix (a 2D array) representing the squares.

2. Step 1: The "Candidate Move" Generator

To find a mate-in-one, your algorithm first needs to know every single legal move the attacking player can make right now.

The program iterates through the 8x8 grid, finds all pieces belonging to the current player, and calculates their theoretical movement paths based on traditional chess rules (e.g., Knights move in L-shapes, Rooks move in straight orthogonal lines).

function getCandidateMoves(board, activeColor) {
  let moves = [];
  // 1. Loop through all 64 squares
  // 2. Identify active pieces
  // 3. Generate potential target squares based on piece physics
  return moves;
}

Step 2: Filter for Genuine Checks

A move can only be a checkmate if it puts the opposing King in immediate danger.

For every candidate move generated in Step 1, our algorithm creates a virtual clone of the board and executes that move. On this cloned board, it checks if any of the attacking pieces now have a direct line of sight to capture the enemy King.

If the King is not in check after the move, the algorithm immediately throws that move out. It isn't our winning puzzle answer.

Step 3: The Ultimate Test (Eliminating Escapes)

This is where the magic happens. Just because the King is in check doesn't mean it's checkmate. It is only checkmate if the defending player has zero legal responses to escape the threat.

For every move that successfully delivers a check, our simulator switches sides to the defender and asks three questions:

Can the King move to an adjacent, safe square that is not under attack?
Can the threat be blocked by putting a defending piece in the path of the attacker?
Can the attacking piece be captured and removed from the board entirely?

function isCheckmate(virtualBoard, defendingColor) {
  // Generate ALL legal moves for the defender on this new board state
  const escapeMoves = getLegalMoves(virtualBoard, defendingColor);

  // If the defender has absolutely no moves left to escape the check...
  return escapeMoves.length === 0;
}

If the defender's legal move count drops to absolute zero while their King is actively under attack, your program has successfully discovered the Mate-in-One!

Keeping Complex Code Architectures Clean

When you build complex, algorithmic tools like chess analyzers or interactive calculators, managing your application's state and keeping your styling decoupled from your logic is half the battle.

If you're looking for a clean way to structure your design tokens without writing massive boilerplate CSS, I use a utility I built called PaletteCSS. It exports tailored palettes straight into clean CSS variables or Tailwind configs, so you can focus on writing clean, optimized JavaScript instead.

Have you ever built a game engine or puzzle logic from scratch? What was the hardest edge case you had to solve? Let's discuss in the comments!

Why your Tailwind build is bloated (And how to fix it in 3 steps)

Avishek Dhimal — Fri, 26 Jun 2026 04:09:50 +0000

Tailwind CSS is an absolute game-changer for speed, but if you aren't careful, you can end up shipping a massive utility stylesheet to your users.

If your production CSS file is clocking in at over a few dozen kilobytes, something is wrong with your configuration. Luckily, getting it back down to a lightning-fast size only takes a few adjustments. Here is exactly how to audit and fix a bloated Tailwind build.

1. Stop using dynamic class strings

The number one reason Tailwind builds balloon or completely miss classes in production is dynamic string interpolation.

Tailwind’s scanner looks for unbroken, complete strings in your source files. If it sees the full string, it keeps the utility. If you break it up, it skips it.

Don't do this:


javascript
// This will FAIL or cause issues because Tailwind doesn't compile code at runtime
const buttonColor = "indigo";
const classString = `bg-${buttonColor}-600`;

Do this instead:

// Write out the full class names so the static extractor can find them
const buttonColors = {
  primary: "bg-indigo-600 hover:bg-indigo-700",
  secondary: "bg-gray-600 hover:bg-gray-700"
};
If the static scanner can’t see the literal string bg-indigo-600, that class won't be included in your final CSS tree-shaking process.

2. Lock down your content array
Tailwind needs to know exactly which files to watch. If your tailwind.config.js file has an overly broad path, it will parse files it shouldn't, slowing down build times and picking up accidental strings as classes.

Check your configuration file:

JavaScript
module.exports = {
  content: [
    "./src/**/*.{html,js,ts,jsx,tsx,vue}",
    // Avoid tracking entire node_modules directories or backup folders!
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}
Make sure you are only targeting your actual source directory. Never point the scanner toward massive compiled build folders like /dist or /build.

3. Don't abuse @apply
The @apply directive is tempting when you want to "clean up" your HTML, but overusing it completely destroys the benefits of Tailwind's design system.

When you use utility classes in your HTML, the same bg-blue-500 class is reused across 100 components, adding zero bytes to your final CSS file. But when you use @apply in a CSS file:

CSS
/* This duplicates CSS declarations behind the scenes */
.btn-primary {
  @apply bg-blue-500 text-white font-bold py-2 px-4 rounded;
}
.card-action {
  @apply bg-blue-500 text-white font-bold py-2 px-4 rounded;
}
Tailwind is forced to generate duplicate raw CSS properties for every custom class name you create, heavily inflating your final bundle size. Stick to utility classes in your component markup whenever possible.

Streamlining your workflow
Keeping your utility workflow clean shouldn't mean copying and pasting raw configuration blocks over and over. If you want to jumpstart a clean architecture, I use a lightweight tool I built called [PaletteCSS](https://palettecss.com/) to quickly grab optimized, pre-formatted theme configurations for Tailwind, SCSS, or vanilla CSS variables without the boilerplate hassle.

What's your biggest pet peeve when working with utility-first CSS? Let's talk shop in the comments!

How to turn a color palette into clean CSS variables

Avishek Dhimal — Thu, 25 Jun 2026 06:40:16 +0000

Picking colors is the fun part. Wiring them into a codebase that stays
maintainable is where most palettes fall apart. Here's the approach I use.

1. Name colors by role, not value

Don't scatter hex codes everywhere:


css
.button { background: #6366f1; }
.link   { color: #6366f1; }
Define them once as custom properties, referenced by role:


:root {
  --color-bg:      #f7f7f8;
  --color-surface: #ffffff;
  --color-text:    #1f2937;
  --color-muted:   #9ca3af;
  --color-accent:  #6366f1;
}

.button { background: var(--color-accent); }
.link   { color: var(--color-accent); }
Now re-theming the whole app is a few edits in one place.

2. Skip pure black and pure white
#000 on #fff feels harsh on screens. Pull both back:


--color-text: #1f2937; /* near-black */
--color-bg:   #f7f7f8; /* off-white  */
Most layouts instantly look more intentional.

3. Dark mode is almost free
Because the colors are role-based variables, you just override the values:


@media (prefers-color-scheme: dark) {
  :root {
    --color-bg:      #0f1115;
    --color-surface: #1a1d24;
    --color-text:    #e5e7eb;
  }
}
Every component using var(--color-bg) adapts automatically.

A shortcut
I got tired of hand-converting palettes into this, so I built a free tool,
PaletteCSS, that copies any palette straight out as
CSS variables, Tailwind or SCSS — and has a color palette generator
if you need a starting point. But honestly, the three rules above matter more
than any tool.

What conventions do you use to keep a color system maintainable?
PaletteCSS — a free tool to discover, create and share color palettes and CSS
gradients. Copy any palette as hex, CSS variables, Tailwind or SCSS. No signup.
https://palettecss.com**

Stop guessing colors: a faster way to add palettes to your CSS

Avishek Dhimal — Mon, 15 Jun 2026 15:15:11 +0000

Every time I start a new project, the same thing happens. I get the layout working, then I completely freeze on colors. I grab a color, drop it in, squint at it, change it, and half an hour later I've got something that's... fine. Maybe.

If that sounds like you, here's what finally fixed it for me.

Stop inventing colors from scratch

For years my mistake was trying to come up with a color scheme on my own — picking one color, then guessing what goes with it. It almost never looked right, and it ate up so much time.

The fix was simple: start from a palette that already works, then tweak it. When you begin with colors that are proven to look good together, everything after that is easy.

Where I get my palettes now

These days I grab them from PaletteCSS: https://palettecss.com

It's a free library of thousands of hand-picked color palettes (and CSS gradients) for websites. You can browse by color, mood, theme, or industry, find one you like, and copy the CSS or hex codes in one click. No signup, no clutter. I find a palette, paste it into my project, and the part that used to eat my whole afternoon is done in a minute.

It also has a gradients section, which is great when you want a background that already looks balanced instead of fiddling with one yourself.

The takeaway

If colors are the scary part of your projects, stop guessing:

Start from a ready-made palette instead of inventing one.
Reuse the same colors consistently across your site.
Lean on tools so you spend your time building, not second-guessing hex codes.

That one change made design the easy part instead of the stressful part.

Full disclosure: I built PaletteCSS to solve this exact problem for myself. I'd genuinely love feedback from this community — what would make it more useful for your projects? Drop a comment below. 🙏