Why Accessibility Should Be Top of Mind in E-commerce
As accessibility standards become a legal requirement—not just a best practice—businesses can’t afford to ignore them, especially in the e-commerce space. I’ve spent the last decade building over 100 websites of all shapes and sizes. Along the way, I’ve learned a few things—not just about code, but about what makes a digital experience truly usable for everyone.
This article is a collection of practical advice, some war stories, and honest insights for anyone looking to build or redesign a Shopify store (or similar platform) with accessibility top of mind. Whether you’re a founder, designer, or junior dev looking to level up—there’s something here for you.
A Quick Background
I’m a Lead Engineer with 11 years of professional experience, currently leading a team at KNOCK, Inc. My background is a blend of design and engineering—I hold a B.S. in Web Design & Interactive Media from The Art Institutes International Minnesota. What started as a passion for object-oriented programming eventually became a full-time career after agencies like space150 and KNOCK took a chance on me.
I’ve built:
-
16+ large-scale sites
-
28 medium-sized projects
-
100+ campaign sites
-
500+ custom HTML emails (for brands like Lowe’s, American Express, Jostens, and Jack Link’s)
My bread and butter is taking a strong design vision and turning it into accessible, maintainable, performant code.
Choosing the Right Platform: Shopify vs WooCommerce
I’ve built four custom Shopify stores and two in WooCommerce. Each has its strengths—but regardless of platform, accessibility should never be an afterthought.
Theme First, Then Custom
If you’re building on Shopify or WooCommerce, the theme you choose can either set you up for success—or make accessibility much harder down the road.
Many store owners (or even designers) opt for heavy customization, but that can come with unintended consequences. If your site deviates from a theme’s native functionality, you may be responsible for accessibility compliance—and potentially liable for lawsuits if you fall short.
Pro tip: If you’re not deeply familiar with accessibility laws (WCAG 2.1 or the upcoming European Accessibility Act), consider working with an agency or developer experienced in compliance and inclusive design from the start.
The Developer vs. Designer-Developer Debate
Let’s be honest: the lines between designer and developer are getting blurry. But in my experience, there’s a big difference between someone who knows how to use tools—and someone who knows how to solve problems when tools fall short.
Why It Matters
Designers using site builders like Webflow, Editor X, or even Shopify’s drag-and-drop features can make impressive layouts—but they often lack the engineering expertise needed to fix accessibility barriers, integrate APIs, or troubleshoot performance issues.
A true developer or engineer will:
-
Understand semantic HTML and ARIA roles
-
Know how to audit for color contrast and keyboard navigation
-
Debug assistive technology issues (screen readers, voice controls, etc.)
-
Write scalable, maintainable, standards-based code
If you’re building a custom experience, don’t just hire someone who “knows Shopify.” Hire someone who knows how the web works.
Why Accessibility Isn’t Optional Anymore
Accessibility isn’t just about compliance—it’s about empathy. If your site isn’t usable by someone who is blind, has limited mobility, or is neurodiverse, you’re turning away customers. Period.
And with legislation tightening (especially in the EU), accessibility is becoming a non-negotiable business requirement.
When to Bring in the Pros
If your site gets:
-
Over 1,000 users a day
-
Generates over $200K/month
-
Offers essential services or products
…then you should absolutely partner with both a developer and an accessibility-focused testing service. I recommend teams like Allyant, who do real-world testing with users who are vision, mobility, or audio-impaired. They can even issue a Letter of Conformance for legal peace of mind.
What Tools and Audits Are Worth Your Time?
You don’t need an enterprise budget to get started. Here are some tools I recommend:
Free or Low-Cost Tools
-
axe DevTools (browser extension) – Great for spot-checking WCAG issues
-
Lighthouse (in Chrome DevTools) – Basic audits for performance and accessibility
-
WAVE Web Accessibility Tool – Quick overviews for contrast, structure, etc.
-
NVDA (Windows screen reader) or VoiceOver (Mac) – Test with real assistive tech
Manual Checks That Matter
-
Can you tab through your site without using a mouse?
-
Do all images have descriptive
alt
tags? -
Does every input (like a form field) have a properly associated label?
-
Is the color contrast readable in all light modes?
Accessible UX Writing: Words Matter More Than You Think
Accessibility isn’t just about structure and color contrast—it’s also about clarity.
The words you use across buttons, forms, links, and error messages play a huge role in how usable your site is for people with cognitive impairments, screen reader users, or people who don’t speak English as their first language.
Tips for Inclusive UX Writing
-
Avoid vague link text like “Click here” or “Learn more.” Instead, use descriptive links like “Download the pricing PDF” or “Explore our skincare collection.”
-
Write helpful form labels and error messages. Instead of just “Invalid input,” try “Please enter a valid email address.”
-
Keep language plain and readable. Shoot for a 6th–8th grade reading level when possible. Complex vocabulary creates unnecessary barriers.
-
Support localization. Ensure your copy is easily translatable and avoid idioms, which can be confusing when translated.
In other words: clear writing = better accessibility.
Integrating Accessibility Into Your Workflow with GitHub Actions
You don’t need a massive team to catch accessibility issues early. If your team uses GitHub, you can automate accessibility audits as part of your CI/CD process using GitHub Actions.
How It Works
You can configure a GitHub Action that runs tools like:
-
axe-core CLI
-
Pa11y
-
Lighthouse CI
These tools can:
-
Audit new code for WCAG violations
-
Catch regressions (like a missing
alt
tag) -
Post results directly into your pull requests
Why It Helps
-
Reduces manual testing burden
-
Helps junior devs learn best practices through feedback
-
Promotes accessibility as part of code quality, not an afterthought