Each Button Element has a Purpose
Yes, it looks like a button. But honestly any decent UX developer can make just about any HTML element look like a button. Add a couple lines of JavaScript and they can effectively serve as a functional button. So why would I want to use one markup type over the other? Does it matter?
Yes, the definitions are different, and they each have specific purposes and advantages. It’s good to learn semantically how to use each to its best advantage and know why using them correctly matters.
To begin, let’s look at the definition of each type of what many consider interchangeable buttons.
Button has the following attributes (w3c)
- autofocus
- disabled
- form
- formaction
- formenctype
- formmethod
- formnovalidate
- formtarget
- name
- type
- value
The Anchor tag has the following attributes (w3c)
- charset
- type
- name
- href
- hreflang
- rel
- rev
- accesskey
- shape
- coords
- tabindex
Input type=submit has the following attributes (w3c)
- formaction
- formenctype
- formmethod
- formnovalidate
- formtarget
- name
- value
Input type=reset has the following attributes (w3c)
- name
- value
Input type=button has the following attributes (w3c)
- name
- value
As you are able to see, these definitions are pretty distinct, and that’s by thoughtful design. There are advantages to using the best choice.
But That’s Code and I Only Care if it LOOKS Like a Button
As the advocate for the User Experience, it is your responsibility to pay attention to these code decisions that can adversely affect the product users. Anymore, just about every website or application will at some point impact accessibility. If you serve the government in any capacity, it’s even mandated by legislation.
Sightless users that utilize a JAWS screen reader to access the web are going to be at best inconvenienced and at worst hindered by the wrong decision. For example, a JAWS user can navigate through all the links on a page by pressing the TAB key. It helps them traverse to other content pages quickly. Imagine the frustration if they have to tab through a styled button bar of action buttons defined as links that don’t lead to further content. Similarly in forms mode, they can immediately jump to the next button by pressing the ‘B’ key. If that button is defined as a link, the shortcut won’t work and you force the user to move through every form element individually. Using the element that is best served for the context is not just good coding practice, it also lends itself to the best user experience.
So When and Why Would I Use These?
I’m not going to delve into all the reasons why you should or shouldn’t use each of these in this post. The point of this is not to deliver a comprehensive thesis on each of the HTML element button types. Ideally, it’s to inform you of their primary designed purpose so you are able to utilize the best solution.
The Anchor Tag – This markup element was intended to be a link to another URL resource. Notice that one of the attributes is not ‘disabled’. If you want your button to have a disabled state, the anchor tag is not your best element to use. Generally, links to another URL should rarely look like a button, but there are instances where a large button call to action on a page will lead to another URL.
The Input Buttons, Submit, Reset, and Button – These were intended to be used with Forms, when the use is to collect a set of form data from a user. Submit is specifically designed to submit the form action to the server for validation and storage. Reset is designed to reset the form data…., only. The input button type is designed for button actions within the form. An example of this would be an employee selector button that opens a common modal window component to offer tools that allow a user to search a large employee database using filtered criteria. As a general rule, only use these types in the context of a form.
The Button Tag – If it looks like a button, acts like a button, and triggers events like a button….., it should most likely be a button. The Button element has several advantages to hyperlink buttons. The disabled property allows a quick and effective way to disable a button that can be directly referenced in the CSS without adding a separate class to the element. It also has attributes for handling form actions and is accessible. I’ve found the 80/20 rule to be pretty close in real world usage that most of the time, the button tag is the best tag to use for a button element. There are exceptions, but the better practice is to use the designed element for the task…….for the task.
Any other button styled HTML element – A span tag can look like a button. So can a Div. Or just about any other tag as well. With JavaScript listeners attached, they can also function like one. But UNLESS THERE IS A REALLY GOOD REASON, why would anyone want to go to strange coding to do something that the Button tag already does well? Typically, these are just poor coding practices. I personally have used them, but the coder in me cringes when I have. Best practice is to avoid these options as much as possible.
The Bottom Line
There are no code police running around the internet looking for code infringements. So why worry about using the ‘best’ option in the application.
- To make YOUR LIFE EASIER. Using the best option can solve some problems with less effort on your part.
- To help those that edit your code after you move on to that next great opportunity make changes without cursing you.
- To help the UX be more accessible
- To keep the code concise,…… and fast.
- To keep the CSS clean and efficient. (The more one off styles you have, the larger your CSS files)
- Credibility. The developers already hold a marginal respect for UX team members. Eroding it further with poor code practices will be detrimental on future battles.
That said, UX is not the only stakeholder in the game. If product or the development team need to define it differently, break the rules for the greater good of the finished product.