Or: If That Pink Lozenge Isn’t a Button, We’re Gonna Fight
There’s a special kind of betrayal that happens when something looks like a button…
…but isn’t.
You hover. Nothing happens.
You click. Nothing responds.
You try the keyboard. Nada.
Maybe it was a <div>. Maybe a <span>. Maybe some text in a pill-shaped bubble someone styled to look “clickable.”
All you know is:
You were led to believe.
And the button let you down.
What even is a button?
At the most basic level, a button is an interactive element – something the user can press to take an action.
But here’s the thing: not all “buttons” are real buttons. And that causes problems.
A real, semantic HTML button:
- Uses the <button> element (or <input type=”submit”>)
- Works automatically with keyboard (Enter and Space)
- Is announced correctly by screen readers
- Supports focus states and form submission by default
Fake buttons made from <div> or <span>?
They don’t do any of that. Not without extra code. And even then, they’re fragile.
If it looks like a button, it should be a button.
“That’s a button, that’s a button, that’s… NOT a button?!”
This is where visual language comes in.
If you teach users that a pink lozenge shape is clickable, then every pink lozenge better behave like a button. If one does nothing? It breaks trust.
Buttons are about predictability.
You’re training users what to expect.
This is especially important for people with cognitive impairments, who rely on consistency and visual cues to understand what they can interact with.
Keyboard users need real buttons
If someone is navigating your site with a keyboard, they rely on the Tab key to move from one focusable element to the next.
Real buttons:
- Can be focused
- Respond to Enter or Space
- Provide visual cues when focused
Fake buttons:
- Often aren’t tabbable
- Might not respond to keyboard events
- Rarely show focus at all
If your “button” can’t be reached or activated without a mouse, it’s not a button. It’s a decorative lie.
Screen readers need real buttons, too
Screen readers announce buttons as buttons. That’s huge.
- A real <button> gets announced as “Button: Submit” or “Button: Continue”
- A fake <div> just gets read as… “text.” If anything at all.
And if it’s a form control – like “Submit,” “Next,” or “Pay now” – screen reader users need to know what it is and what it does.
Semantics matter.
You’re not just styling a shape – you’re giving it meaning.
Visual feedback: Make it obvious
When someone interacts with a button, they expect something to happen:
- A hover state (mouse)
- A focus outline (keyboard)
- A pressed or active state (when clicked or tapped)
Without these, users feel unsure. Did it work? Should they click again?
Good button feedback:
- Changes background or border
- Adds a visible focus state
- Animates (if appropriate) to show response
- Looks different from static content
Let people know: “Yes, this is clickable – and it worked.”
Buttons vs Links: Know the difference
If it takes you somewhere new, use a link (<a>).
If it performs an action, use a button (<button>).
Examples:
- Link: Go to the “About” page
- Button: Submit a form
- Link: Open the Terms and Conditions page
- Button: Open a modal
Misusing these can confuse users and break accessibility.
(Also, it’ll mess with screen readers and keyboard navigation.)
Quick checklist: Is it really a button?
- Does it use a real <button> element?
- Can you activate it with both mouse and keyboard?
- Does it show a focus state when tabbed to?
- Is it announced properly to screen readers?
- Does it look like other buttons on the site?
- Does it behave consistently?
Press it like you mean it
A button is a promise.
It says: “You can press this. It will do something. And it will work.”
Don’t break that promise.
Don’t build fake buttons that leave people stranded.
Don’t train users to expect one thing, then hit them with something else.
Don’t sacrifice usability for aesthetic minimalism.
Just give people the confidence to press forward – literally.
And if that pink lozenge isn’t a button?
We’re gonna have words.