{"id":19,"date":"2020-01-20T11:20:54","date_gmt":"2020-01-20T16:20:54","guid":{"rendered":"https:\/\/blog.crawfordux.com\/?p=19"},"modified":"2020-01-20T11:20:54","modified_gmt":"2020-01-20T16:20:54","slug":"all-buttons-are-not-created-equal","status":"publish","type":"post","link":"https:\/\/blog.crawfordux.com\/?p=19","title":{"rendered":"All Buttons Are Not Created Equal"},"content":{"rendered":"\n<h3 class=\"wp-block-heading\">Each Button Element has a Purpose<\/h3>\n\n\n\n<figure class=\"wp-block-image size-large is-resized\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/blog.crawfordux.com\/wp-content\/uploads\/2020\/01\/19_Buttons.jpg\" alt=\"\" class=\"wp-image-25\" width=\"565\" height=\"111\"\/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Yes, it looks like a button.&nbsp; But honestly any decent UX developer can make just about any HTML element look like a button.&nbsp; Add a couple lines of JavaScript and they can effectively serve as a functional button.&nbsp; So why would I want to use one markup type over the other?&nbsp; Does it matter?<br> <br> Yes, the definitions are different, and they each have specific purposes and advantages.&nbsp; It&#8217;s good to learn semantically how to use each to its best advantage and know why using them correctly matters.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">To begin, let&#8217;s look at the definition of each type of what many\nconsider interchangeable buttons.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Button has the following attributes (<a href=\"https:\/\/www.w3.org\/TR\/2011\/WD-html5-20110525\/the-button-element.html\">w3c<\/a>)<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>&nbsp;autofocus<\/li><li>disabled<\/li><li>form<\/li><li>formaction<\/li><li>formenctype<\/li><li>formmethod<\/li><li>formnovalidate<\/li><li>formtarget<\/li><li>name<\/li><li>type<\/li><li>value<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">The Anchor tag &nbsp;has the following attributes (<a href=\"https:\/\/www.w3.org\/TR\/html401\/struct\/links.html\">w3c<\/a>)<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>charset&nbsp;&nbsp;&nbsp;&nbsp;\n<\/li><li>type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\n<\/li><li>name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\n<\/li><li>href&nbsp;&nbsp;&nbsp; <\/li><li>hreflang&nbsp;&nbsp;&nbsp;\n<\/li><li>rel&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\n<\/li><li>rev&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\n<\/li><li>accesskey&nbsp;&nbsp;\n<\/li><li>shape&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\n<\/li><li>coords&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\n<\/li><li>tabindex&nbsp;&nbsp;&nbsp;\n<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Input type=submit has the following attributes (<a href=\"https:\/\/www.w3.org\/TR\/2011\/WD-html5-author-20110809\/number-state.html#submit-button-state\">w3c<\/a>)<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>formaction <\/li><li>formenctype <\/li><li>formmethod <\/li><li>formnovalidate <\/li><li>formtarget <\/li><li>name<\/li><li>value <\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Input type=reset has the following attributes (<a href=\"https:\/\/www.w3.org\/TR\/2011\/WD-html5-author-20110809\/number-state.html#reset-button-state\">w3c<\/a>)<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>name<\/li><li>value<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Input type=button has the following attributes (<a href=\"https:\/\/www.w3.org\/TR\/2011\/WD-html5-author-20110809\/number-state.html#button-state\">w3c<\/a>)<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>name<\/li><li>value<\/li><\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">As you are able to see, these definitions are pretty distinct, and that&#8217;s by thoughtful design.&nbsp; There are advantages to using the best choice.<br><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">But That&#8217;s Code and I Only Care if it LOOKS Like a Button <\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">As the advocate for the User Experience, it is your\nresponsibility to pay attention to these code decisions that can adversely\naffect the product users.&nbsp; Anymore, just\nabout every website or application will at some point impact\naccessibility.&nbsp; If you serve the\ngovernment in any capacity, it&#8217;s even mandated by legislation.&nbsp; <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sightless users that utilize a JAWS screen reader to access\nthe web are going to be at best inconvenienced and at worst hindered by the\nwrong decision.&nbsp; For example, a JAWS user\ncan navigate through all the links on a page by pressing the TAB key.&nbsp; It helps them traverse to other content pages\nquickly.&nbsp; Imagine the frustration if they\nhave to tab through a styled button bar of action buttons defined as links that\ndon&#8217;t lead to further content.&nbsp; Similarly\nin forms mode, they can immediately jump to the next button by pressing the &#8216;B&#8217;\nkey.&nbsp; If that button is defined as a\nlink, the shortcut won&#8217;t work and you force the user to move through every form\nelement individually.&nbsp; Using the element\nthat is best served for the context is not just good coding practice, it also\nlends itself to the best user experience.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">So When and Why Would I Use These? <\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">I&#8217;m not going to delve into all the reasons why you should\nor shouldn&#8217;t use each of these in this post.&nbsp;\nThe point of this is not to deliver a comprehensive thesis on each of\nthe HTML element button types.&nbsp; Ideally,\nit&#8217;s to inform you of their primary designed purpose so you are able to utilize\nthe best solution.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The Anchor Tag &#8211; This markup element was intended to be a\nlink to another URL resource.&nbsp; Notice\nthat one of the attributes is not &#8216;disabled&#8217;.&nbsp;\n&nbsp;If you want your button to have a\ndisabled state, the anchor tag is not your best element to use.&nbsp; Generally, links to another URL should rarely\nlook like a button, but there are instances where a large button call to action\non a page will lead to another URL.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The Input Buttons, Submit, Reset, and Button &#8211; These were intended to be used with Forms, when the use is to collect a set of form data from a user.&nbsp; Submit is specifically designed to submit the form action to the server for validation and storage.&nbsp; Reset is designed to reset the form data&#8230;., only.&nbsp; The input button type is designed for button actions within the form.&nbsp; 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.&nbsp; As a general rule, only use these types in the context of a form.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The Button Tag &#8211; If it looks like a button, acts like a button, and triggers events like a button&#8230;.., it should most likely be a button.&nbsp; The Button element has several advantages to hyperlink buttons.&nbsp; 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.&nbsp; It also has attributes for handling form actions and is accessible.&nbsp; I&#8217;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.&nbsp; There are exceptions, but the better practice is to use the designed element for the task&#8230;&#8230;.for the task.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Any other button styled HTML element &#8211; A span tag can look\nlike a button.&nbsp; So can a Div.&nbsp; Or just about any other tag as well.&nbsp; With JavaScript listeners attached, they can\nalso function like one.&nbsp; But UNLESS THERE\nIS A REALLY GOOD REASON, why would anyone want to go to strange coding to do\nsomething that the Button tag already does well?&nbsp; Typically, these are just poor coding\npractices.&nbsp; I personally have used them,\nbut the coder in me cringes when I have.&nbsp;\nBest practice is to avoid these options as much as possible.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">The Bottom Line<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">There are no code police running around the internet looking\nfor code infringements. So why worry about using the &#8216;best&#8217; option in the\napplication.<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li>To make YOUR LIFE EASIER.&nbsp; Using the best option can solve some problems\nwith less effort on your part.<\/li><li>To help those that edit your code after you move\non to that next great opportunity make changes without cursing you.<\/li><li>To help the UX be more accessible<\/li><li>To keep the code concise,&#8230;&#8230; and fast.<\/li><li>To keep the CSS clean and efficient. (The more\none off styles you have, the larger your CSS files)<\/li><li>Credibility. &nbsp;The developers already hold a marginal respect\nfor UX team members.&nbsp; Eroding it further\nwith poor code practices will be detrimental on future battles.<\/li><\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">That said, UX is not the only stakeholder in the game.&nbsp; If product or the development team need to\ndefine it differently, break the rules for the greater good of the finished\nproduct.&nbsp; <\/p>\n","protected":false},"excerpt":{"rendered":"<p>Each Button Element has a Purpose Yes, it looks like a button.&nbsp; But honestly any decent UX developer can make just about any HTML element look like a button.&nbsp; Add a couple lines of JavaScript and they can effectively serve as a functional button.&nbsp; So why would I want to use one markup type over [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[3,11,12,1],"tags":[],"class_list":["post-19","post","type-post","status-publish","format-standard","hentry","category-accessibility","category-css-html-js","category-dev-qa-architecture-ux","category-uncategorized"],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/pbdpy9-j","jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.crawfordux.com\/index.php?rest_route=\/wp\/v2\/posts\/19","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.crawfordux.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.crawfordux.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.crawfordux.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.crawfordux.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=19"}],"version-history":[{"count":5,"href":"https:\/\/blog.crawfordux.com\/index.php?rest_route=\/wp\/v2\/posts\/19\/revisions"}],"predecessor-version":[{"id":27,"href":"https:\/\/blog.crawfordux.com\/index.php?rest_route=\/wp\/v2\/posts\/19\/revisions\/27"}],"wp:attachment":[{"href":"https:\/\/blog.crawfordux.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=19"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.crawfordux.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=19"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.crawfordux.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=19"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}