Five accessibility barriers that keep showing up on e-commerce product pages
Across the e-commerce sites we scan, a handful of the same issues turn up again and again. They are not exotic edge cases. They are common patterns baked into popular themes and component libraries, repeated across thousands of stores, and usually fixable with a handful of lines of HTML. Here are the five we flag most consistently on product pages, what they break, and the specific change that resolves each one.
1. Product images with no alt text
The axe-core rule is image-alt. WCAG success criterion 1.1.1 requires that every meaningful image have a text alternative. A screen reader user shopping for a blue cotton t-shirt should hear "Blue cotton t-shirt, front view," not "image" or a filename like "pdp_hero_v3_FINAL.jpg."
The broken pattern:
<img src="product-hero.jpg">The fix for an informative product image:
<img src="product-hero.jpg" alt="Blue cotton t-shirt, front view">For a purely decorative image, one that adds no information a sighted user relies on, the correct alt value is an empty string, which tells the screen reader to skip it:
<img src="texture-bg.jpg" alt="">The problem shows up everywhere: lifestyle images, swatches, trust badge logos, and promotional banners. The quickest audit is a grep or a browser extension that highlights images without alt attributes. The harder part is writing good alt text for each one, but even a generic description is better than a missing attribute.
2. Icon-only buttons with no accessible name
The axe rule is button-name. On a product grid with thirty items, each with a wishlist heart and a quick-add button, a screen reader user navigating by button hears "button, button, button" with no way to tell which product each one belongs to. WCAG 4.1.2 requires every interactive control to have a programmatic name.
The broken pattern, an SVG icon with no label:
<button>
<svg viewBox="0 0 24 24">...</svg>
</button>The fix:
<button aria-label="Add Blue T-Shirt to wishlist">
<svg aria-hidden="true" viewBox="0 0 24 24">...</svg>
</button>Two things to notice: the button gets an aria-label that identifies both the action and the specific item, and the SVG gets aria-hidden="true" so the screen reader does not also try to announce the icon's internal structure. Including the product name in the label is important when the same button pattern repeats across a grid.
One trap: aria-label="" (empty string) explicitly removes the accessible name. It is worse than no label at all. If you see buttons with empty aria-label attributes, that is the issue.
3. Form fields without programmatic labels
The axe rule is label. Size selectors, color dropdowns, quantity inputs, email fields on newsletter signups, and most fields in checkout flows need a label element associated with them. Placeholder text does not count: it disappears when someone starts typing, and screen readers do not treat it as a label even when the field is empty.
The broken pattern:
<select name="size">
<option>Select size</option>
<option>S</option>
<option>M</option>
</select>The fix using a visible label:
<label for="size-select">Size</label>
<select id="size-select" name="size">
<option>Select size</option>
<option value="S">Small</option>
<option value="M">Medium</option>
</select>The for attribute on the label must match the id on the input exactly. If you cannot change the visual layout, aria-label or aria-labelledby on the input element work too, though a visible label is better for everyone, not just screen reader users.
This issue appears frequently on custom dropdown components that replace native selects. The custom element gets none of the semantics the browser provides for free, and the developer has to add them back manually.
4. Color contrast failures on secondary text
The axe rule is color-contrast. WCAG 1.4.3 requires a minimum contrast ratio of 4.5:1 for body text and 3:1 for large text (18px normal weight or 14px bold). The failures we see most often are not the dramatic ones; they are subtle. Light gray secondary text on white: "Sold out," "3 items left," size guide links. White text on a light product photo. Small-print promotional copy against a pale brand color.
The fix is usually a color value change. Browser devtools include a contrast ratio display in the color picker. The WebAIM contrast checker takes two hex values and tells you exactly where you stand. A common approach is darkening the text color by enough steps to clear 4.5:1 while staying close enough to the original brand palette that the design team accepts it.
Contrast failures are the highest-volume finding by instance count in most of our reports. A single low-contrast text style used site-wide can generate hundreds of flagged elements. The root cause is usually that the color was chosen visually on a high-quality monitor in a well-lit office. It passes for many sighted users while failing for others, including people with low vision who have not been diagnosed with any condition.
5. Links with no descriptive name
The axe rule is link-name. Screen reader users can pull up a list of all links on a page and navigate between them. If every product card links to a product page but the link wraps only an image with no alt text, the list reads as a series of unlabeled "link" entries. If the nav uses icon links to social media profiles with no accessible names, those entries are also blank.
Three patterns that each cause this:
Linked images without alt text:
<a href="/products/blue-shirt">
<img src="blue-shirt.jpg">
</a>Fix: add meaningful alt text to the image.
Icon-only links:
<a href="https://instagram.com/brandname">
<svg viewBox="0 0 24 24">...</svg>
</a>Fix:
<a href="https://instagram.com/brandname" aria-label="Follow us on Instagram">
<svg aria-hidden="true" viewBox="0 0 24 24">...</svg>
</a>Vague link text: "Click here," "Read more," and "Learn more" links that are not differentiated by context. When someone reads the link list, they hear four "learn more" entries with no way to know what they lead to. Fix: rewrite to "Learn more about size and fit," "Read the full ingredient list," and so on.
What to do next
These five patterns, image alt text, unlabeled buttons, unlabeled form fields, color contrast, and unlabeled links, account for the majority of the findings in our scan reports. They are not the only accessibility issues a site can have, but they are the ones that come up first when you scan and the ones most worth addressing before moving on to more specialized work.
The fastest way to see which of these are present on your own site is to request a free homepage scan. The report names each instance, links to the specific element, and includes a concrete code fix for each finding.