To celebrate this year’s Global Accessibility Awareness Day (GAAD) I started working on one of my 2021 goals, write more technical notes on eCommerce accessibility.
Even when websites with more accessibility complains are in the eCommerce industry, there’s a lack of technical documentation on how to make them accessible.
Example of the topics I’ll be covering on this series of articles:
- How should the „Buy Now“ button be structured?
- How should products be listed in a product listing page?
- What makes a search box accessible?
- How should a discounted price be coded to be properly announced in a screen reader?
- What at the considerations to create a colour picker?
Unfortunately they are not eCommerce specific, they can be applied to any website (blog, personal page, newspaper, etc.).
There doesn’t seem to be detailed descriptions about the technical needs a eCommerce faces.
In the following articles I’ll be giving you some technical & functional documentation that will hopefully help close that gap.
Product Detail Page
As a buyer, it’s important to know everything there is to know about a product before purchasing it.
Unfortunately we’re not yet in a digital world that allow us to try products before we buy them.
One of the goals of a store owner is to provide as much detail of a product as possible.
This information is typically shared in what’s called the Product Detail Page (PDP).
But, what exactly is a product detail page, and what makes it effective?
Read my thoughts on this in this article: Product Detail Page – eCommerce Accessibility
Search Box
I have yet to find a eCommerce website that can live without a search box.
The purpose of the component is to allow buyers to discover products on the website.
What makes a search box actually accessible and useful?
In this article (part one) I show you the basic code require to stat building an accessible search box.
Read my thoughts on this in this article: Search box part 1 – eCommerce Accessibility
Anchors or Buttons
One common mistake that junior developers make when starting to work is to use the multiple HTML elements for the same purpose.
The preferred element by developers & Content Management systems for actionable items is anchor <a>.
However there are many considerations that need to be taken into account when using an anchor <a> when a <button> should have been used.
For instance:
- The default styling are different, requiring CSS to visually „match“ both elements.
- The keyboard operation in both elements are different, requiring JavaScript to „match“ behaviour in both elements. What are those little tweaks that need to be considered? Read my thoughts on this article: When does an anchor becomes a button
If you have questions or comments, leave me a comment or message me at @
If you want to know more about the motivation of this articles, don’t miss the first article of the series eCommerce Accessibility
Front End Development Manager & Accessibility Champion. I specialize – but not solely focus – on eCommerce accessibility. Every day I try to learn, educate & share knowledge about accessible solutions. I’m also a casual platform gamer where I get inspired in accessibility solutions & inclusive story–telling. Currently working towards my IAAP CPWA certification (2021)