Your gradient button probably fails WCAG — mine hit 1.81:1

Mohit Parmar — Tue, 18 Aug 2026 14:16:27 +0000

My portfolio uses an indigo → violet → cyan gradient on headline words and primary
buttons. It looks sharp. It also quietly failed accessibility, and no tool told me.

Why checkers miss it

WCAG AA wants 4.5:1 contrast between text and its background. Every contrast checker
takes one foreground and one background colour. But white text on a gradient
does not have one background — it has every colour along the ramp.

So I computed the ratio at each gradient stop instead of eyeballing it:

Gradient stop	White text contrast	AA (4.5:1)
Indigo `#6366f1`	4.6:1	pass
Violet `#8b5cf6`	3.9:1	fail
Cyan `#22d3ee`	1.81:1	fail badly

At the cyan end, white-on-cyan is nearly invisible to low-vision users — and this was
the call-to-action button. Worse, the hover state shifted the gradient toward cyan, so
the button got less readable exactly when someone showed intent to click it.

The fix: two gradients with different jobs

The display gradient is a brand asset; the button background is a legibility surface.
Those are different jobs, so they got different ramps:

:root {
  /* Headline words only — never carries text on top of it. */
  --gradient: linear-gradient(110deg, #6366f1, #8b5cf6 45%, #22d3ee);

  /* Filled surfaces carrying white text. Every stop clears 4.5:1. */
  --gradient-solid: linear-gradient(110deg, #4f46e5, #7c3aed);
}

The display gradient survives untouched where it is safe — clipped into text with
background-clip: text, where the text is the gradient rather than sitting on it. The
solid ramp goes everywhere white text sits on a fill. Visually the two read as the same
brand; mathematically only one of them ever carries text.

The habit worth keeping

If a design uses gradients under text, check the ratio at every stop, in every
state — including hover — with a script, not a screenshot. It is ten lines of
relative-luminance maths, and it catches the failure the single-pair checkers are
structurally unable to see.

Originally published on my portfolio.

GITHUB_TOKEN cannot enable GitHub Pages — and neither error tells you that

Mohit Parmar — Tue, 18 Aug 2026 14:16:26 +0000

While deploying my portfolio to GitHub Pages with GitHub Actions, the very first run
failed at actions/configure-pages@v5 with:

Get Pages site failed. Please verify that the repository has Pages enabled
and configured to build using GitHub Actions ... Error: Not Found

The message suggests a misconfigured workflow. It isn't. It means the Pages site
itself does not exist yet — nothing in the repository ever created it.

The trap: `enablement: true`

The action has an input that sounds like the exact fix:

- uses: actions/configure-pages@v5
  with:
    enablement: true

This fails too, with a different but equally unhelpful error:

Create Pages site failed. Error: Resource not accessible by integration

"Resource not accessible by integration" is GitHub's way of saying the token you are
using does not have the permission this API call needs. And here is the part that is
genuinely not obvious: no permission you can grant in the workflow file fixes it.
Creating a Pages site is a repository-administration operation, and the automatic
GITHUB_TOKEN can never administer the repository — by design, no matter what you put
under permissions:.

The enablement input only works with a personal access token or a GitHub App token.
For a personal project, wiring one up just for this is not worth it.

The actual fix — thirty seconds, in a browser

Settings → Pages → Build and deployment → Source → GitHub Actions.

That is the entire fix. It creates the Pages site once, and from then on the standard
workflow — configure-pages → upload-pages-artifact → deploy-pages — works with the
default token forever.

Two extra details that cost me time:

A private repository on a free account cannot serve Pages at all. Public repo, or a paid plan. The errors will not tell you this either.
The GitHub mobile app has no Settings screen. If you are doing this from a phone, you need the browser, and probably "desktop site" mode.

What I took from it

When a CI error says "Not Found" about a resource your workflow is supposed to create,
ask whether creating it is an admin operation. The default Actions token deliberately
cannot administer the repository that runs it — a good security boundary that produces
two of the most misleading error messages I have hit this year.