1
The other day we published an article with a bonafide CSS trick where an element with a double border could look like a pause icon, and morph nicely into a CSS triangle looking like a play icon. It was originally published with a <div>
being the demo element, which was a total accessibility flub on our part, as something intended to be interacted with like this is really a <button>
.
It also included a demo using the checkbox hack to toggle the state of the button. That changes the keyboard interaction from a “return” click to a “space bar” toggle, but more importantly should have had a :focus
state to indicate the button (actually a label) was interactive at all.
Both have been fixed.
2
Adam Silver has an interesting post where the title does a good job of setting up the issue:
But sometimes links look like buttons (and buttons look like links)
Buttons that are buttons aren’t contentious (e.g. a form submit button). Links that are links aren’t contentious. The trouble comes in when we cross the streams.
Buttons (that have type=”button”) are not submit buttons. Buttons are used to create features that rely on Javascript. Behaviours such as revealing a menu or showing a date picker.
A call-to-action “button” is his good example on the other side. They are often just links that are styled like a button for prominence. This whole passage is important:
In Resilient Web Design Jeremy Keith discusses the idea of material honesty. He says that “one material should not be used as a substitute for another, otherwise the end result is deceptive”.
Making a link look like a button is materially dishonest. It tells users that links and buttons are the same when they’re not.
In Buttons In Design Systems Nathan Curtis says that we should distinguish links from buttons because “button behaviours bring a whole host of distinct considerations from your simple anchor tag”.
For example, we can open a link in a new tab, copy the address or bookmark it for later. All of which we can’t do with buttons.
Call to action buttons— which again, are just links — are deceptive. Users are blissfully unaware because this styling removes their natural affordance, obscuring their behaviour.
We could make call to action buttons look like regular links. But this makes them visually weak which negates their prominence. Hence the problem.
I find even amongst <button>
s you can have issues, since what those buttons do are often quite different. For example, the Fork button on CodePen takes you to a brand new page with a new copy of a Pen, which feels a bit like clicking a link. But it’s not a link, which means it behaves differently and requires explanation.
3
I’ll repeat Adam again here:
Buttons are used to create features that rely on Javascript.
Buttons within a <form>
have functionality without JavaScript, but that is the only place.
Meaning, a <button>
is entirely useless in HTML unless JavaScript is successfully downloaded and executed.
Taken to an extreme logical conclusion, you should never use a <button>
(or type="button"
) in HTML outside of a form. Since JavaScript is required for the button to do anything, you should inject the button into place with JavaScript once it’s functionality is already ready to go.
Or if that’s not possible…
<button disabled title="This button will become functional once JavaScript is downloaded and executed">
Do Thing
</button>
Then change those attributes once ready.
It seems for me that when ‘flat’ design gained popularity, the other way around can be discussed. I am aware that this is not the web, but the user doesn’t care – all the buttons in iOS are styled like links. Are we suppose to base the web designs on that fact (as the user learns the new way from the system) or shall we style our web pages in opposite way and (exaggerating of course ) confuse the user?
WRT #3, wouldn’t using the
hidden
attribute suffice render the button ineffective until JS can do its thing (and then remove that attribute)?Perhaps it is to let a user know where functionality is being lost due to their disabling JS? Rather than leaving gaps in the page or design and the user guessing what is going on, this would explain it outright and provide a solution.
The reason you wouldn’t want to use the
hidden
attribute is because the button will then lose its place in the page. When it is shown, it will shift all the content below it down, so that it can fit it. Using thedisabled
attribute means the button will hold its place, the rest of the content will fall where it’s meant to, and the page won’t be jumping as JS is loaded.Interesting. Makes sense. Thanks both.
Newsflash: Users don’t care. They don’t even realize it, they are not going through the HTML source to look what element is what.
This is just OCD, not something you worry about for your users.
You’re right and wrong. Most users don’t care whether it’s a button or a link but from an accessibility standpoint it could have a pretty big impact.
I teach that a button is for a toggle(ish), a link is to route to a URL. It also matters for assistive technology, so it’s helpful for devs to get this correct.
Nope, I’m not going to do this. I don’t want to complicate my workflow even further.
Even though I’m basically always building SPAs and it comes for free, for the remaining cases it takes usually very short to download the JavaScript needed for that button to work.
If that button remains inactive for a second, it’s not that bad.
In our system, we use
links
looking asbuttons
. The reason is, in most cases we want to show modal (loaded from providedlink href
) and where there is no javascript, user will just go to standalone page of modal content. There are few cases, thats role is like toggle or just a link.The main reason is that button styling on links looks more like do some action, and from user view, its easier to find and interact.
But I agree, same styling and diffrent functionality may hurt.
I don’t want to blame somebody. But before argue, just need to read HTML5 specs, there is pretty good explained what button stands for and what is tag for.
https://www.w3.org/TR/html5/forms.html#attr-button-type-button-state
https://www.w3.org/TR/html5/text-level-semantics.html#the-a-element
Pretty clear and unambiguously.
If your hidden button contained text which wouldn’t become visible automatically or by some standard user interaction you will have fun with google. It’s a sin they call “cloaking”, possibly leading to an organic index ban.
Yes, web development is multidimensional.