Monthly Accessibility Maintenance for eCommerce

A male figure holding a wrench to a laptop screen. the laptop screen has a warning sign on it. In the background various tools are seen with nuts and cogs.

Ecommerce websites typically change a lot. Products are added and removed. Prices are changed. Images and product descriptions are updated. New features are added.

Because of all this change, it’s crucial that eCommerce websites (and really all websites with a lot of change) understand that accessibility is maintained over time. Just like SEO (search engine optimization).

This post outlines a suggested checklist for monthly accessibility maintenance of an eCommerce website. It’s not exhaustive by any means, but it’s a good start.

Check for product changes

The first thing to check for are new products that have been added in the last month AND products that have been updated. If you don’t already have installed some sort of history or audit plugin on the site to quickly help you know what been updated or changed, you may want to get one installed. Our team likes the Simple History plugin that’s free from the WordPress directory.

For each new or updated product, quickly check:

Check plugins with front end output that updated

While WooCommerce as a base plugin is fairly accessible out-of-the-box, it’s not uncommon at all for plugins (or custom coding) that affects front end output to create accessibility barriers. Ideally, you’ve already checked on this sitewide previously and fixed any barriers. It doesn’t happen frequently, but any time a plugin or custom coding gets updated, it carries the potential to create new barriers so this is something that you will want to check.

An auditing plugin like Simple History (mentioned above) can help you find which plugins have been updated in the last month. If you have custom coded functionalities that have been updated, you’ll want to check those too, although it may be harder to track when those changes may have happened. Check the functionality that this plugin or custom coding creates, especially looking at:

  • Keyboard navigability: can you use your keyboard to navigate through the feature? Learn to test keyboard navigation.
  • Forms/input fields have HTML labels. Open the Inspector, inspect a form field and look for something like: <label for="{someID}">Email</label>
  • Any interactive components like buttons must meet color contrast guidelines and size guidelines (in WCAG 2.2 AA, they must be 24 x 24 pixels or larger)

There may be other things that you need to check depending on the specific functionality that’s being created.

Test keyboard navigation for checkout

As a monthly practice, it’s not a bad idea to quickly make sure that your purchase tthrough check out journey is keyboard navigable. After all, a customer actually making a purchase is the main function of your website and if they encounter a barrier to checking out you are losing sales. This may require learning a little bit about keyboard navigation, but it should take you only a few minutes to perform and it’s worth the time to test this on your site regularly.

See the above link for other tips, but to test the purchase through check out journey:

  • Put away your mouse and use only your keyboard. You will primarily use the tab, enter, spacebar and arrow keys.
  • Navigate to a product, and if your site uses product filtering make sure you include that in your testing. You are looking for any selectors/inputs that aren’t reachable via the keyboard navigation.
  • Make sure that you can change the quantity before you put the product in the cart.
  • Get the product into your cart, make sure you can change the quantity after it’s in the cart.
  • Make sure you can get to the coupon field to put in a coupon code if you have this on your site.
  • Get through the rest of the checkout process to near the very end, although it’s probably not necessary to actually checkout. Can you interact with all the fields and buttons to get the sale completed (or all but the last submit)?
  • Try leaving out some required info, and make sure that the error reporting is not ambiguous. Ideally if you leave out your ZIP code, you see “your zip/postal code is required” vs. “there was an error”.

Prevent issues before they are published

While this may not work for every eCommerce website, if your site has drafts of new products that will be published or new landing pages that are being worked on for future launch, your accessibility maintenance check is a great opportunity to check those ahead of time for any accessibility issues. See the list above in the products section for what to check.

Ideally, an accessibility check before publication can become a regular part of your QA (quality assurance) process to prevent accessibility barriers from ever embarrassing the shop publicly.


When there are a lot of moving and changing parts on eCommerce sites, it’s crucial to regularly test those changes for accessibility barriers. Making sure everyone can use your site is not just about legal compliance, it’s a smart business move to make sure that customers can purchase your products!

If you would like help with regular accessibility maintenance, our Accessibility Maintenance Plans are designed to provide this sort of support along with documenting reporting that may be an important resource in the case of a lawsuit or complaint.

AccessiCart logo

Our Accessibility Maintenance Plans help you remove barriers for people with disabilities and meet legal requirements with confidence.

Written by


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.