DEV Community: 8Bit Enterprise

Stop Guessing Text Colors. Chrome DevTools Can Pick an Accessible One for You

Hannan Shoukat — Wed, 11 Nov 2026 21:07:08 +0000

Light grey text on white looks clean in a design file. It's also one of the most common accessibility failures on the web, and it's easy to miss because it looks fine on your own bright screen.

Here's the thing: you don't need to guess a darker shade. Chrome DevTools will measure the contrast and suggest a color that passes.

The numbers you're aiming for

WCAG, the standard most accessibility checks use, measures contrast as a ratio between text color and background. WCAG's contrast guidance sets these levels:

Level	Normal text	Large text
AA (the usual target)	4.5:1	3:1
AAA (enhanced)	7:1	4.5:1

To make this concrete, I calculated a few common greys on a white background:

Text color on #FFFFFF	Ratio	Result
`#9e9e9e`	2.68:1	Fails
`#767676`	4.54:1	Passes AA
`#595959`	7.00:1	Passes AAA

That #9e9e9e is a very popular "subtle" grey. It fails.

Fixing it in DevTools

These steps follow Chrome's contrast documentation:

Inspect the text. Right-click it and choose Inspect. Hovering the element in inspect mode shows its contrast ratio in the tooltip, with a warning sign if it's too low.
Open the Color Picker. In the Styles pane, click the small color swatch next to the element's color value.
Expand "Contrast ratio." The picker shows the current ratio and whether it meets AA or AAA.
Use the lines. The shade area shows two lines. Drag the circle below the top line to pass AA, or below the bottom line to pass AAA.
Or let DevTools choose. Click Use suggested color next to the AAA level, and DevTools applies a text color that passes.

Then copy the new value into your CSS. DevTools changes are only temporary.

What's new in this month's DevTools

Chrome's November 2026 DevTools update, covering Chrome 155 and 156, added two things to the color picker:

APCA suggestions for light text on dark backgrounds, which is exactly the case that trips up dark modes.
Converting out-of-gamut colors to oklab() and oklch() without producing NaN values.

APCA is a newer contrast method that accounts for how we actually perceive light and dark text differently. Older guides say you need to switch it on under Settings > Experiments, while newer ones show it by default. If your picker shows only AA and AAA, check Experiments in your version.

Dark mode needs its own check

Contrast doesn't carry over automatically when you flip themes. Here's the same idea on a common dark background:

Text color on #121212	Ratio	Result
`#6b6b6b`	3.52:1	Fails for normal text
`#949494`	6.18:1	Passes AA
`#b8b8b8`	9.44:1	Passes AAA

Run the DevTools check in both themes. It takes a minute, and dark modes are where low-contrast text hides most often.

Bonus: check contrast in code

If you generate colors or build a design system, you can test contrast automatically. This is the WCAG formula in a few lines:

function luminance(hex) {
  const [r, g, b] = hex.replace('#', '').match(/../g)
    .map(x => parseInt(x, 16) / 255)
    .map(c => c <= 0.04045 ? c / 12.92 : ((c + 0.055) / 1.055) ** 2.4);
  return 0.2126 * r + 0.7152 * g + 0.0722 * b;
}

function contrast(fg, bg) {
  const [a, b] = [luminance(fg), luminance(bg)].sort((x, y) => y - x);
  return (a + 0.05) / (b + 0.05);
}

contrast('#9e9e9e', '#ffffff').toFixed(2); // "2.68"
contrast('#595959', '#ffffff').toFixed(2); // "7.00"

Drop it into a unit test and you'll catch a failing color before it ever ships.

What's your go-to for checking contrast? I'm curious how many people check dark mode separately, because I suspect it's not many.

CSS text-overflow Now Takes Custom Text in Chrome 157. Here's What Works (and What Doesn't)

Hannan Shoukat — Wed, 11 Nov 2026 21:06:53 +0000

Chrome 157 went stable on November 3, and one small CSS change in it is surprisingly handy: text-overflow now accepts a custom string, not just ellipsis or clip.

That means the "…" at the end of truncated text can be anything you want: " (more)", " →", " [...]".

It's listed in the Chrome 157 release notes. Firefox has supported it for years, since Firefox 9. Safari doesn't support it yet, according to MDN's compatibility data.

I tried it out before writing this. Here's the recipe, plus two things that caught me out.

The basic recipe

text-overflow only works on text that's already overflowing on a single line. So you still need the usual two properties alongside it:

.truncate {
  white-space: nowrap;       /* keep it on one line */
  overflow: hidden;          /* hide what doesn't fit */
  text-overflow: " (more)";  /* the new part */
}

That's it. The browser cuts the text where it overflows and adds your string at the end.

Add a fallback in one line

Browsers that don't understand the string value ignore the whole declaration. So declare ellipsis first and let the newer value override it:

.truncate {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;   /* Safari and older Chrome use this */
  text-overflow: " →";       /* Chrome 157+ and Firefox use this */
}

Nobody gets a broken layout. They just get the classic "…" instead.

Gotcha 1: it cuts words in half

This was the first surprise. The cut happens wherever the text runs out of room, even mid-word. In my test, " (more)" produced:

Free shipping on every order over $50 unti (more)

The default ellipsis does the same thing, but it's easier to miss with "…". A word like "(more)" or "[...]" right after a broken word looks more like a bug.

Short, symbol-style markers like " →" or " …" hide this best.

Gotcha 2: multi-line clamping ignores it

The common way to show two or three lines and then cut off is -webkit-line-clamp. I paired it with the custom string:

.clamp {
  display: -webkit-box;
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 2;
  overflow: hidden;
  text-overflow: " (more)";
}

In Firefox, the custom string was ignored and the text ended with a normal "…". MDN's text-overflow page also says the property only affects text overflowing in the inline direction, not text cut off at the bottom of a box.

So this feature is for single-line truncation. I couldn't test Chrome 157's behaviour with line-clamp myself, so check it before relying on it.

What it can't do: be clickable

The string is just text drawn by the browser. You can't link it, focus it or attach a click handler.

So if you want an actual "Read more" that expands the text, you still need a real <a> or <button>. Where the custom string helps is as a visual hint, for example in table cells, card titles or file lists where the full text sits in a tooltip or detail view.

Where I'd actually use it

Card and list titles: " →" hints there's more to see.
Table cells: " [...]" reads more clearly than "…" in dense data.
Non-English interfaces: you can use a marker that suits the language.

The quick reference

Situation	Does the custom string work?
Single line with `nowrap` and `overflow: hidden`	Yes (Chrome 157+, Firefox)
Safari	No, falls back to your `ellipsis`
Multi-line with `-webkit-line-clamp`	Firefox ignored it in my test
Making the marker clickable	No, use a real link or button

Small feature, but it removes a whole category of "add a custom suffix in JavaScript" code. Has anyone found a good use for the two-value form, where you set a different marker at the start and end of the line?

13,352 Websites Already Let AI Agents Use Their Forms. Here's How WebMCP Works (With Code)

Hannan Shoukat — Wed, 11 Nov 2026 21:06:39 +0000

AI agents that browse the web on someone's behalf have a hard job. They look at a page, guess which box is the email field, guess which button submits, and hope nothing moved.

WebMCP is Chrome's answer to that. Instead of guessing, an agent can ask the page: what can you do? The page answers with a list of tools, each with a name, a description and a schema for its inputs.

It's still experimental, but it's already in use on more sites than I expected.

How many sites already use it

Browser Use ran a crawl to find out. According to their WebMCP directory, they loaded 322,714 pages in Chrome and found 13,352 sites exposing 45,763 distinct tools. The scan finished on October 19, 2026.

A few things stood out:

Shopping leads, with 6,107 sites, ahead of business software and developer tools.
Shopify accounts for about 5,190 of them, adding tools like add-to-cart and catalog search across many stores at once.
Adoption is still small at the top: 1,270 of the top 100,000 sites they could load, about 1.7%, had WebMCP tools.

So if you run a store on Shopify, your site may already be talking to agents. For everyone else, it's early, which is the best time to learn it.

The status, honestly

WebMCP is an active origin trial. Chrome's WebMCP guidance says local testing needs Chromium 146.0.7672.0 or later with the chrome://flags/#enable-webmcp-testing flag turned on, and that the API is experimental and may change.

Don't rebuild anything around it yet. But adding it to a form is cheap, and that's where to start.

The easy start: two attributes on a form

The declarative API turns an ordinary HTML form into a tool. Add toolname and tooldescription to the <form>, and optionally describe individual fields with toolparamdescription.

This is close to the example in Chrome's declarative API docs:

<form toolname="newsletter_signup"
      tooldescription="Subscribes the user to the weekly newsletter"
      action="/subscribe" method="post">
  <label for="email">Email</label>
  <input id="email" name="email" type="email" required
         toolparamdescription="The user's email address">
  <button type="submit">Sign up</button>
</form>

A few details from the docs worth knowing:

Both attributes are required. Remove either one and the tool is unregistered.
Labels count. Without toolparamdescription, the browser describes a field using its <label> text.
The user still submits by default. The agent can fill the form, but a person clicks the button, unless you add toolautosubmit.

Know when an agent sent the form

The submit event gets an agentInvoked flag, so you can treat agent submissions differently. You can also send a result straight back to the agent:

form.addEventListener('submit', (e) => {
  if (e.agentInvoked) {
    e.preventDefault();
    e.respondWith(
      fetch(form.action, { method: 'POST', body: new FormData(form) })
        .then((res) => (res.ok ? 'Subscribed.' : 'Subscription failed.'))
    );
  }
});

Whatever the promise resolves to is returned to the model as the tool's output.

For app-like pages: register a tool in JavaScript

When an action isn't a simple form, use the imperative API. Chrome's imperative API docs show it living on document.modelContext:

const controller = new AbortController();

await document.modelContext.registerTool({
  name: 'check_order_status',
  description: 'Returns the shipping status for an order number.',
  inputSchema: {
    type: 'object',
    properties: { orderNumber: { type: 'string' } },
    required: ['orderNumber'],
  },
  execute: async ({ orderNumber }) => {
    const res = await fetch(`/api/orders/${encodeURIComponent(orderNumber)}`);
    const order = await res.json();
    return `Order ${orderNumber} is ${order.status}.`;
  },
}, { signal: controller.signal });

// later, to remove the tool:
controller.abort();

The order-status endpoint is my example. The registerTool shape and the AbortSignal cleanup come from the docs.

The safety settings that matter

This is the part I'd read twice. Chrome's docs include several guards:

Setting	What it does
`consequentialHint: true`	Marks a high-impact action, so agents and browsers can ask the user to confirm
`untrustedContentHint: true`	Flags output that came from untrusted sources, such as user reviews, to help against prompt injection
`allow="tools"` on an iframe	Required before a cross-origin iframe can register tools
`exposedTo`	Tools are hidden from other origins unless you list them here

Chrome's guidance also says not to auto-submit tools for destructive or irreversible actions, such as deleting data, unless the person has to confirm manually.

My rule of thumb: newsletter signups and searches are fine to expose. Anything involving money, accounts or deletion should keep a human in the loop.

How to test and debug it

Two Chrome tools help here:

DevTools: open Application, then WebMCP. It lists the tools on the current tab and logs each time an agent calls one, with inputs and outputs. See Debug WebMCP tools.
Lighthouse: it now has an audit that flags <form> elements missing toolname or tooldescription. Chrome's docs say it's informational for now and won't produce warnings.

Should you add it now?

For a contact form, newsletter or site search, yes. It's a couple of attributes, and it costs nothing if the agent never shows up.

For checkout, payments or account actions, I'd wait. The API is an origin trial, the details are still changing, and those are exactly the actions where a mistake costs real money.

Has anyone added WebMCP to a production site yet? I'd like to know whether agents are actually calling your tools, or if they're mostly sitting idle so far.

Traffic Dropped During Google's November 2026 Core Update? Check These 6 Things First

Hannan Shoukat — Wed, 11 Nov 2026 21:06:25 +0000

Google started rolling out its November 2026 core update on November 10 at 10:06 a.m. Pacific. According to the Google Search Status Dashboard, it applies globally, to all languages, and may take up to two weeks to finish.

If your traffic dipped this week, the worst move is to start rewriting pages. Some drops come from the update. Others come from something you broke, and that kind you can fix today.

Here's how to tell them apart, using Google's own guidance.

First: don't judge it mid-rollout

Google's core updates documentation is specific about timing. Wait until the dashboard shows the rollout is complete, then wait at least a full week more before you analyze anything.

When you do compare, Google recommends comparing the week after the update finished with a week before it started. Comparing yesterday with last Tuesday mostly measures noise.

So for now, use the time to rule out the problems that aren't the update.

1. Check whether the drop is site-wide or narrow

Open Search Console, go to Performance, and use the Compare tab. Check whether the drop is limited to:

specific queries or pages
one country
one device type
one search type (Web, Image, Video, News)

This is the most useful split you can make. A drop on one device or in one country rarely comes from a broad core update. A drop spread across your whole site might.

2. Look for a technical problem first

Google's guide to debugging traffic drops points to two reports: Page indexing and Crawl stats. Look for a spike in errors that lines up with your drop.

Then run URL Inspection on a few pages that lost traffic and use the live test. It shows whether Googlebot can actually fetch the page right now.

You can also do a quick status-and-robots check from your terminal. This doesn't prove what Googlebot sees, but it catches obvious mistakes like a stray noindex after a deploy:

while read -r url; do
  code=$(curl -s -o /tmp/page.html -w "%{http_code}" "$url")
  header=$(curl -sI "$url" | grep -i '^x-robots-tag' | tr -d '\r')
  meta=$(grep -io '<meta[^>]*name="robots"[^>]*>' /tmp/page.html | head -1)
  echo "$code | $url | ${header:-no x-robots-tag} | ${meta:-no meta robots}"
done < urls.txt

Put the URLs that lost the most clicks into urls.txt, one per line.

A trap worth knowing: if you test with a bot's user agent, your CDN may answer 403. Many CDNs block requests that claim to be Googlebot or Bingbot but don't come from their IP ranges. That's normal and proves nothing about the real crawler. Only the search engine's own live test can confirm that.

3. Check the Security Issues report

If Google has detected malware or phishing on your site, it will show in Security issues in Search Console. It's a one-minute check, and it's a very different problem from a core update.

4. Check Manual Actions

A manual action means someone at Google decided part of your site breaks the spam policies. It shows under Manual actions. Again, this isn't the core update, and it has its own fix and review process.

5. Rule out search interest and seasonality

Sometimes nothing is wrong with your site. People are just searching less.

In the Performance report, filter to the queries that lost the most clicks. Check each one in Google Trends. Then switch to the 16-month date range and see if the same dip happened last November.

If demand fell everywhere, your rankings may be fine.

6. Think about what you changed recently

New theme, URL changes, a migration, a plugin update that touched SEO settings? Google's guide notes that a medium-sized site can take a few weeks for Google to process URL changes.

Drops that line up with your own deploy date are far more likely to be yours than Google's.

If it really is the core update

Google's documentation says a drop after a core update doesn't automatically mean something is wrong with your pages. Core updates are broad and don't target specific sites. Other pages may simply serve searchers better now.

Its advice:

Small drop: no need for drastic changes.
Large drop: do a deeper review of how helpful and reliable your content is.
Avoid quick fixes. Make improvements that help readers long term.

Recovery isn't instant either. Google says it can take several months for its systems to recognize improvements, and sometimes the change only shows after the next core update.

The short version

Symptom	Likely cause	Where to look
Drop on a few pages	Technical issue on those pages	URL Inspection live test
Spike in indexing errors	Technical issue	Page indexing, Crawl stats
Warning in Search Console	Security or spam	Security issues, Manual actions
Same dip last year	Seasonality	Performance, 16-month range
Broad drop, nothing else wrong	Core update	Wait, then compare full weeks

Has anyone seen movement yet? I'm curious whether people are seeing site-wide shifts or drops limited to specific page types.