Can we get rid of the blue outline that’s in every screenshot?

You’ve seen it. Press Tab on a web page and a box appears around a link; press it again and the box hops to the next one. That hop is the follow spot moving, and the Tab key is the operator.

Who presses Tab? More people than you’d guess!

Anyone who can’t hold a mouse steady. People who use a screen reader (software that reads the page aloud) alongside a keyboard. And a quiet crowd who simply type faster than they point: the person filling in your checkout at speed, the one on a laptop with a broken trackpad, the one with a baby on the other arm.

For all of them, the ring is the only thing on the page that answers the question “where am I?”

Does it matter if it’s a small group? I’d say the size is the wrong question. A page that can’t be used without a mouse isn’t a slightly worse page for those people; it’s a closed door. (WebAIM’s page on keyboard access is the long version.) The web’s accessibility guidelines say it in one line: keyboard focus must be visible.

How this goes wrong: say your checkout has nine things you can tab to: three fields, a checkbox, four buttons, and a link to the terms. Remove the ring and a person pressing Tab is pressing it blind, counting hops, hoping the ninth press lands on “Pay.” It usually doesn’t.

I understand the instinct. In some browsers the ring shows up when you click a button with a mouse too, and then it sits there looking like a mistake until you click somewhere else. It ends up in every screenshot. Someone types the one line that removes it (it is one line, which is most of the problem), and the screenshots are clean at last.

What’s the cost? Everything in the previous section, silently.

Nobody who uses a mouse notices. Nobody who uses a keyboard can tell you, because they’ve left.

Here’s what I think is going on: the problem you’re pointing at is real, and the fix you asked for is wrong. The ring isn’t the problem; it’s that it shows up for the wrong people (mouse clicks) and looks like it wasn’t invited (default blue over your brand’s colors).

Both are fixable without switching the light off. Let’s take them in that order.

A follow spot has dials: how wide the circle is, how soft its edge is, which colored gel sits in front of the lamp. The ring has three of its own, and we’d say they’re enough to make it look like it was always part of the design.

Color. The default blue is a default, nothing more. Pick one from your palette that stands out against every background the ring will sit on: a dark accent on light, a light one on dark. The guidelines ask the ring to stand out from its surroundings at about three to one, which in practice we read as “don’t pick a pale gray and call it subtle.” (This guide to focus indicators walks through the arithmetic better than I could, and the British government’s design system shows its yellow-and-black ring with the reasoning attached.)

The gap. Most of what makes the default ring look wrong is that it hugs the thing too tightly, like a sticker on a photo. Push it out by a couple of pixels (a pixel being one dot on the screen) and it reads as a halo instead of a border. On a button with a background, that gap is the difference between “there’s a glitch” and “this one’s selected.”

The corners. A square ring around a round button is the most common tell we see, and the easiest to fix, which is a rare combination. Match the ring’s corners to the thing it’s around, plus the gap. Now it’s an outline of the button, not a box someone drew over it.

That’s the whole redesign: color, gap, corners. An afternoon, done once, applied everywhere!

How this goes wrong: say whoever restyles it picks the brand’s pale yellow for the ring because it’s on brand. On the white page it vanishes, and now the ring exists and still doesn’t do its job, which is the worst of both.

Now the other half, the part I think will make you happy.

Browsers can tell the difference between a focus that came from a click and one that came from a keyboard. There’s a rule for it that your developers will know by name, :focus-visible, and what it means is “show this only when the browser thinks the person needs to see where they are.” Click a button with a mouse and the ring stays hidden. Press Tab and it appears. Every major browser has understood that rule since 2022.

Why does this fix the screenshots? Because the screenshots are taken with a mouse.

You, with a folder full of blue boxes: the ring you were trying to delete simply stops showing for clicks, and it still shows for the people who need it.

Is there a catch? One, small.

Text fields show the ring on a click too, on purpose, because a cursor needs a home. We’d leave that alone; it’s right.

(Two things to know before you test this on a Mac: Safari doesn’t move between links with Tab until you switch on the setting called “Press Tab to highlight each item on a webpage,” and macOS has its own switch for keyboard navigation in System Settings. I’d check both before blaming the code.)

You press a button and a panel slides over the page: a sign-in box, an “are you sure?” dialog, a photo viewer. On a good site, press Tab now and you’re inside the panel, moving between its fields and buttons. Close it and you’re back on the button that opened it.

On a bad site, press Tab and the ring goes somewhere. Behind the panel. To a link you can’t see. Through the whole page underneath, while the panel sits there ignoring you.

In the theatre, when the scene moves to the balcony, the spot swings up to the balcony. It doesn’t keep lighting an empty stage. And when the scene comes back down, the spot comes back with it.

Two rules, then, and we’d hold to both. When something opens, put the focus inside it. When it closes, put the focus back where it came from.

That’s the whole of it, and it’s the part most often forgotten, because the person building the panel had a mouse in their hand the whole time.

Some good news for your developers: browsers now have a built-in panel that handles most of this. It moves focus in and keeps the Tab key from wandering underneath; whether focus comes back on close is the thing I’d still check by hand.

Most sites build their own panel instead, and a hand-built panel does none of that unless someone writes it. We’d write it the same day as the panel.

How this goes wrong: say a search box opens as a panel, and closing it drops the focus back to the top of the page. The person who opened it from halfway down a long article is now ten Tab presses from where they were, and they’ll put up with that once.

Most of the ring’s hard cases, I find, aren’t buttons. They’re the in-between things: a search box with a magnifying-glass icon, a card that’s clickable all over, a row in a list with three actions inside it.

Say the search box. The icon sits inside the field and it’s drawn as a separate thing, so click the icon and nothing happens, or the ring appears around the field but not the icon and the whole thing looks lopsided. We’d treat the field and the icon as one object: the ring goes around the pair, and pressing the icon puts the cursor in the field. One spot on one actor, not two actors in the same circle.

Say the card. A picture, a title, and a “Buy” button inside it. Which gets the ring when you press Tab: the card or the button?

If the whole card is a link and the button sits inside it, you’ve got a button inside a link, and keyboards hate that. We’d make them neighbors instead: the title is the link, the button is a button, and Tab visits each in turn with its own ring.

And the row with three actions? Tab should land on the row, and we’d have the arrow keys move between the actions in it, which is how a set of radio buttons has always worked. (The people behind the accessibility guidelines keep a long page of these keyboard rules; drier than this one, and more complete.) That’s a bit of extra work, and it’s the bit that separates “we have a focus ring” from “you can use this.”

Don’t take my word for it. Here’s the test, and I’ll call it a hypothetical because I haven’t seen your app:

1. Put the mouse out of reach. Not pushed aside, out of reach, because your hand will go to it.
2. Press Tab from the top of the page. Can you see where you are at every press? Does anything disappear off the edge, or vanish behind a header that stays put at the top?
3. Open every panel and menu with Enter. Does the ring go in? Does Escape close it? Does the ring come back to where you started?
4. Reach “Pay,” or “Send,” or whatever the page is for. Count the presses. If you lost track, so will everyone else.
5. Now do the same with a mouse, and take a screenshot. No ring in sight? Good!

I’d put money on step three being the one that bites. (If you run it on one of ours and find a square ring, that’s on me, and I’d rather hear about it than not.)

But it’s ten minutes, and it tells you whether the argument was about looks or about people who can’t reach “Pay.” If you want the long list, this community-run accessibility checklist is the one we’d print.

So, you, with the screenshots, and the developers with the lecture: you’re both right about something.

The ring, as it ships, does look like a mistake. And it is also the only light on the stage for the people who don’t use a mouse.

Keep the light, we’d say.

Change the gel, widen the gap, round the corners, show it only when a keyboard is driving, and swing it to the balcony when the scene goes there.

Nobody using a mouse will ever see it again. The people using a keyboard will see a ring that looks like it belongs, and they’ll never know there was an argument!

In one breath: keep the ring, recolor it to stand out, push it off the edge by a couple of pixels, match its corners, show it only for keyboards, send focus into panels and back out, treat an icon and its field as one thing, and tab through your own checkout with the mouse out of reach.

That’s all of it. Here’s to the next person who reaches your “Pay” button without a mouse, and never notices how easy it was.

Hope this helps.