AccessScanRun a free scan

Guide

Retail Website Accessibility: A Practical Guide for Fashion and E-Commerce Brands

Retail website accessibility is no longer a nice-to-have for fashion and e-commerce brands selling in Europe. Since 28 June 2025, the European Accessibility Act has treated consumer e-commerce as a covered service, with WCAG 2.2 Level A and AA as the technical baseline through the harmonised standard EN 301 549.

Compliance aside, the shopping journey on a typical fashion site is full of places where disabled customers quietly give up: a product photo with no alt text, a colour swatch you can only tell apart by sight, a filter panel you cannot operate by keyboard, a checkout that rejects a pasted address. Every one of those is a lost sale.

This guide walks the real retail funnel, from product imagery to checkout, and shows what to fix and which success criteria apply.

Product imagery and alt text: where most retail sites fail first

Fashion sites are image-heavy by nature, which makes alt text the highest-leverage fix in retail website accessibility. The rule is about function, not decoration. The primary product photo and any image that carries buying information must be described; purely decorative styling shots should be skipped.

  • Primary product image: describe the item, the key visible attributes, and the colour. 'Cropped wool-blend cardigan in charcoal, buttoned front' beats 'IMG_4821.jpg' or 'cardigan'.
  • Detail and zoom shots: name what they add ('Close-up of mother-of-pearl buttons and ribbed cuff') so a non-sighted shopper gets the same information a sighted one gets from the gallery.
  • Decorative lifestyle and banner images: use an empty alt attribute (alt="") so assistive technology passes over them rather than reading a filename.
  • Text baked into a sale graphic ('30% off') must appear in the alt text or as real HTML, or screen reader users miss the offer entirely.

Avoid stuffing keywords or repeating the product title verbatim when it already sits next to the image, since the screen reader will announce both. Text alternatives that fail to convey purpose are a 1.1.1 Non-text Content failure.

Size and colour selectors that work without a mouse or sight

Variant pickers are where the WCAG 2.2 additions bite hardest in fashion. Colour swatches and size chips are usually built as custom controls, and three things go wrong repeatedly.

Don't rely on colour alone

A swatch that is only a coloured circle fails 1.4.1 Use of Color and is invisible to screen readers. Give each swatch an accessible name ('Colour: sage green') and a visible selected state that does not depend solely on a coloured ring, for example a checkmark or a clear border plus an offset outline. Sold-out variants need a text or programmatic indicator, not just a greyed-out tint.

Hit targets and dragging

WCAG 2.2 added 2.5.8 Target Size (Minimum), Level AA, which expects interactive targets of at least 24 by 24 CSS pixels (with defined exceptions). Tightly packed size chips ('XS S M L XL') often fail this. SC 2.5.7 Dragging Movements (AA) also requires that anything operated by dragging, such as a zoom slider or a swipeable lookbook, has a single-pointer alternative like tap or arrow buttons.

Announce the change

When selecting a colour swaps the gallery or updates the price, sighted users see it instantly; others need SC 4.1.3 Status Messages (AA). Use an ARIA live region so the new selection ('Sage green selected, in stock') is announced without moving focus. Build the selectors as a proper radio group and they get keyboard support for free.

Filters, facets, and 'load more': the keyboard test

Category and search pages live or die on filters, and these are frequently keyboard traps. Walk your own facet panel using only the Tab, arrow, and Enter keys.

  • Every checkbox, price slider, and 'apply' button must be reachable and operable by keyboard, with a clear focus indicator (2.4.7 Focus Visible, AA). A faint browser default outline removed by CSS and never replaced is a top failure.
  • When results update after a filter is applied, announce the count via a live region ('48 results') so screen reader users know something happened (4.1.3 Status Messages).
  • 'Load more' and infinite scroll must not strand keyboard focus or hide it behind a sticky header. WCAG 2.2's 2.4.11 Focus Not Obscured (Minimum), Level AA, means the focused element cannot be fully covered by your sticky filter bar or cookie notice.
  • Price range sliders built with drag-only handles fail 2.5.7; add keyboard increment and a numeric input fallback.

Focus order, traps, and visible indicators are the underlying techniques to get right here, and they map directly to the operable principle in WCAG.

Cart, checkout, and the EAA stakes

Checkout is the conversion point and the highest-risk surface. Form failures here are both lost revenue and direct EAA exposure, because payment and account flows are exactly what enforcement bodies scrutinise.

  • Label every field properly (3.3.2 Labels or Instructions) and tie error messages to their inputs so a screen reader announces what went wrong and where (3.3.1 Error Identification).
  • WCAG 2.2's 3.3.7 Redundant Entry (A) means you should not force shoppers to re-type information already given, such as making them re-enter a shipping address as the billing address with no 'same as' option.
  • 3.3.8 Accessible Authentication (Minimum), Level AA, means login and guest-checkout flows must not depend on a cognitive function test like solving a puzzle or transcribing characters. Allow password managers and paste; do not block it.
  • 3.2.6 Consistent Help (A) expects support entry points (chat, contact, returns) to appear in a consistent relative order across pages.

Test that text can be resized to 200% (1.4.4 Resize Text, AA) and that the layout reflows to a single column at 320 CSS pixels without horizontal scrolling (1.4.10 Reflow, AA), since many shoppers complete checkout on a phone. Check 1.4.12 Text Spacing too, so user-applied spacing does not clip labels or buttons.

Why this matters now: the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025 and covers consumer e-commerce alongside banking, e-books and e-readers, electronic communications, audiovisual media access services, transport services, and self-service terminals such as ATMs and ticketing machines. The conformance baseline is WCAG 2.2 Level A and AA, referenced through the harmonised standard EN 301 549.

Member states enforce the EAA through national law: Germany via the Barrierefreiheitsstaerkungsgesetz (BFSG), in force since 28 June 2025; France via the RGAA, aligned with EN 301 549 and WCAG; and Italy via the Legge Stanca with AgID guidelines. A brand selling into multiple EU markets faces one technical bar, WCAG 2.2 AA, but several national enforcement regimes.

The defensible position is to fix the underlying markup, test with a keyboard and a real screen reader, and publish an honest accessibility statement. Overlay widgets do not satisfy this; they patch presentation, not the code that gets assessed. For background, see the European Accessibility Act and EN 301 549 pages.

A starting checklist for retail teams

You do not need to boil the ocean. Prioritise the templates that every shopper passes through: product detail page, category/filter page, cart, and checkout. Fixing those four covers most of the funnel and most of your risk.

  • Audit alt text on product and gallery images; set decorative images to empty alt.
  • Make colour and size selectors keyboard-operable, named, and not colour-only, with a 24 by 24 CSS pixel minimum target.
  • Keyboard-test filters end to end and announce result counts.
  • Harden checkout: labels, linked errors, no redundant entry, paste-friendly authentication, 200% zoom, reflow at 320px.
  • Publish a real accessibility statement and keep it current.

Run a free baseline scan from the AccessScan homepage to see where your top templates stand against WCAG 2.2, then generate a starting accessibility statement once you know your status. Automated tools catch a meaningful share of issues, but variant selectors and checkout flows still need a manual keyboard and screen reader pass.

Check your site against AccessScan

See your issues ranked by impact in seconds — free.

Run a free accessibility scan

FAQ

Does the European Accessibility Act apply to my online fashion store?

If you sell to consumers in the EU, almost certainly yes. The EAA (Directive (EU) 2019/882) treats consumer e-commerce as a covered service and has applied since 28 June 2025. The technical baseline is WCAG 2.2 Level A and AA via the harmonised standard EN 301 549. National laws implement it: Germany through the BFSG, France through the RGAA, and Italy through the Legge Stanca with AgID guidelines. A microenterprise exemption exists for some service providers, but many established retail brands will not qualify; check the thresholds in your national law.

What is the single most common accessibility failure on retail product pages?

Missing or useless alt text on product images, closely followed by colour swatches conveyed by colour alone. Both are easy wins. Write alt text that names the product, key visible attributes, and colour ('Relaxed-fit linen blazer in sage green, front view'), and give every swatch a programmatic name plus a visible selected state that does not rely on a coloured ring.

Do decorative lifestyle photos need alt text?

No. Purely decorative imagery should have an empty alt attribute (alt="") so screen readers skip it. The product's primary image and any image carrying buying information (colour, pattern, fit, graphic detail) must have descriptive alt text. The mistake to avoid is the reverse: leaving the main product photo empty while a background banner gets a paragraph of description.

Are accessibility overlay widgets enough for EAA compliance?

No. Overlay scripts do not fix the underlying HTML, and conformance is assessed on the actual code and user experience, not the presence of a widget. They often introduce new keyboard and focus problems. The defensible path is to fix the markup, test with a keyboard and a screen reader, document conformance honestly, and publish an accessibility statement describing real status and known limitations.

More guides