Accessible Product Pages: Variants, Gallery, Add to Cart

The colour swatch is a particularly common finding on product pages because it is so inconspicuous. A round dot of colour shows sighted users which colour is meant – but only as long as they can reliably tell colours apart and recognise the swatch as selectable at all. WCAG requires that colour is not the only visual means of conveying information or distinguishing an element (W3C, WCAG 2.2, SC 1.4.1). For variant selection this means: next to the swatch stands the colour name, visible or at least as text after selection ("Colour: Sage green"). And the selected state is shown not only by a different border colour but also by a check mark or a clearly thicker frame.

Technically, a variant selection is a group of options with exactly one selected. That is exactly what native radio buttons are for: a fieldset with a legend ("Colour"), containing one input type="radio" per variant with a visible or accessible name. Name, role and state of every variant can then be programmatically determined, as SC 4.1.2 requires for all controls (W3C, WCAG 2.2, SC 4.1.2). Whoever builds div elements with click handlers instead has to recreate role, state and keyboard operation and in practice often forgets at least one of them. The keyboard convention for radio groups is defined: Tab moves into and out of the group, the arrow keys change the selection within it (W3C WAI, ARIA Authoring Practices, Radio Group).

On the product page the gallery often carries more information than the description: back view, lining, stitching detail, size comparison on the model. Every view is therefore an image with its own purpose and needs its own alternative text, not the product name five times. WCAG requires a text alternative for all non-text content that serves the equivalent purpose (W3C, WCAG 2.2, SC 1.1.1). WebAIM's home page survey shows how widespread the gap is: 16.2 percent of all images lack alternative text (WebAIM Million, 2026). How good descriptions for product images come about is covered in the article on images and alt text.

The thumbnails below the main image are controls, not decoration. As buttons with names ("View 3 of 5: lining") and a state for the current view, they can be reached by keyboard and told apart by ear. This is where a common finding lies: about 9 percent of desktop buttons and 11 percent on mobile have no accessible name (Web Almanac, 2025). Left and right arrows, the magnifier and the close cross of the full-screen view are the typical candidates because they only show an icon. If the gallery runs as a carousel, the rules from our article on sliders and carousels apply as well.

Zoom and full screen are two different patterns. A magnifier that shows an enlarged section when the mouse hovers over the image can only be operated with a pointer – yet all functionality must also be available through the keyboard (W3C, WCAG 2.2, SC 2.1.1). Content that additionally appears on pointer hover or focus must also be dismissible, hoverable and persistent for as long as it is needed (W3C, WCAG 2.2, SC 1.4.13). Full-screen mode is a dialog: on opening, focus moves into it, Escape closes it, and focus then returns to the element that opened the dialog (W3C WAI, ARIA Authoring Practices, Dialog). What else goes wrong with modal layers is described in the article on modals and overlays.

The quantity selector usually consists of a number field and two icon buttons. The field needs a label ("Quantity"), the buttons need names ("Decrease quantity", "Increase quantity") – a minus and a plus sign alone are read as "minus" or not at all. If a click changes the number, the field itself carries the new value so that the screen reader announces it at the next focus. Plus and minus, like all targets, are at least 24 by 24 CSS pixels (W3C, WCAG 2.2, SC 2.5.8); on a phone they otherwise sit close to the edge of the quantity field and are easily missed.

The size chart is a real data table and should be marked up as one: with caption and column and row headers (th with scope), so that a screen reader moving through the cells announces size and measurement together, for example "Size M, chest" followed by the value. Structure and relationships that are visually recognisable must be programmatically determinable (W3C, WCAG 2.2, SC 1.3.1). A size chart as an image does not meet this, nor does a grid of div elements. If the chart opens in its own layer, the same rules apply as for the gallery's full-screen view. Details on header cells and captions are in the article on data tables and complex content.

Delivery time and availability often appear as a coloured dot: green for in stock, yellow for few left, red for sold out. This is exactly the case SC 1.4.1 rules out when the text next to it is missing (W3C, WCAG 2.2, SC 1.4.1). A short sentence such as "In stock, delivery in one to two working days" carries the same information for everyone. Normal text requires a contrast of at least 4.5:1 (W3C, WCAG 2.2, SC 1.4.3) – delivery notes in light green or orange easily miss this value. Low contrast text was found on 83.9 percent of the home pages examined (WebAIM Million, 2026).

The star rating is a graphic with a number inside it. Five star icons, four and a half of them filled, need a text alternative such as "4.5 out of 5 stars" together with the number of reviews – as one continuous text, not as five separate images with the alternative text "star". If the rating is a link to the review section further down, the link text names that destination. Stars as input in a review form, on the other hand, are again a radio group, and the same rules apply as for variant selection.

The following table summarises what we check in a product template. It is organised by component, not by success criterion, because development teams think in components and fix findings there. The criteria in the third column come from WCAG 2.2, which for conformance is usually tested at level AA.

The product page is not the only template of a shop, but one with particularly high leverage: it is served very often, and it is where the purchase decision is made. Whoever builds it accessibly removes a large share of findings from the whole range before checkout is even reached. The same approach applies to the rest: home page, category page, search, cart, checkout and customer account are each one template that is audited thoroughly once. Which barriers affect older customers in particular is covered in our article on older customers; the buttons for withdrawal and cancellation are covered in the article on the accessible withdrawal button.

For online shops aimed at consumers, the product page usually falls within the scope of the Act; exceptions apply, among others, to micro-enterprises providing services. A violation can be fined up to one hundred thousand euros (BFSG, section 37). In everyday business, however, what is lost at a silent add-to-cart button often weighs more: a purchase that never happens appears in no complaint and in no statistic.

The effort for this lies almost entirely in the template. The data – colour names, image descriptions, unit prices, delivery times – is usually already available in the merchandise management system; what is missing is its output in the right place. A change to the template takes effect on every product page after the next rollout, and the audit can be repeated with every new version of the template.