Accessibility Essentials for Product Card Images: Alt Text, Roles, and Screen Readers

This guide explains how to make product card images accessible: writing purposeful alt text, choosing correct markup or roles for non-img visuals, structuring figure/caption relationships, and testing with screen readers and keyboards—so your e-commerce cards are usable for everyone. ⏱️ 5-min read

Alt text essentials for product card images

Alt text should answer the question “What does this image convey here?” Keep it brief and functional: describe the product and any critical variant or state the image shows. Avoid redundant UI words such as “image of” or “picture.” If the product name and a short descriptor are visible nearby, alt can be shorter or match that visible text so screen readers don't create a confusing wrap.

• Good: “Cedar wood dining chair, walnut finish” — concise, identifies product and variant.
• Better for promotional: “Cedar wood dining chair, walnut finish — on sale 20% off” — only if the image itself communicates the promotion.
• Bad: “Image of chair” or long lists of styling details that aren’t useful to purchase decisions.

If an image is the only place where information appears (e.g., a product is shown in a specific configuration that isn’t otherwise described), include that information in the alt text so it’s available to assistive tech.

Img vs decorative or background images

Decide whether each visual is content or decoration. If the image conveys product information or supports a link, use an actual <img> with meaningful alt text. If it’s purely decorative—ornamental borders, layout flourishes—hide it from assistive technology.

• Decorative <img>: use empty alt attribute alt="" and ensure no accessible name leakage.
• Decorative background images (CSS): keep them out of the accessibility tree; avoid giving them roles or ARIA labels.
• If a background image is the only way to convey product info, move it to an <img> so it can have alt text.

Roles and semantics for non-img elements

Sometimes product visuals are implemented with <div> or CSS backgrounds (for layout or performance reasons). If that element must be exposed to assistive tech as an image, use semantic affordances correctly.

• Use role="img" only when a non-img element genuinely represents an image that conveys content. Then provide an accessible name via aria-label or aria-labelledby.
• Example: <div role="img" aria-label="Blue running shoes, size 9"></div>
• Avoid role="img" + decorative copy; if decorative, add aria-hidden="true" instead.
• Do not rely on title attributes for accessibility—they are inconsistently supported and not a substitute for alt or ARIA naming.

Figure and caption structure

When an image needs a caption—price badges, variant descriptions, or usage notes—use semantic structure with <figure> and <figcaption>. This groups the visual with its explanatory text and creates a clear reading relationship for assistive technology.

• Example structure: a product image inside <figure> with <figcaption> containing the product name or short descriptor.
• If the image itself is also a link, keep the <a> inside the <figure> or wrap the <figure> with the link consistently, and ensure the accessible name is clear (avoid duplicate announcements).
• When visible text already describes the product, consider using alt="" and referencing the visible label with aria-labelledby for a single, coherent accessible name.

Screen reader testing and keyboard accessibility

Automated tools catch many issues, but manual testing with real assistive tech is essential. Test with VoiceOver (macOS/iOS), NVDA (Windows), and TalkBack (Android) and verify the keyboard tab order and focus behavior for product cards.

• Verify reading order: screen readers should encounter product name, price, and action in a logical sequence, and the image should not repeat information already read unnecessarily.
• Keyboard: links and interactive elements within the card must be reachable via Tab, have visible focus styles, and be operable by Enter/Space where appropriate.
• Use accessibility trees in developer tools (Chrome DevTools Accessibility panel, Safari Web Inspector) to confirm roles, names, and properties are exposed as intended.
• Include regular user testing with assistive tech users for the highest confidence.

Performance, responsiveness, and markup consistency

Accessible images also need to be performant and responsive. Use modern image techniques while preserving accessibility semantics.

• Serve responsive images with srcset and sizes so browsers pick the appropriate resolution. Alt text travels with the element regardless of source selection.
• Use loading="lazy" for off-screen product images; ensure lazy-loading does not delay meaningful accessible names or focusable elements being available to assistive tech.
• Keep markup consistent across product cards: consistent DOM order prevents surprise reading order and keeps keyboard navigation predictable.
• Avoid swapping DOM nodes in ways that remove accessible names or break relationships (e.g., moving the visible product name out of the logical sequence).

Common pitfalls and practical patterns

A few repeating mistakes cause most accessibility issues. Use these practical patterns to avoid them.

• Pitfall: Long, verbose alt text. Pattern: short, actionable alt that complements visible text—e.g., “Men’s waterproof jacket, forest green, medium”.
• Pitfall: Decorative images announced by screen readers. Pattern: mark purely decorative <img alt=""> or add aria-hidden="true" for non-img elements.
• Pitfall: Background images used for essential info. Pattern: convert to <img> or provide the info in accessible text adjacent to the image.
• Pitfall: Duplicate content read twice (image alt repeating visible title). Pattern: either keep alt="" if the visible title fully describes the image, or use aria-labelledby to point to the existing text to create a single accessible name.
• Pitfall: Non-semantic interaction (clickable <div>). Pattern: use native <button> or <a> when something is clickable; if you must use a non-semantic element, add role, keyboard handlers, and focus styles carefully.

Applying these principles will make your product cards more useful to screen reader users and more robust across devices: write purposeful alt text, expose only meaningful visuals, use semantic grouping with figure/figcaption, and test with real assistive technology and keyboard navigation.

Powered by Trafficontent