How to spot common accessibility issues on your e-commerce site
The most common way to discover that your site has accessibility problems is to receive an automated scan report. But before requesting a scan, or after receiving one and wanting to see the issues yourself, these four methods let you check directly in a browser. They require only a keyboard and the developer tools built into Chrome or Firefox. They do not catch everything, but they surface the failures that appear most often across e-commerce sites.
1. The keyboard navigation test
The majority of accessibility issues on e-commerce sites affect users who cannot use a mouse: people using screen readers, voice control software, switch access devices, or who simply prefer keyboard navigation. You can reproduce their experience in about five minutes.
Press Tab to move forward through interactive elements on any page, and Shift+Tab to move backwards. At each step, ask:
- Is there a visible indicator showing which element has focus? There should be an outline, highlight, or other visual cue. If nothing is visible, the site has suppressed browser focus styles, which is a serious usability problem for keyboard users.
- Does Tab move in a sensible order? It should follow the visual layout: navigation first, then main content, then footers and supplementary elements. Jumping between unrelated sections is disorienting.
- Can you activate every button and link using Enter or Space?
- If a modal or dropdown opens (a filter panel, a size selector, a cookie notice), can you navigate within it and close it without using a mouse?
Common failures: focus goes invisible partway through the page (the site applies outline: none globally in CSS), or Tab enters a modal and cannot escape, leaving the user trapped. Either one blocks a keyboard user from completing a purchase.
Try this on your homepage, a product page, and your checkout flow. The checkout flow is the highest-priority path because a keyboard user who cannot complete checkout cannot buy.
2. The image alt text check
In Chrome, right-click any image and choose Inspect. In the Elements panel, look at the img element. Find the alt attribute and check its value.
What you might see:
<!-- Missing entirely: screen reader announces the filename -->
<img src="hero.jpg">
<!-- Empty string: correct for purely decorative images -->
<img src="background-texture.jpg" alt="">
<!-- Filename leaked into alt text: still useless -->
<img src="pdp_hero_v3_FINAL.jpg" alt="pdp_hero_v3_FINAL.jpg">
<!-- Meaningful alt text: correct for product images -->
<img src="blue-shirt.jpg" alt="Blue cotton crew neck t-shirt, front view">On a product listing page, check 10 to 15 product images. If most have no alt attribute or have the filename as alt text, that is a missing alt text failure across the product catalog. Apply the same check to promotional banners, trust badge logos, and hero images: those are meaningful images that need descriptive text, not decorative ones that should have alt="".
The distinction matters: a decorative background texture should have alt="" so the screen reader ignores it. A product image showing a specific item should have text that describes what it shows, so a shopper who cannot see it still gets the information.
3. The color contrast check
Chrome DevTools includes a contrast ratio display in its color picker. Open DevTools (F12, or Cmd-Option-I on Mac), select any text element in the Elements panel, and click the colored square next to the color property in the Styles panel. The color picker shows a contrast ratio at the bottom.
The thresholds from WCAG 1.4.3:
- Normal text (below 18px regular weight or 14px bold): 4.5:1 or higher
- Large text (18px+ or bold 14px+): 3:1 or higher
The failures that appear most often on e-commerce sites are not the dramatic ones. They are the subtle choices made during design: a "Sold out" badge in light gray on white, a promotional discount label in white over a light product photo, small-print shipping notes in a brand secondary color that looked fine on a calibrated studio monitor. Check those elements specifically, because they are the ones most likely to fail.
If you want to test any two hex colors without opening DevTools, the WebAIM contrast checker at webaim.org/resources/contrastchecker takes two values and returns the ratio immediately.
4. The form label check
Click on any input field in DevTools and look at the element. A field is properly labeled if it has one of the following:
<!-- Visible label with matching id/for -->
<label for="size-select">Size</label>
<select id="size-select" name="size">...</select>
<!-- aria-label directly on the input -->
<input type="email" aria-label="Email address">
<!-- aria-labelledby pointing to a visible element -->
<input type="text" aria-labelledby="quantity-heading">If none of these are present, the field has no programmatic label. Placeholder text does not count: it disappears as soon as someone starts typing, and assistive technology does not treat it as a label even when the field is empty.
Check specifically: the size selector on product pages, any quantity input, newsletter signup fields, and each field in your checkout flow. Custom dropdown components that replace native selects are particularly likely to be missing labels, because building a custom select means giving up the semantics the browser provides for free and adding them back manually.
The axe DevTools extension
If you want a more systematic scan rather than a manual element-by-element check, the axe DevTools browser extension runs the same core test suite as our scanner. It is free, available for Chrome and Firefox, and takes about 30 seconds to run on any page.
Install it from the Chrome Web Store (search "axe DevTools"), open any page, open DevTools, go to the axe tab, and click Analyze. Each result shows the issue type, the severity, which element triggered it, and a link to the relevant WCAG criterion with an explanation.
One important caveat: axe DevTools catches the same category of issues that all automated tools catch, roughly 30 to 57 percent of WCAG issue types. Color contrast, missing alt text, form labels, and ARIA structure errors are reliably detected. Cognitive accessibility issues, video caption quality, and focus order problems that only appear during interaction require manual testing. Axe is a good diagnostic tool; it is not a comprehensive pass/fail test.
What these checks tell you
Keyboard navigation, image alt text, color contrast, and form labels map to the four WCAG success criteria that account for the majority of the findings in automated accessibility reports. Running these checks yourself takes about 15 minutes and gives you an accurate picture of where the most common structural failures are on your site.
A full automated scan covers all 26 of these testable pattern types across every page of your site, identifies each affected element with its CSS selector, and includes a concrete code fix for each finding. If you want that for your site, request a free homepage scan and we will send the report within a few hours.