What a screen reader user hears on your product page, and how to fix it

A screen reader user hears your product page as a sequence of announcements: the page title, then each heading, link, image description, button and form field, with its role ("button", "link", "heading level 2") and its state ("selected", "expanded", "dimmed"). They hear only what is in the code. A price that is just red text, a colour swatch with no name, or a cart update shown only visually is silent or confusing. You fix it with real headings, named buttons, proper form controls and announced status messages.

Most screen reader users do not listen from top to bottom. In WebAIM's 2026 survey of 1,780 screen reader users, 67.8% said that on a long page they first navigate through the headings, and 91.8% use a screen reader on a mobile device.¹ So a product page has to make sense heading by heading, and on a phone.

A product page, as it might sound

Here is an illustration of two versions of the same page, written the way a screen reader reads them out. The exact words vary between screen readers and browsers, but the difference is typical.

Before

• "Link, graphic, logo underscore final dot png."
• "Button." "Button." "Button, 2."
• "Linen shirt." (bold text, not a heading)
• "45 dollars. 60 dollars."
• "Clickable." "Clickable." "Clickable." (colour swatches)
• "Edit text, blank." (quantity)
• "Add to cart, button." Then nothing.

After

• "Link, Acme Outdoor, home."
• "Search, button." "Account, link." "Cart, 2 items, link."
• "Heading level 1, Linen shirt."
• "Sale price 45 dollars. Regular price 60 dollars."
• "Colour, Sage, radio button, checked, 1 of 3."
• "Quantity, spin button, 1."
• "Add to cart, button." Then: "Linen shirt added to cart. Cart, 3 items."

Every difference between the two comes from the code. The rest of this post goes through them.

1. Headings: the outline of the page

WCAG 1.3.1 asks that structure shown visually is also available in code, and headings are its first example: text that looks like a heading must be marked up as one.² On a product page, a sensible outline is one h1 for the product name, then h2 headings for sections such as Description, Size and fit, Delivery and returns, Reviews and You may also like. Shopify's theme guidance says the same: use headings for structure in sequence, not for visual size, with h1 for the page's main topic.⁵

2. Images: describe what a buyer needs

Each product photo needs a text alternative that serves the same purpose as the image; decorative images should be hidden from screen readers.⁹ With no alt attribute at all, a screen reader may read out the file name instead, which is how a customer ends up hearing "logo underscore final dot png". Describe what each photo shows that matters to a buyer: colour, material, detail, scale. Our guide to alt text that actually helps has examples.

3. Buttons and links: every one needs a name

Icon buttons, such as search, cart, wishlist, close, next and previous, often have no text. WebAIM found empty buttons on 30.6% and empty links on 46.3% of the top million home pages in 2026.⁶ A screen reader announces them as "button" with nothing else. Give each a name with visually hidden text or an aria-label: "Search", "Open cart, 2 items", "Next image".

Use the right element too. Shopify's guidance is to use a for navigation and button for actions.⁵ A div scripted to behave like a button has no role, so it is not announced as a button and may not be reachable by keyboard; W3C lists it as a failure of 4.1.2 Name, Role, Value.³

4. Prices: make sale prices make sense

A sale is usually shown with a struck-through regular price next to the new one. Strikethrough is visual, so a screen reader may read both numbers with nothing to tell them apart. Shopify's theme guidance is to label sale and regular prices with visually hidden text.⁵ W3C makes a related point about colour: a price shown in red needs something besides the red, such as a word or currency symbol, to carry its meaning.²

Unit prices, "from" prices and "sold out" labels need the same care. If a badge says "Sold out" only as an image, it needs alt text; if it is text, make sure it is near the product name in the reading order.

5. Variant pickers: name, role and state

Colour and size swatches are the most common problem on product pages. A swatch built as a coloured box gives a screen reader nothing to announce. W3C's 4.1.2 asks that every control exposes its name, its role, and its state, such as whether it is selected, and that changes to the state are announced.³ W3C also notes that standard HTML controls already do this when used as intended.³ The reliable fix is a group of real radio buttons, styled as swatches, inside a fieldset whose legend is "Colour", with each option's name as its label. Out-of-stock options should say so in text, not only with a diagonal line through the swatch.

6. Changes on the page: announce them

When a customer picks a variant, the price, stock message and sometimes the main image change. When they press Add to cart, the cart count changes or a drawer opens. A sighted customer sees it; a screen reader user hears nothing unless the change is announced.

WCAG 4.1.3 Status Messages (level AA) covers this. W3C's own example is a shopping cart: after adding an item, text near the cart icon updates to the item count and should be announced, ideally as a phrase such as "5 items" rather than just the number.⁴ Shopify's guidance is to announce variant price and availability changes with aria-live.⁵ If a cart drawer opens, treat it as a dialog: move focus into it and let Escape close it.⁵

How to listen to your own product page

1. Start a screen reader. On Windows, NVDA is free and open source.⁷ On a Mac, VoiceOver is built in and turns on with Command-F5.⁸
2. Open a product page and list the headings. Most screen readers have a headings list. Is the product name the first-level heading? Do the sections make sense out of context?
3. Tab through the page and listen to each control. Write down any "button" with no name, any "clickable" without a role, and any file name read out.
4. Choose a variant and add to cart. Did you hear the price change and the confirmation?
5. Read the price with the arrow keys. Can you tell the sale price from the regular one?

Automated checks help with the countable parts: missing alt text, buttons and links with no name, form fields without labels. Jralo's free check runs those tests on your homepage and up to five pages linked from it, and also says which countries' accessibility laws are likely relevant to your store. Whether a description is useful, or whether a variant change is announced, needs a person listening; see why automated testing finds some problems but not all.

Most of these fixes live in the product template, so one change in the theme fixes every product at once. Alt text is the exception: that is content you add product by product.