EAA Compliance Checklist for E-Commerce

Livana Team8 min29 April 2026

E-commerce is one of the sectors most directly affected by the European Accessibility Act. If you sell products or services online to EU consumers, your website must be accessible under EN 301 549, which maps to WCAG 2.1 Level AA for web content.

But WCAG has 50 Level A and AA success criteria, and applying them to an e-commerce site can feel overwhelming. This checklist breaks it down by page type and feature area, giving you actionable items you can assign to your development and content teams.

Before you start

Run an automated accessibility scan on your site to establish a baseline. Lumi's multi-engine scanner checks over 300 rules across five engines and gives you a prioritised list of issues. This helps you focus your manual review on the areas that need the most work.

Also check whether the EAA applies to your business using our EAA Scope Checker. Microenterprises (fewer than 10 employees, under two million euros turnover) are exempt from service requirements.

Site-wide requirements

These requirements apply across every page of your e-commerce site.

Navigation and structure

- [ ] **Skip navigation link** - provide a "skip to main content" link as the first focusable element on every page
- [ ] **Consistent navigation** - navigation menus appear in the same location and order on every page
- [ ] **Heading hierarchy** - use a logical heading structure (h1, h2, h3) that reflects the content hierarchy. Every page should have exactly one h1.
- [ ] **Landmark regions** - use semantic HTML landmarks (header, nav, main, footer) or ARIA roles to identify page regions
- [ ] **Page titles** - every page has a unique, descriptive title that reflects its content
- [ ] **Language attribute** - the html element has a lang attribute set to the correct language. Content in other languages is marked with the appropriate lang attribute.
- [ ] **Breadcrumbs** - if used, breadcrumbs are implemented with proper nav landmark and aria-label

Keyboard accessibility

- [ ] **All functionality keyboard-operable** - every interactive element (links, buttons, menus, modals, carousels) can be operated with keyboard alone
- [ ] **Visible focus indicators** - focused elements have a clearly visible outline or highlight that meets contrast requirements
- [ ] **Logical tab order** - the tab order follows the visual reading order of the page
- [ ] **No keyboard traps** - users can tab into and out of every component (modals, dropdown menus, embedded content)
- [ ] **Focus management for dynamic content** - when modals open, focus moves to the modal. When they close, focus returns to the trigger element.
- [ ] **Sticky headers don't obscure focused elements** - use scroll-padding-top to prevent fixed headers from hiding the focused element

Visual design

- [ ] **Text colour contrast** - minimum 4.5:1 ratio for normal text, 3:1 for large text (18pt or 14pt bold). Use our [Contrast Checker](/tools/contrast-checker) to verify.
- [ ] **Non-text contrast** - UI components and graphical objects have a minimum 3:1 contrast ratio against adjacent colours
- [ ] **Text resizable to 200%** - content remains readable and functional when text is resized to 200% without horizontal scrolling
- [ ] **Responsive layout** - content reflows at 320px width without loss of information or functionality
- [ ] **No information conveyed by colour alone** - links, error states, required fields, and status indicators use more than just colour (add icons, patterns, text, or underlines)
- [ ] **Motion and animation** - respect prefers-reduced-motion. Provide pause/stop controls for any auto-playing content.

Images and media

- [ ] **Alt text for product images** - every product image has descriptive alt text that conveys what the image shows. Avoid filenames like 'IMG_0034.jpg'.
- [ ] **Decorative images** - purely decorative images have empty alt attributes (alt="") so screen readers skip them
- [ ] **Complex images** - charts, infographics, and size guides have a longer text description available (via adjacent text or a details/summary)
- [ ] **Video captions** - all video content has synchronised captions
- [ ] **Audio descriptions** - if video content conveys visual information not available in the audio track, provide audio descriptions

Product listing pages

Category pages, search results, and product grids have specific accessibility considerations.

Product cards

- [ ] **Meaningful link text** - each product link includes the product name, not just "View" or "Click here"
- [ ] **Image alt text** - product thumbnail alt text includes the product name and key visual information
- [ ] **Price information accessible** - prices are presented as text (not images) and associated with the correct product
- [ ] **Sale/discount information** - if a product is on sale, both the original and sale price are available to screen readers with appropriate context
- [ ] **Rating information** - star ratings have a text alternative (e.g., "4.5 out of 5 stars based on 128 reviews")

Filters and sorting

- [ ] **Operable filters** - all filter controls (checkboxes, sliders, dropdowns) are keyboard accessible and properly labelled
- [ ] **Filter state announcements** - when filters are applied, screen reader users are informed of the updated results count
- [ ] **Price range sliders** - if you use a price range slider, provide an accessible alternative (text input fields for min/max values)
- [ ] **Sort controls labelled** - sort dropdowns have visible labels explaining what they sort
- [ ] **Active filters visible and removable** - applied filters are listed with a way to remove each one via keyboard

Pagination

- [ ] **Pagination links labelled** - links include "Page 1", "Page 2", etc., not just numbers without context
- [ ] **Current page identified** - the current page is indicated with aria-current="page"
- [ ] **Infinite scroll alternative** - if you use infinite scroll, provide a traditional pagination option. Infinite scroll is problematic for screen reader and keyboard users.

Product detail pages

Product pages are the core of any e-commerce site and have the most complex accessibility requirements.

Product information

- [ ] **Product name as h1** - the product name should be the page's h1 heading
- [ ] **Structured product data** - key product details (price, availability, specifications) are presented in properly structured HTML (definition lists, tables, or labelled paragraphs)
- [ ] **Size and colour options** - selection controls have visible labels. Colour swatches include text colour names, not just visual swatches.
- [ ] **Availability status** - stock status is communicated in text, not just through colour (red for out of stock, green for available)
- [ ] **Product descriptions** - long descriptions use proper heading structure and lists for scanability

Image galleries

- [ ] **Gallery navigation keyboard accessible** - previous/next buttons and thumbnail selectors work with keyboard
- [ ] **Zoomed images accessible** - image zoom functionality is keyboard operable with a clear way to exit
- [ ] **Gallery state communicated** - screen readers can tell which image is currently displayed (e.g., "Image 3 of 8")

Add to cart

- [ ] **Quantity input labelled** - the quantity input has an associated label
- [ ] **Add to cart confirmation** - when an item is added, the user receives an accessible notification (not just a visual animation). Use aria-live or a toast notification that's announced to screen readers.
- [ ] **Variant selection required** - if size/colour must be selected before adding to cart, required fields are clearly indicated and errors are announced

Shopping cart

- [ ] **Cart summary accessible** - the cart page clearly presents each item's name, quantity, individual price, and total price in a structured format
- [ ] **Quantity updates** - changing quantity is keyboard accessible, and the price update is announced to screen readers
- [ ] **Remove item** - the remove button is clearly labelled with the product name ("Remove Blue Widget", not just "X")
- [ ] **Cart total updated** - when quantities change or items are removed, the updated total is communicated to assistive technology
- [ ] **Proceed to checkout** - the checkout button is prominently placed and clearly labelled

Checkout

Checkout is the most critical flow for accessibility. An inaccessible checkout means users with disabilities literally cannot purchase from your store.

Forms

- [ ] **Every input has a visible label** - do not rely on placeholder text alone. Placeholders disappear when the user starts typing.
- [ ] **Required fields identified** - required fields are marked with both a visual indicator and aria-required="true"
- [ ] **Input purpose identified** - use autocomplete attributes (autocomplete="given-name", autocomplete="street-address", etc.) so browsers and assistive technology can help users fill in forms
- [ ] **Error identification** - when a form submission fails, errors are clearly identified, described in text, and associated with the specific field using aria-describedby
- [ ] **Error prevention** - for financial transactions, provide a review step before final submission, or allow users to undo the transaction

Address entry

- [ ] **Address autocomplete** - if you use an address autocomplete widget, ensure the suggestions list is keyboard navigable and announced to screen readers
- [ ] **Country/region selects** - dropdown lists for country and region are labelled and keyboard navigable
- [ ] **Postcode validation** - validation messages are associated with the field and announced when they appear

Payment

- [ ] **Payment method selection** - radio buttons or tabs for payment methods are properly labelled and keyboard accessible
- [ ] **Card number input** - the card number field has a label and appropriate autocomplete attribute (autocomplete="cc-number")
- [ ] **Third-party payment iframes** - if you embed a payment provider's iframe, verify it meets accessibility requirements. This is a common gap.
- [ ] **Security codes** - CVC/CVV inputs are labelled clearly. Don't use images to show where to find the code without providing alt text.

Order review and confirmation

- [ ] **Order summary accessible** - before final submission, present a clear, structured summary of the order
- [ ] **Confirmation page** - after purchase, the confirmation page clearly communicates the order was successful, includes the order number, and is accessible
- [ ] **Confirmation email** - order confirmation emails should be accessible (proper heading structure, alt text, sufficient contrast)

Account management

- [ ] **Registration form accessible** - all form fields labelled, errors identified, CAPTCHA alternatives provided if used
- [ ] **Login accessible** - the login form works with keyboard and screen readers. If you use social login buttons, they're properly labelled.
- [ ] **Password requirements** - if passwords must meet specific criteria, the requirements are communicated before and during entry, not just on error
- [ ] **Account dashboard** - order history, saved addresses, and account settings pages follow the same accessibility requirements as the rest of the site
- [ ] **CAPTCHA alternatives** - if you use CAPTCHA, provide an accessible alternative (audio CAPTCHA, logical questions, or invisible CAPTCHA). This aligns with WCAG 2.2's Accessible Authentication criteria.

Search

- [ ] **Search input labelled** - the search field has an accessible label (visible label, aria-label, or associated with a visually hidden label element)
- [ ] **Search suggestions accessible** - if you show autocomplete suggestions, the list is keyboard navigable, the current selection is announced, and Escape closes the suggestion list
- [ ] **No results messaging** - when a search returns no results, the message is clear and suggests alternative actions
- [ ] **Search results structured** - results use proper heading hierarchy and product cards follow the same requirements as listing pages

Accessibility statement

Every e-commerce site covered by the EAA should publish an accessibility statement. Our Accessibility Statement Generator creates one that meets EAA requirements. For a detailed guide on what to include, see our EAA Accessibility Statement Template.

Testing your compliance

This checklist covers the most important requirements, but it's not exhaustive. To ensure comprehensive coverage:

**Run an automated scan** - [Lumi](/) tests over 300 rules across five engines, catching issues that single-engine tools miss
**Test with keyboard only** - unplug your mouse and try to complete a purchase using only the keyboard
**Test with a screen reader** - use VoiceOver (Mac/iOS), NVDA (Windows), or TalkBack (Android) to navigate your site
**Check colour contrast** - use our [Contrast Checker](/tools/contrast-checker) to verify all text and UI components meet minimum ratios
**Test at 200% zoom** - resize text to 200% and verify everything remains usable
**Test on mobile** - verify touch targets are at least 24x24 CSS pixels (WCAG 2.2 Target Size requirement)