Web accessibility for small e-commerce stores
The common assumption is that accessibility is a large-company problem: enterprise stores with dedicated engineering teams, legal departments reviewing every release, and budgets for expensive manual audits. Small stores, the thinking goes, can skip it.
That assumption is wrong in a specific way. The accessibility issues that show up on e-commerce sites do not depend on how large the store is. They depend on the platform and the theme. If two stores both run on the same Shopify theme, they will have largely the same accessibility gaps, regardless of whether one has 50 products and one has 5,000.
Where small store issues come from
Most small e-commerce stores run on Shopify, WooCommerce, or BigCommerce, often using a purchased or free theme as the starting point. The accessibility gaps that appear in scans are almost always baked into the theme's component choices:
- Product image carousels that use icon-only previous/next buttons with no accessible names
- Wishlist and quick-add buttons built as bare icon elements with no
aria-label - Size or color selector dropdowns with no associated
labelelement - Color swatch buttons that are visually labeled by their color but have no text equivalent
- Newsletter sign-up forms where the submit button is an arrow icon with no text
None of these are the store owner's choices in any direct sense. They come with the theme. That also means the fix is often narrow: a targeted change to a specific component, not a full redesign.
What typical findings look like on a small store
When we scan a small Shopify or WooCommerce store, the most common categories of findings are:
Image alt text: Product images, lifestyle photos, and promotional banners often have no alt attribute at all, or an empty one where a description should be. A screen reader user cannot tell what the image shows. For a product page, that breaks the shopping experience entirely.
Unlabeled form fields: Size selectors, color pickers, quantity inputs, and email newsletter fields frequently lack a programmatic label. Placeholder text inside the input does not substitute for a label: it disappears when the user starts typing, and screen readers do not treat it as a label even when the field is empty.
Unlabeled interactive buttons: Icon buttons (wishlist, cart, quick-add, close) built with SVG icons and no accessible name are invisible to keyboard and screen reader navigation. A user cannot tell what action a button performs without being able to see the icon.
Color contrast: Light gray text on white backgrounds, muted promotional text, and low-contrast color swatches frequently fall below the 4.5:1 contrast ratio required for readable body text. Contrast failures affect users with low vision and anyone reading in bright light.
The specific counts vary by theme and content, but these four categories account for the majority of what appears in scans of small stores.
What fixing these actually costs
The fixes for most common accessibility issues are HTML-level changes: adding an attribute here, associating a label element there. A front-end developer familiar with the theme can typically address a specific component failure in under an hour. The harder part is identifying which components have the issue and what the correct fix is for that specific implementation.
A concrete example: if a theme has 30 product cards on a grid page, each with an unlabeled wishlist button, that shows up as one issue type with 30 instances. The fix is a one-line change to the button template. Once you have identified the exact component and the correct attribute, the implementation is straightforward.
That said, some findings require judgment: writing accurate alt text for product images, for example, means someone has to look at each image and write a description that conveys what a sighted shopper sees. That scales with catalog size in a way that HTML attribute changes do not.
The case for ongoing monitoring over a one-time fix
A one-time scan tells you where your store stands today. It does not tell you where it will stand after the next theme update, the next Shopify release, or the next seasonal promotion that uses a new banner template. New content introduces new issues, and theme updates sometimes change component behavior in ways that break accessibility attributes that were previously set correctly.
For a small store that deploys changes every few weeks, the relevant question is not "is the store accessible today?" but "will I know when it stops being accessible?" Monthly or weekly scanning answers that question by comparing the current state against a baseline and surfacing anything that changed.
This is the core argument for monitoring as distinct from an audit: an audit is a point-in-time measurement, and a site that passes today can fail next month without anyone noticing.
When a one-time baseline audit is the right starting point
If you have never had your store scanned, a baseline audit makes sense before committing to ongoing monitoring. The baseline tells you what you are starting from: a prioritized list of every issue the scanner finds across your pages, with the specific HTML location, the WCAG rule it violates, and the fix. That gives you and your developer a concrete remediation list.
Once the high-priority issues are addressed, monitoring keeps the baseline from drifting back as the site evolves.
What automated scanning covers and does not cover
Automated scanners, including ours, catch a specific class of accessibility issues: those that can be determined from the HTML structure without a human reading or navigating the page. WCAG 2.1 AA covers a broader scope than automated tools can reach: things like whether focus order makes logical sense, whether complex interactive patterns (data tables, multi-step flows) are navigable in a coherent way, and whether alt text is actually descriptive rather than just present.
Published research places the proportion of WCAG issues that automated scanning can detect at roughly 30 to 57 percent of all issue types, depending on the tool and methodology. The issues automated tools catch reliably are the high-frequency, high-impact ones: missing alt text, unlabeled form fields, unlabeled buttons, color contrast failures, and ARIA implementation errors. Those categories account for the majority of issues cited in ADA web cases against e-commerce sites.
A full manual audit, where a trained tester uses a screen reader and keyboard navigation to work through the site, is more thorough. It is also more expensive and does not scale to monthly cadences. For most small stores, automated scanning catches the issues that matter most and provides the kind of regular feedback that keeps a site from accumulating unaddressed problems over time.
Where to start
The fastest way to understand what your store actually has is to run a scan and read the findings. Our free homepage scan covers the critical and serious issues on your main page in about 60 seconds. If you want to see what a full multi-page report looks like before committing, the sample report shows real findings from a real scan.
For stores where the homepage scan finds critical issues, a full baseline audit (covering your product pages, category pages, and checkout flow) gives you a prioritized list to hand to a developer. From there, ongoing monitoring keeps the work from undoing itself.