DEV Community

The Button

stereobooster on June 08, 2019

Demo is here. Source code is here. Use <button> Please don't use <a> for buttons. They have different meaning and behaviour...

Read full post

Al Romano • Jun 9 '19

You forgot the most important point about buttons from an accessibility viewpoint. Using type="button" when you aren't using it to submit data!

If you forget this type, some browsers default back to type="submit". By also using proper type you don't need e.PreventDefault either.

If you want to get better at #a11y development I would focus more on HTML symantics and what changes when you add aria elements because it can change the behaviour of elements and their intended meanings to users.

To learn more I would highly recommend readying Hedyon Pickering's Accessible Components. It's mandatory reading for all our frontend Devs at our shop because we're a charity that needs to build accessibility into everything we do.

stereobooster • Jun 9 '19 • Edited

TIL

The type of the button. Possible values are:

submit: The button submits the form data to the server. This is the default if the attribute is not specified, or if the attribute is dynamically changed to an empty or invalid value.

reset: The button resets all the controls to their initial values.

button: The button has no default behavior. It can have client-side scripts associated with the element's events, which are triggered when the events occur.

developer.mozilla.org/en-US/docs/W...

Davis • Jun 9 '19

So, what if I want that as a clickable link and don't want to hook up JS to that button to do so?
This result you have there would only make you as the initiator of the idea feel better. Client wouldn't give 2 shits about how is that working, it just works, so why do extra work for that? It's just a trend, even W3C Validator doesn't give a crap about as a button. Therefore, why not style to look like a button, even better - create few concise utilities for that? This is just getting nit-picky.

stereobooster • Jun 9 '19 • Edited

I mean if your main concern is "Client wouldn't give 2 shits about how is that working", I guess this advice is not for you.

I'm not saint myself, but from time to time I think about people who have special needs, for whom internet (the biggest source of information, free education, online banking, social, media etc...) is not accessible. There are people who can't use internet, because somebody "didn't give 2 shits", and other person didn't bother either, because he is not get paid for it.

~~W3C Validator? Seriously? Did you travel here from 1999?~~
UPD: W3C Validator is ok, it is not for a11y testing though. You can try axe for a11y testing. a11y testing tools doesn't guarantee absence of a11y issues, they just help find some obvious ones. You still need to test it manually

Davis • Jun 9 '19 • Edited

As I am not exclusively a front-end dev, yet I was back in the day, W3C Validator was my go to.
For accessibility - that would be some additional planning, time consuming one. Either I hire someone for front-end or learn that stuff myself, either money or time consuming. Not my top priority, since that's quite low percentage of users.

stereobooster • Jun 9 '19 • Edited

Not my top priority, since that's quite low percentage of users.

That is discrimination based on abilities which has legal implications under some laws. Here is the list of laws

Angelique • Jun 12 '19

Not only are there legal implications to your attitude about accessibility, but your assumptions about users who benefit from accessible designs is really limited. Microsoft has an Inclusive 101 guide that is a great resource, and I highly recommend reviewing it and challenging yourself a bit on this, Davis.

Davis • Jun 15 '19 • Edited

Oh, we are even going there with this.

I am not interested in answering everyone getting upset by that - I won't prioritize accessibility concerns over what the hell my button really is and what it does.

Desi • Jun 12 '19

This viewpoint is exhausting and is exactly why accessibility gets pushed to the back burner. "It doesn't effect me personally, so it MUST be a low percentage of users."

Paul • Jun 12 '19

Not my top priority, since that's quite low percentage of users.

That is an awful attitude. And you never know when you or someone you know will suddenly belong to that group of users. A disability can happen in an instant.

Davis • Jun 15 '19 • Edited

You do realize that "not my top priority" !== "not gonna do that"?
But, I guess, it's appealing to push views for leverage of community that will get backed up since I am the "bad guy" here.

Comment marked as low quality/non-constructive by the community. View Code of Conduct

Davis • Jun 25 '19

Sheesh, so many butthurt people. ;)

anpos231 • Jun 9 '19 • Edited

I don't remember where I've read it, but once one guy asked on the internet if he should fire his font-end developer.
The guy said that it took 2 days for the font-end dev to create a button!

This guy should probably see this guide :P, I am pretty sure we could add even more to it, like aria props, buttons with menus, buttons that control state of other elements, etc...

Then test it all on multiple browsers and screen readers.

Nicolas Bailly • Jun 9 '19

Honestly though, it entirely depends on what the task was.

If it's just "add a button that does x when clicked", I don't want a developer to go nearly as far as what's presented here and waste two days on a button. I wouldn't fire anyone over this, but I would definitely explain that they have a job to do and that it's not OK to start doing R&D when asked to add a button.

Now if the task was "add a button that looks exactly like this, is responsive, has a specific look when disabled, a focus state that looks identical on all browsers" and so on... I'd expect a developer to at least tell the Product Owner "OK, but this is not a simple button and it's going to take me at least a day of work"

Md Abu Taher • Jun 9 '19 • Edited

The question on Quora got viral and there are one answer with 13k upvote. I only got 1k upvotes though :D

qr.ae/TWG0sV

I've linked back to this post.

Kevin • Jun 8 '19

    <ul>
        <li><button>link 1</button></li>
        <li><button>link 2</button></li>
        <li><button>link 3</button></li>
        <li><button>link 4</button></li>
        <li><button>link 5</button></li>
    </ul>

i got you ;)

stereobooster • Jun 8 '19

Herbert Verdida • Jun 9 '19 • Edited

One might be interested reading this as well, “Buttons shouldn’t have a hand cursor” by Adam Silver link.medium.com/E09nLN8KmX.

stereobooster • Jun 9 '19

Fair point. I kind of agree with it

Danil Zakablukovskiy • Jun 8 '19 • Edited

thanks, always interesting to look into the accessibility best practices!
and i find the button looking good

Elliot • Jun 8 '19 • Edited

This is comprehensive, simple, and in-depth on the topic of button styling! Really nice work.

It seems like such a simple thing, but I love to see all its important and interesting facets.

stereobooster • Jun 8 '19

I guess you would enjoy reading about The Image as well

Elliot • Jun 8 '19 • Edited

ye, nice.

I know you can add articles to a series on dev.to. Are these two articles in a series?

edit: never mind, clicked on the link and realized it's a github link :| I am just curious what a series of articles looks like on dev.to

stereobooster • Jun 8 '19

Yeah, it was published before I joined dev.to. Maybe I will update component to use React hooks and republish article to dev.to.

Alejandro Gorgues • Jun 8 '19

At least you made a button

stereobooster • Jun 8 '19

I know, right?

Olivier “Ölbaum” Scherler • Jun 12 '19

I’m lost. Where do I put the href for that button? It’s missing from your examples.

stereobooster • Jun 12 '19

You can style links to appear as buttons (it can be bad UX, it depends on the situation), but you should not use links as buttons e.g. when they don't have correct href param. Examples of bad buttons:

<a onClick="..."></a>
<a href="#" onClick="..."></a>
<a href="javascript:..."></a>

instead, you can write

<button type="button" onClick="...">

Does this help?