DEV Community: Muhammad Afsar Khan

Zero CLS, APCA Contrast, and AI Font Pairing: Building a Professional Font Comparison Tool.

Muhammad Afsar Khan — Tue, 17 Mar 2026 12:46:43 +0000

When it comes to web performance and accessibility, typography is often an afterthought. We pick nice fonts, maybe check contrast with a browser extension, and call it a day. But modern web development demands more.

I recently built a professional font comparison tool that tackles three of the toughest challenges in web typography:

1.Eliminating CLS with font metric overrides

2.Implementing APCA contrast for WCAG 3 readiness

AI-powered font pairing based on morphological characteristics

Let me walk you through the technical implementation.

Part 1: Zero CLS with Font Metric Overrides
Cumulative Layout Shift (CLS) occurs when a web font loads and swaps with the system fallback, changing the size of text elements. The fix? Use size-adjust, ascent-override, and descent-override in your @font-face rules.

The Challenge: Every font requires different override values. Inter needs different adjustments than Roboto.

The Solution: Build a database of fallback metrics.

const SYSTEM_FALLBACKS = {
  'Inter': {
    fallbacks: ['system-ui', '-apple-system', 'Segoe UI', 'sans-serif'],
    sizeAdjust: '102.5%',
    ascentOverride: '92%',
    descentOverride: '22%',
    lineGapOverride: '0%'
  },
  'Roboto': {
    fallbacks: ['system-ui', 'Segoe UI', 'Arial', 'sans-serif'],
    sizeAdjust: '101.2%',
    ascentOverride: '94%',
    descentOverride: '24%',
    lineGapOverride: '0%'
  }
  // ... 20+ more fonts with AI-matched metrics
};

CLS Ghosting Visualization: To help users understand the impact, I added a "ghost layer" that shows where the fallback font would render:

function showGhostLayers() {
  // Clone the preview text styles
  const styles = window.getComputedStyle(previewText);
  ghostDiv.style.fontSize = styles.fontSize;
  ghostDiv.style.fontWeight = styles.fontWeight;

  // Apply fallback font
  ghostDiv.style.fontFamily = fallbackFont;

  // Calculate shift percentage
  const shift = Math.abs(parseFloat(sizeAdjust) - 100);
  showToast(`CLS Impact: ${shift.toFixed(1)}%`);
}

When activated, users see exactly how much the text would shift—visual feedback that drives home the importance of proper fallbacks.

Part 2: Implementing APCA Contrast
WCAG 2.1 contrast ratios are simple but flawed. They don't account for font weight, spatial frequency, or perceptual brightness. APCA (Accessible Perceptual Contrast Algorithm) fixes this.

The APCA Calculation:

function getAPCAcontrast(textColor, bgColor) {
  // Convert to linear RGB
  const yText = sRGBtoY(rgbText);
  const yBg = sRGBtoY(rgbBg);

  // Determine which is lighter
  const textIsLighter = yText > yBg;
  const yHigh = Math.max(yText, yBg);
  const yLow = Math.min(yText, yBg);

  // APCA formula (simplified)
  let contrast;
  if (textIsLighter) {
    contrast = (yHigh ** 0.56 - yLow ** 0.57) * 1.14 * 100;
  } else {
    contrast = (yHigh ** 0.65 - yLow ** 0.62) * 1.24 * 100;
  }

  return Math.round(contrast * 10) / 10;
}

Performance Optimization: APCA calculations can be expensive, especially when updating in real-time. I used a Web Worker to offload the work:

// Worker thread
self.onmessage = function(e) {
  const { textColor, bgColor, side } = e.data;
  const lc = calculateAPCA(textColor, bgColor);
  self.postMessage({ lc, side });
};

// Main thread
apcaWorker.onmessage = function(e) {
  updateWcagIndicatorsWithLC(e.data.side, e.data.lc);
};

Part 3: AI Morphology Pairing
Font pairing is part art, part science. I wanted to build an algorithm that could suggest pairings based on morphological characteristics:

function smartMorphologyPair(sourcePanel) {
  const sourceFont = getSelectedFont(sourcePanel);
  const sourceChars = getFontCharacteristics(sourceFont);

  let bestMatch = null;
  let bestScore = -1;

  // Score potential matches
  options.forEach(opt => {
    const targetChars = getFontCharacteristics(opt.value);
    let score = 0;

    // Contrasting families often work well
    if (targetChars.familyType !== sourceChars.familyType) score += 35;

    // Matching x-heights creates harmony
    if (targetChars.xHeight === sourceChars.xHeight) score += 25;

    // Similar style adds safety
    if (targetChars.style === sourceChars.style) score += 15;

    if (score > bestScore) {
      bestScore = score;
      bestMatch = opt.value;
    }
  });

  return { font: bestMatch, score: bestScore };
}

This creates pairings like:

Playfair Display (serif) → Source Sans Pro (sans-serif) — 35 points for contrast

Montserrat (geometric) → Open Sans (humanist) — complementary styles

Part 4: Lazy Loading 1000+ Fonts
Displaying every Google Font would crash the browser. The solution? Lazy loading with an Intersection Observer:

function setupLazyLoadingForSelect(selectId) {
  const select = document.getElementById(selectId);

  select.addEventListener('scroll', function() {
    // Check if near bottom
    const scrollPosition = this.scrollTop + this.clientHeight;
    const scrollThreshold = this.scrollHeight - 30;

    if (scrollPosition >= scrollThreshold) {
      loadMoreFonts(this);
    }
  });
}

function loadMoreFonts(select) {
  // Show loading indicator
  // Fetch next batch of 50 fonts
  // Append to select options
  // Update lazy loading index
}

Part 5: The Production Bundle Generator
The final piece: generating production-ready CSS that combines everything:

function generateProductionBundle() {
  const leftFont = getLeftFont();
  const rightFont = getRightFont();
  const leftFallback = FALLBACKS[leftFont];
  const rightFallback = FALLBACKS[rightFont];

  return `
/* Google Fonts Import */
@import url('https://fonts.googleapis.com/css2?family=${leftFont}&display=swap');

/* Zero-CLS Fallbacks */
@font-face {
  font-family: '${leftFont} Fallback';
  src: local('${leftFallback.fallbacks[0]}');
  size-adjust: ${leftFallback.sizeAdjust};
  ascent-override: ${leftFallback.ascentOverride};
  descent-override: ${leftFallback.descentOverride};
}

/* Font Stacks */
:root {
  --font-heading: '${leftFont}', '${leftFont} Fallback', ${leftFallback.fallbacks.join(', ')};
  --font-body: '${rightFont}', ${rightFallback.fallbacks.join(', ')};
}
  `;
}

The Result
The tool now helps developers:

Eliminate CLS with one-click fallback generation

Meet APCA contrast standards (future-proofing for WCAG 3)

Find perfect font pairings using AI

Test fonts in a live sandbox with real HTML/CSS

If you're building a typography tool or just want to understand these concepts better, the full source approach is available in the tool. Check it out and let me know what you'd add!

Explore the Pro Font Lab → FontPreview

Mastering Web Typography: Building a Real-Time Font Preview Tool with the Local Font Access API.

Muhammad Afsar Khan — Fri, 13 Mar 2026 16:33:23 +0000

We all know the struggle of choosing a font for a project. You have your design system in Figma, your VS Code open, and you're constantly switching back and forth to see if "Inter" really looks better than "Roboto" at 16px. Wouldn't it be great to just... preview them live, in the browser, alongside your actual content?

In this post, I want to break down the core technical challenges I faced while building FontPreview.online and share the solutions that made it fast, accurate, and developer-friendly.

The Core Challenge: A Million Fonts, One Page
The first hurdle was loading and displaying over 1,000 Google Fonts without crashing the browser. The naive approach-loading every single font stylesheet at once-is a performance nightmare.

The Solution: Lazy Loading with an Intersection Observer.
We load the base UI, but the actual font files are only fetched when a card is about to scroll into view.

// Simplified lazy loading setup
const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const card = entry.target;
      loadGoogleFont(card.dataset.fontFamily); // Dynamically create <link> tag
      observer.unobserve(card);
    }
  });
}, { rootMargin: '100px' }); // Start loading 100px before it enters

document.querySelectorAll('.font-card').forEach(card => observer.observe(card));

This "just-in-time" loading keeps the initial page weight low and the interaction smooth.

Leveling Up with the Local Font Access API
This was a game-changer. The window.queryLocalFonts() method allows us to ask a user for permission to read their locally installed fonts. No more guessing if "SF Mono" or "Helvetica Neue" is available!

The Permission Flow is Critical.
You can't just call the function. You need to handle the user's decision gracefully.

Check Support: if ('queryLocalFonts' in window) { ... }

Request and Handle Errors: The call prompts the user. We must handle the NotAllowedError if they deny it, and guide them on how to re-enable it if they change their mind.

De-duplication: The API returns every font variation (e.g., "Arial Bold", "Arial Italic"). We had to map and clean these to present a simple list of unique font families.

This feature is a huge win for developers who want to see exactly how their text will render on a target OS.

Real-Time Accessibility (a11y) is Non-Negotiable
A design tool is useless if it doesn't help you build for everyone. We integrated two levels of contrast checking:

WCAG Ratio: The standard (L1 + 0.05) / (L2 + 0.05) formula.

APCA (Accessible Perceptual Contrast Algorithm): This is the future (WCAG 3). It's more nuanced than the simple ratio, taking font weight and size into account. Implementing this was a deep dive into color science, but it provides a much more accurate prediction of readability.

The Stack and Key Takeaways
Vanilla JavaScript: Keeps it lightweight and fast for a core utility tool.

CSS Grid: Made the responsive card layout trivial.

LocalStorage: For persisting user preferences like pinned fonts and recent searches without a backend.

Building a tool like this is a fantastic way to deepen your understanding of the modern web platform. You'll touch on performance APIs, cutting-edge browser features, and the nuanced world of accessibility.

Check out the source code structure on the live site, and if you're working on a typography project, give the tool a spin!

typography

Muhammad Afsar Khan — Fri, 27 Feb 2026 18:04:10 +0000

How I Curated 100+ Google Font Pairings & Built a Live Preview Tool....

Muhammad Afsar Khan — Mon, 23 Feb 2026 17:28:55 +0000

Here's the thing: I'm terrible at picking fonts.

Every time I started a project, I'd spend hours scrolling through Google Fonts, opening 20 tabs, trying to decide if Montserrat goes with Open Sans or if I should just give up and use Arial again.
I knew I wasn't alone. Every designer I talked to had the same problem.
So I built something simple: a page with 100+ font combinations that actually work, where you can type your own text and see it instantly.

The Problem With Every Other Font Site

Most font pairing websites show you pretty pictures of "Sample Text" with some made-up headline. But when I paste in my actual content — my product name, my blog title — it never looks as good.
I wanted to see my words, in those fonts, right now.

How I Built It

I started by just listing out font pairs I actually use. Playfair Display + Lato for blog posts. Inter + Roboto for dashboards. The classics that never fail.
Then I turned that list into JavaScript:

javascript
const pairings = [
  {
    heading: 'Playfair Display',
    body: 'Lato',
    style: 'classic',
    tags: ['serif', 'editorial'],
    description: 'Great for blogs and articles'
  },
  {
    heading: 'Inter',
    body: 'Roboto',
    style: 'modern',
    tags: ['ui', 'clean'],
    description: 'Perfect for web apps'
  }
];

The Magic Part: Live Preview

The key feature is letting you type your own words. Here's how that works:

// When someone types in the box
customTextInput.addEventListener('input', (e) => {
  customText = e.target.value || 'Visual Harmony';
  showAllPairings(); // Update everything
});

// Then each card shows their text
function showAllPairings() {
  pairings.forEach(pair => {
    // Display their text in the heading font
    // Display description in the body font
  });
}

Every time you type, all 100+ cards update. It's surprisingly fast.

Making It Useful for Developers

The thing I wanted most was to copy-paste CSS quickly. So I added a button:

function copyCSS(heading, body) {
  const css = `/* Use these in your project */
h1, h2, h3 {
  font-family: '${heading}';
}

p {
  font-family: '${body}';
}`;

  navigator.clipboard.writeText(css);
  alert('Copied! Ready to paste into your CSS');
}

One click, and you're done.

Keeping It Fast

With 100+ cards, the page could get slow. So I only load 12 at first, then add more when you click "Load More":

let visibleCount = 12;

function loadMore() {
  visibleCount = visibleCount + 12;
  showPairings(); // Show the next batch
}

Simple but works.

What I Learned

People actually use the custom text box — like, a lot. Everyone wants to see their own words.
Categories help more than search — "Show me modern fonts" is easier than typing keywords.
Copy buttons get clicked — developers hate typing font names manually.

Try It Yourself

The whole thing is free, no signup needed: fontpreview.online/pairings
You can:

Test 100+ combinations with your text
Filter by style (modern, classic, elegant)
Copy CSS instantly
Preview on desktop and mobile

What's Next?

I'm working on:

Variable font pairings (experiment with weight axes)
Dark mode preview (see how pairs look on dark backgrounds)

- Export as PDF (for client presentations)

Built with vanilla JS, Google Fonts API, and a lot of caffeine. Free forever, no signup required.

How I Built a Side-by-Side Font Comparison Tool (And Accidentally Learned Way Too Much About Browser APIs)

Muhammad Afsar Khan — Thu, 19 Feb 2026 09:24:29 +0000

I wanted to let people compare system fonts with Google Fonts.

Sounds simple, right?

It was not simple.

But after a lot of trial, error, and yelling at my browser console, I got it working. Here's how it works — including the parts that almost made me give up.

The Idea

I built FontPreview because I was tired of guessing how fonts would look with real text. But the thing designers kept asking was: "Can I compare this Google Font with the font already on my computer?"

Turns out, that's harder than it sounds.

Browsers don't really want you poking around someone's system fonts. For good reason — imagine every website you visit getting a list of everything installed on your computer. That's a privacy nightmare.

But there's a newer API that lets you do this, if the user says it's okay.

The Local Font Access API

There's this thing called the Local Font Access API. It's relatively new, and not every browser supports it yet (looking at you, Safari). But in Chrome and Edge, you can do this: javascript

const fonts = await window.queryLocalFonts();

That one line of code returns an array of every font installed on the user's system.

Except — and this is important — the browser will ask the user for permission first. A little popup shows up saying "This site wants to see your fonts." If the user says no, you get nothing.

This is good. We don't want random sites scraping font lists without permission.

The Permission Dance

Here's how I handle it: javascript

function checkSystemFontsPermission() {
  if (!window.queryLocalFonts) {
    showToast('Local Font Access API not supported in this browser');
    useFallbackFonts();
    return;
  }

  // Show the permission modal
  document.getElementById('permissionModal').style.display = 'flex';
}

If the browser doesn't support the API, I fall back to a list of popular system fonts. Not perfect, but better than nothing.

If it does support it, I show a little modal explaining why I'm asking and what I'll do with the data. (Spoiler: nothing. I just show them in a dropdown.)

What Happens When They Say Yes

When the user clicks "Allow", this runs: javascript

async function requestFontPermission() {
  try {
    const fonts = await window.queryLocalFonts();

    // Clean up font names (remove "Regular", "Bold", etc.)
    const fontMap = new Map();

    fonts.forEach(f => {
      let name = f.family;
      const suffixes = [' Regular', ' Bold', ' Italic', ' Light', ' Medium'];

      suffixes.forEach(suffix => {
        if (name.endsWith(suffix)) {
          name = name.substring(0, name.length - suffix.length);
        }
      });

      if (!fontMap.has(name)) {
        fontMap.set(name, {
          family: name,
          fullName: f.family,
          style: f.style,
          weight: f.weight
        });
      }
    });

    // Sort and store
    allSystemFonts = Array.from(fontMap.values()).sort((a, b) => 
      a.family.localeCompare(b.family)
    );

    showToast(`Loaded ${allSystemFonts.length} system fonts`);

  } catch (error) {
    if (error.name === 'NotAllowedError') {
      showToast('Permission denied. Using fallback fonts.');
    } else {
      showToast('Error loading fonts. Using fallback.');
    }
    useFallbackFonts();
  }
}

The Map thing is important. A lot of fonts come back with multiple entries for different styles — "Arial Regular", "Arial Bold", "Arial Italic". I just want "Arial" once. The Map deduplicates them.

The Big Problem I Didn't Expect

Once I had the font list, I needed to actually use those fonts in the preview.

In CSS, you can just do:

font-family: 'Arial', sans-serif;

And if the user has Arial installed, it works. Great.

But here's the thing — I also wanted to let users compare system fonts with Google Fonts side by side. So if someone picks Arial on the left and Roboto on the right, I need to load Roboto from Google Fonts.

That means dynamically injecting a tag: javascript

function loadGoogleFontForPanel(fontName, panel) {
  const fontFamily = fontName.replace(/ /g, '+');

  const linkId = `panel-font-${panel}`;
  const oldLink = document.getElementById(linkId);
  if (oldLink) oldLink.remove();

  const link = document.createElement('link');
  link.id = linkId;
  link.rel = 'stylesheet';
  link.href = `https://fonts.googleapis.com/css2?family=${fontFamily}&display=swap`;

  document.head.appendChild(link);
}

This way, each panel can load its own font independently. Left panel can load a system font (which doesn't need a stylesheet), right panel can load a Google Font (which does).

The Part That Still Bugs Me

When you load a Google Font dynamically, there's a tiny delay before it's available. During that moment, the text shows up in the default font, then swaps to the chosen font.

It's a flash of unstyled text. FOIT, if you want the fancy term.

I tried a bunch of fixes. Preloading, font-display: swap, even hiding the text until the font loads. Everything felt janky.

Eventually I just left it. The flash is brief, and most users don't notice. But I notice. Every time.

What I'd Do Differently

If I built this again from scratch:

Cache the permission status. Right now, the modal shows every time you click "System". That's annoying. I should store their choice in localStorage.
Better error handling. Sometimes the API just... fails. No error, no nothing. The code just stops. I need to catch that better.
Fallback for Safari. Safari doesn't support this API at all. I should build a real fallback instead of just a list of popular fonts.

The Code (If You Want It)

The whole thing is on FontPreview if you want to see it in action. View source — it's all client-side, no backend, no tracking, just HTML, CSS, and JavaScript.

I'm not a great developer. I learned most of this by breaking things and Googling errors. But it works, and people use it, and that's enough for me.

If you're building something with the Local Font Access API, hit me up. I've probably already hit the same bugs you're hitting.

Originally published on dev.to. Try the tool here: FontPreview

Tags: javascript, webdev, tutorial, showdev, api

How I Built a WCAG Contrast Checker in 50 Lines of JavaScript.

Muhammad Afsar Khan — Thu, 19 Feb 2026 08:56:21 +0000

I used to do something really dumb.

When I was picking colors for a website, I'd zoom in, squint, and ask myself: "Is this readable? Yeah, probably."

Then I'd ship it.

A few months ago, a user emailed me. He had low vision and couldn't read light gray text on one of my sites. He wasn't angry — just disappointed. Said he wanted to read my content but couldn't.

That email is still in my inbox.

So when I built FontPreview, I decided I wasn't going to guess anymore. I built a contrast checker right into the tool. Turns out it only took about 50 lines of JavaScript.

Here's exactly how it works.

The Math (It's Not as Scary as It Looks)
WCAG contrast ratio is calculated with this formula:
(L1 + 0.05) / (L2 + 0.05)
Where L1 is the relative luminance of the lighter color, and L2 is the relative luminance of the darker color.

But "relative luminance" sounds like something from a math textbook. Here's what it actually looks like in JavaScript:
function luminance(r, g, b) { let 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; }

I didn't invent this formula — it's straight from the WCAG spec. I just typed it into my editor and hoped it worked. (It did. Eventually.)

Converting Hex to RGB
First step: turn those hex codes (#1e1e1e, #E8E8E8) into something we can do math with.
[function hexToRgb(hex) {
const result = /^#?([a-f\d]{2})([a-f\d]{2})([a-f\d]{2})$/i.exec(hex);
return result ? {
r: parseInt(result[1], 16),
g: parseInt(result[2], 16),
b: parseInt(result3], 16)
} : null;
}

Regex looks scary, but it's just pulling out the red, green, and blue values from that hex string.

Putting It All Together
Once we have RGB values, we can calculate the contrast ratio between two colors:

function contrastRatio(hex1, hex2) {
  const rgb1 = hexToRgb(hex1);
  const rgb2 = hexToRgb(hex2);

  if (!rgb1 || !rgb2) return 1;

  const l1 = luminance(rgb1.r, rgb1.g, rgb1.b);
  const l2 = luminance(rgb2.r, rgb2.g, rgb2.b);

  const lighter = Math.max(l1, l2);
  const darker = Math.min(l1, l2);

  return (lighter + 0.05) / (darker + 0.05);
}

That's it. That's the whole thing.

What's a "Good" Ratio?
WCAG defines three levels:

AAA: 7:1 or higher (the gold standard)

AA: 4.5:1 or higher (what most sites should aim for)

AA Large: 3:1 for text that's at least 24px or 19px bold

Here's how I check that in code:

function getWcagLevel(ratio, fontSize, isBold) {
  const size = parseFloat(fontSize);
  const isLarge = size >= 18.66 || (size >= 14 && isBold);

  if (ratio >= 7) return { level: 'AAA', class: 'aaa' };
  if (ratio >= 4.5) return { level: 'AA', class: 'pass' };
  if (ratio >= 3 && isLarge) return { level: 'AA Large', class: 'aa-large' };
  return { level: 'FAIL', class: 'fail' };
}

The 18.66 and 14 numbers come from the WCAG spec — 18.66px is about 14pt at 1.333x scaling. I don't think about it too hard. I just copy the numbers and move on.

The Part That Surprised Me
I thought the math would be the hard part. It wasn't.

The hard part was realizing how many of my old designs would have failed these checks. That light gray text I thought looked "clean" and "minimal"? FAIL. That low-contrast button I was proud of? FAIL.

The email from that user makes more sense now.

You Can Try It Yourself
I built this into FontPreview. Pick any two colors, type some text, and the badge updates instantly. No math required.

If you're a developer, steal this code. Use it in your own projects. That's why I'm sharing it.

One More Thing
The 50 lines of code in this post are fine. They work. But they're not the important part.

The important part is that I stopped guessing.

If you're still checking colors by squinting at your screen, just know that someone out there — maybe someone like the guy who emailed me — is trying to read your work and can't.

Fifty lines of code is a small price to pay for making sure they can.

Try the contrast checker yourself: FontPreview

How I Built a WCAG Contrast Checker in 50 Lines of JavaScript.

Muhammad Afsar Khan — Wed, 18 Feb 2026 11:38:33 +0000

I used to do something really dumb.

When I was picking colors for a website, I'd zoom in, squint, and ask myself: "Is this readable? Yeah, probably."

Then I'd ship it.

A few months ago, a user emailed me. He had low vision and couldn't read light gray text on one of my sites. He wasn't angry — just disappointed. Said he wanted to read my content but couldn't.

That email is still in my inbox.

So when I built FontPreview, I decided I wasn't going to guess anymore. I built a contrast checker right into the tool. Turns out it only took about 50 lines of JavaScript.

Here's exactly how it works.

But "relative luminance" sounds like something from a math textbook. Here's what it actually looks like in JavaScript.

javascript
function luminance(r, g, b) {
  let 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;
}

I didn't invent this formula — it's straight from the WCAG spec. I just typed it into my editor and hoped it worked. (It did. Eventually.)

Converting Hex to RGB
First step: turn those hex codes (#1e1e1e, #E8E8E8) into something we can do math with.

javascript
function hexToRgb(hex) {
  const result = /^#?([a-f\d]{2})([a-f\d]{2})([a-f\d]{2})$/i.exec(hex);
  return result ? {
    r: parseInt(result[1], 16),
    g: parseInt(result[2], 16),
    b: parseInt(result[3], 16)
  } : null;
}

Regex looks scary, but it's just pulling out the red, green, and blue values from that hex string.

Putting It All Together
Once we have RGB values, we can calculate the contrast ratio between two colors:

javascript
function contrastRatio(hex1, hex2) {
  const rgb1 = hexToRgb(hex1);
  const rgb2 = hexToRgb(hex2);

  if (!rgb1 || !rgb2) return 1;

  const l1 = luminance(rgb1.r, rgb1.g, rgb1.b);
  const l2 = luminance(rgb2.r, rgb2.g, rgb2.b);

  const lighter = Math.max(l1, l2);
  const darker = Math.min(l1, l2);

  return (lighter + 0.05) / (darker + 0.05);
}

That's it. That's the whole thing.

What's a "Good" Ratio?
WCAG defines three levels:

AAA: 7:1 or higher (the gold standard)

AA: 4.5:1 or higher (what most sites should aim for)

AA Large: 3:1 for text that's at least 24px or 19px bold

Here's how I check that in code:

javascript
function getWcagLevel(ratio, fontSize, isBold) {
  const size = parseFloat(fontSize);
  const isLarge = size >= 18.66 || (size >= 14 && isBold);

  if (ratio >= 7) return { level: 'AAA', class: 'aaa' };
  if (ratio >= 4.5) return { level: 'AA', class: 'pass' };
  if (ratio >= 3 && isLarge) return { level: 'AA Large', class: 'aa-large' };
  return { level: 'FAIL', class: 'fail' };
}

The 18.66 and 14 numbers come from the WCAG spec — 18.66px is about 14pt at 1.333x scaling. I don't think about it too hard. I just copy the numbers and move on.

The Part That Surprised Me
I thought the math would be the hard part. It wasn't.

The email from that user makes more sense now.

You Can Try It Yourself
I built this into FontPreview. Pick any two colors, type some text, and the badge updates instantly. No math required.

If you're a developer, steal this code. Use it in your own projects. That's why I'm sharing it.

One More Thing
The 50 lines of code in this post are fine. They work. But they're not the important part.

The important part is that I stopped guessing.

If you're still checking colors by squinting at your screen, just know that someone out there — maybe someone like the guy who emailed me — is trying to read your work and can't.

Fifty lines of code is a small price to pay for making sure they can.

Try the contrast checker yourself: FontPreview

How I Built a WCAG Contrast Checker in 50 Lines of JavaScript.

Muhammad Afsar Khan — Wed, 18 Feb 2026 11:38:33 +0000

I used to do something really dumb.

When I was picking colors for a website, I'd zoom in, squint, and ask myself: "Is this readable? Yeah, probably."

Then I'd ship it.

A few months ago, a user emailed me. He had low vision and couldn't read light gray text on one of my sites. He wasn't angry — just disappointed. Said he wanted to read my content but couldn't.

That email is still in my inbox.

So when I built FontPreview, I decided I wasn't going to guess anymore. I built a contrast checker right into the tool. Turns out it only took about 50 lines of JavaScript.

Here's exactly how it works.

But "relative luminance" sounds like something from a math textbook. Here's what it actually looks like in JavaScript.

javascript
function luminance(r, g, b) {
  let 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;
}

I didn't invent this formula — it's straight from the WCAG spec. I just typed it into my editor and hoped it worked. (It did. Eventually.)

Converting Hex to RGB
First step: turn those hex codes (#1e1e1e, #E8E8E8) into something we can do math with.

javascript
function hexToRgb(hex) {
  const result = /^#?([a-f\d]{2})([a-f\d]{2})([a-f\d]{2})$/i.exec(hex);
  return result ? {
    r: parseInt(result[1], 16),
    g: parseInt(result[2], 16),
    b: parseInt(result[3], 16)
  } : null;
}

Regex looks scary, but it's just pulling out the red, green, and blue values from that hex string.

Putting It All Together
Once we have RGB values, we can calculate the contrast ratio between two colors:

javascript
function contrastRatio(hex1, hex2) {
  const rgb1 = hexToRgb(hex1);
  const rgb2 = hexToRgb(hex2);

  if (!rgb1 || !rgb2) return 1;

  const l1 = luminance(rgb1.r, rgb1.g, rgb1.b);
  const l2 = luminance(rgb2.r, rgb2.g, rgb2.b);

  const lighter = Math.max(l1, l2);
  const darker = Math.min(l1, l2);

  return (lighter + 0.05) / (darker + 0.05);
}

That's it. That's the whole thing.

What's a "Good" Ratio?
WCAG defines three levels:

AAA: 7:1 or higher (the gold standard)

AA: 4.5:1 or higher (what most sites should aim for)

AA Large: 3:1 for text that's at least 24px or 19px bold

Here's how I check that in code:

javascript
function getWcagLevel(ratio, fontSize, isBold) {
  const size = parseFloat(fontSize);
  const isLarge = size >= 18.66 || (size >= 14 && isBold);

  if (ratio >= 7) return { level: 'AAA', class: 'aaa' };
  if (ratio >= 4.5) return { level: 'AA', class: 'pass' };
  if (ratio >= 3 && isLarge) return { level: 'AA Large', class: 'aa-large' };
  return { level: 'FAIL', class: 'fail' };
}

The 18.66 and 14 numbers come from the WCAG spec — 18.66px is about 14pt at 1.333x scaling. I don't think about it too hard. I just copy the numbers and move on.

The Part That Surprised Me
I thought the math would be the hard part. It wasn't.

The email from that user makes more sense now.

You Can Try It Yourself
I built this into FontPreview. Pick any two colors, type some text, and the badge updates instantly. No math required.

If you're a developer, steal this code. Use it in your own projects. That's why I'm sharing it.

One More Thing
The 50 lines of code in this post are fine. They work. But they're not the important part.

The important part is that I stopped guessing.

If you're still checking colors by squinting at your screen, just know that someone out there — maybe someone like the guy who emailed me — is trying to read your work and can't.

Fifty lines of code is a small price to pay for making sure they can.

Try the contrast checker yourself: FontPreview

How I Reduced Font Load Time by 70% Using Variable Fonts.

Muhammad Afsar Khan — Sun, 15 Feb 2026 10:55:27 +0000

Originally published on FontPreview

I used to think typography was just about aesthetics. Pick a nice font, pair it with another nice font, ship it.

Then I launched a client site that looked perfect on my fiber-optic connection — but on a real 4G network, the text area stayed blank for 2.7 seconds. The client's bounce rate doubled.

That's when I stopped treating fonts as "design assets" and started treating them as what they really are: render-blocking resources.

The Problem: 6 Font Files, 380kb

Here's what I did for years: when I needed a font for a project, I'd load the entire family. Roboto? Give me Thin, Light, Regular, Medium, Bold, Black. "Just in case."

The result: 380kb of font files for text that only ever used Regular and Bold.

The Solution: One Variable Font, 112kb

Variable fonts changed everything. One file contains all the variations — weight from 100 to 900, width from condensed to extended, slant from upright to italic.

The math:

6 static files → 380kb
1 variable file → 112kb
70% reduction in font payload

The Results (Real Numbers)

Project	Before	After	Improvement
Blog	412kb	118kb	71%
Corporate site	384kb	112kb	70%
E-commerce	520kb	156kb	70%

Average First Contentful Paint improvement: 0.8 seconds faster on 4G

When NOT to Use Variable Fonts

Here's the part nobody tells you: variable fonts aren't always better.

If you only need 1-2 weights, static fonts might be smaller:

2 static weights: ~84kb
1 variable font: ~112kb

Use variable fonts when:

You need 3+ weights
You want fine control (weight 450, 560, etc.)
You need multiple axes (width, slant)
Performance is critical (one request vs multiple)

My Go-To Variable Fonts

Font	Size	Best For
Inter	112kb	Most projects
Roboto Flex	487kb	When you need everything
Merriweather Sans	98kb	Content sites, blogs
Fraunces	124kb	Brands with personality

Performance Checklist

[ ] Count your weights – Do you really need all 9?
[ ] Check variable file size – Compare with static alternatives
[ ] Use font-display: swap – Never hide text
[ ] Preload one font – Only the one above the fold
[ ] Test on 3G – If it loads in 2 seconds, you're good

I still don't use variable fonts for every project. Sometimes two static weights really are the right answer. But now I check. I open FontPreview, see the file size, count the weights I actually need, and make a real decision instead of just guessing.

Try it yourself: FontPreview – free tool to test variable fonts with your own text