On Finding The Perfect “Add to Cart” Button


Recently I participated in a code camp at Al-Makinah where we introduce participants to the fundamentals of the front-end component of the web. I was asked to review the model answer to one of the exercises given to the students. It was simple; they take a web page written in HTML, CSS and JavaScript and improve it in a way that shows what they’ve learnt that reflects what they were taught. The exercise addressed several aspects like user experience improvement, semantics, validation of the markup … etc. It was a simple shopping cart with several products cards laid out in a grid.

I spend a lot of time writing HTML. It’s been a part of what I am doing every day for more than a decade. For me, HTML is more than just a few elements that you throw here and there; I invest a lot in picking the elements that I use. While I was reviewing the exercise, I stopped in front of the “Add to Cart” button. It was an <a> tag with a link. I started questioning myself; part of me hates the fact that this is a link not a button inside a form. It makes perfect sense to be a button. Of course it can be made anything. Simply attaching a listener that fires an ajax request updating the cart will work. But it doesn’t feel right. This isn’t semantically correct. Before I decide what the “Add to Cart” element should be, I decided I should write down the criteria addressing how this element should behave given all the possible circumstances.


  1. It must have the same behavior in presence or absence of JavaScript.
  2. If there are other fields like “amount,” pressing enter (submitting the form) should behave like clicking the button.

At this point I was convinced that this should be a submit button not a link. I quickly realized that this will require each product card to have a form tag with more elements like hidden input with product id for example. In big shops, the home page sometimes hosts a lot of product cards. It even uses sliders to save the space for “Newly arrived,” “Hot offers,” “Hot in category X” and the list can go on. A single page can contain more than a hundred of product cards. All this increase the amount of the HTML tags we serve to the user and increase the page size (comparing to serving a single <a> tag per card).

There is also another problem the submit button doesn’t address and it is very common. It’s the products that need you to select attributes before adding it to your cart (like shirt size or color). It’s common that these product cards redirect the user to the full details page of the product asking him to pick the required attributes in order to add the proper item to the cart. Now I changed my mind; I don’t think it’s a problem using a link for this functionality. I decided to change the first rule I mentioned earlier; it shouldn’t have the same behavior. It just should work in a way.

Before discussing the possible scenarios, I want to clarify something before getting into the argument of whether we should support users with no JavaScript or not. I believe both sides of the argument have valid points; however, there are reasons that you don’t want to lose even the smallest fraction of the users without JavaScript. We’re talking about e-commerce where conversion is translated directly into money. The solution is also pretty simple whether you decided to go with progressive enhancement or graceful degradation as you will see later on.

The available scenarios

Using button

If the product can be added directly to the cart, use button inside a form tag. It can use ajax when JavaScript is available or submit to the server directly when it isn’t (embracing progressive enhancement).


  • Semantically, it is more accurate.
  • The behavior is similar in presence or absence of JavaScript.



  • Require more code for form tag and other elements that identify the product.


If the product cannot be added without selecting attributes, use an anchor tag linking to the full product details page.

Using link

Use links in all cases. When JavaScript is available, hijack the click event and add the product to the cart using ajax (embracing graceful degradation). If it isn’t, direct the user to the full details page.



  • Requires less HTML, just a link with data attribute for product id.




  • The experience is different based on the presence or absence of JavaScript.
  • In absence of JavaScript, the link that says “Add to Cart” will do something completely different. It should then say “Show product details.” This might cause confusion for people using assistive technologies like screen readers.


How other e-commerce platforms address this issue?

I decided to review how the other popular e-commerce platforms address this issue. At robusta, we have success stories building successful big e-commerce platforms in Egypt using popular platforms like WooCommerce and Magento Enterprise Edition. I picked the popular open source e-commerce platforms available which provided a demo and a default theme. Now, bear in mind that the result of this analysis is highly based on the used theme. If you are using a different theme it is very likely that your theme uses a different markup than what I am about to show you. The default theme is important because developers use it as a boilerplate for their themes. Some platforms like Magento allow defining a parent theme and extend it to override some of its parts instead of writing everything from scratch.

Magento 2

Magento comes with a theme called Luma. It uses a button tag without a form. The button itself has some additional data attributes related to the product. As you might guess, this implementation doesn’t work except when JavaScript is available. It’s worth mentioning that Magento 2 utilizes RequireJS to split JavaScript into modules. Luma theme by default loads 119 JavaScript file in the homepage alone. With Magento, JavaScript bundler merely seems to function properly; there is a big chance for failure at any point (by network timeout, server failure, slow internet connection,…etc.). It’s disappointing to see the e-commerce giant uses an inaccessible solution that only works with JavaScript.


The number 1 WordPress plugin for e-commerce really shines with its implementation. It uses a link that directs to the current page with the query string “?add-to-cart=id”. When JavaScript is available, the product is added to the cart using ajax. When it’s absent, WooCommerce handles it in a way different than the scenarios I mentioned before. The product is added to the cart and the user is redirected to the same page again with a success message on top. WooCommerce says “Add to cart” and it delivers what it says exactly with no confusion. When the product requires picking attributes, it redirects the user to the product details page.


OpenCart uses a button without a form that has an onclick attribute. It requires JavaScript to work. When JavaScript is available the product is added to the cart. If the product requires selection of attribute the same button redirects the user to the full details page.


Perhaps this is one of the least known e-commerce platforms but it is well known across Joomla community. VirtueMart uses a classic form with a button. If JavaScript is available, the experience is enhanced with ajax. If not, the form is submitted and the user is redirected to the cart page. If the product requires selection of additional attributes the button is disabled and the options are displayed to pick from inside the cart. VirtueMart embraces progressive enhancement and provides a solution that works smoothly.


This is an obligatory mention to the e-commerce dinosaur. From the minute you check the demo you get the feeling that you stepped back in time into PhpNuke. osCommerce doesn’t include an add to cart button in the listing. Adding the product to the cart is only available inside the full product details.


There are several methods to mark down the “Add to Cart” button. We should always embrace a method that guarantees the button will work then improve the experience using JavaScript.