EAA Compliance for E-Commerce: What Online Retailers Need to Know

E-Commerce Is a Core Target of the EAA

If you run an online store that serves European consumers, the European Accessibility Act (EAA) applies directly to you. E-commerce is explicitly listed as a covered service category under Directive (EU) 2019/882 — making it one of the regulation's primary targets.

This isn't surprising. Online shopping has become essential to daily life, and the 87 million people with disabilities in the EU deserve the same seamless buying experience as everyone else. Yet most e-commerce sites are riddled with accessibility barriers — from unlabeled form fields to keyboard-inaccessible checkout flows.

Since June 28, 2025, compliance is mandatory. If you haven't started, now is the time. This guide walks you through every critical component of an accessible webshop, with practical tips you can implement today.

New to the EAA? Start with our complete guide to the European Accessibility Act.

---

Why E-Commerce Accessibility Matters Beyond Compliance

Before diving into the specifics, consider the business case. Accessible e-commerce isn't just about avoiding fines and penalties — it's a competitive advantage:

• Larger customer base — 16% of the global population has a disability. That's a massive market segment most online retailers ignore.
• Higher conversion rates — Accessible checkout flows reduce friction for all users, not just those with disabilities. Clear labels, logical tab order, and readable error messages improve completion rates across the board.
• Better SEO — Semantic HTML, descriptive alt text, and proper heading structures are both accessibility requirements and search engine ranking factors.
• Mobile-first alignment — Many accessibility best practices (large tap targets, readable text, logical flow) directly improve the mobile shopping experience.

An inaccessible webshop doesn't just exclude people — it leaks revenue.

---

Product Pages: The Foundation of Accessible Shopping

Product pages are where buying decisions happen. If users can't perceive, understand, or interact with your product information, they can't buy.

Product Images

Images are the centerpiece of any product page, and they're also one of the most common accessibility failures.

Requirements:

• Every product image needs descriptive alt text that conveys what the image shows. "Blue cotton t-shirt, crew neck, front view" is useful. "IMG_4523.jpg" is not.
• Decorative images (backgrounds, dividers) should use alt="" so screen readers skip them.
• Image galleries and carousels must be keyboard-navigable. Users should be able to cycle through images using arrow keys or tab.
• Zoom functionality must work without a mouse. If you offer image zoom on hover, provide an equivalent keyboard-activated alternative.

Tip: For products with multiple variants (colors, sizes), ensure the alt text updates dynamically when the user selects a different variant.

Product Descriptions

• Use proper heading hierarchy (H2 for the product name, H3 for sections like "Features," "Specifications," "Reviews").
• Break long descriptions into scannable sections with bullet points and short paragraphs.
• Avoid conveying critical information only through color. If a product is "available" in green and "out of stock" in red, add a text label too.
• Ensure pricing information is programmatically associated with the product and readable by screen readers. Don't embed prices in images.

Product Variants and Options

Size selectors, color pickers, and configuration options are often custom-built components that break accessibility.

• Custom dropdowns must implement proper ARIA roles (role="listbox", role="option") and keyboard interaction patterns.
• Color swatches need text labels — not just colored circles. A visually impaired user can't distinguish "Navy" from "Black" by color alone.
• When a variant selection changes the price, availability, or images, announce the change to assistive technology using aria-live regions.

---

Search and Filtering: Helping Users Find Products

E-commerce sites often have thousands of products. Search and filtering are essential — and frequently inaccessible.

Search Functionality

• The search input must have a visible label or accessible name (via aria-label or associated <label>).
• Autocomplete suggestions must be navigable by keyboard (arrow keys to browse, Enter to select, Escape to dismiss).
• Announce the number of results after a search completes. Use an aria-live region: "Showing 24 results for 'running shoes'."
• Ensure the search results page uses proper heading structure so users can jump directly to results.

Filters and Faceted Navigation

Filters are one of the trickiest components to make accessible. Common patterns include checkboxes, sliders, and expandable filter groups.

Best practices:

• Checkbox filters (brand, size, color) should use native <input type="checkbox"> elements with associated <label> elements. Custom-styled checkboxes must maintain keyboard focusability and announce their state.
• Price range sliders must be operable by keyboard. Use role="slider" with aria-valuemin, aria-valuemax, and aria-valuenow. Better yet, provide text input fields as an alternative to the slider.
• When filters update results dynamically (without a page reload), announce the updated result count using aria-live="polite".
• Expandable filter sections (accordion pattern) should use aria-expanded to communicate their open/closed state.

Common mistake: Many e-commerce sites use JavaScript-only click handlers on <div> or <span> elements for filters. These are completely invisible to keyboard and screen reader users. Always use semantic HTML elements or add proper ARIA roles and keyboard handlers.

---

Forms: Account Creation, Addresses, and Contact

E-commerce is form-heavy. Account registration, shipping addresses, billing details, contact forms — each one is an opportunity for accessibility failure.

Form Fundamentals

Every form on your site should follow these principles:

1. Every input needs a label. Use <label for="inputId"> to programmatically associate labels with inputs. Placeholder text is not a substitute for labels — it disappears when the user starts typing.

2. Group related fields. Use <fieldset> and <legend> for logical groupings like "Shipping Address" or "Payment Method."

3. Error handling must be accessible.

   • Identify errors in text, not just color. A red border alone isn't enough — add a message like "Please enter a valid email address."
   • Use aria-describedby to associate error messages with their input fields.
   • On submission failure, move focus to the first error or provide an error summary at the top of the form.
   • Use aria-invalid="true" on fields with errors.

4. Required fields must be indicated both visually (asterisk) and programmatically (aria-required="true" or the required attribute).

Address Forms

• Autocomplete attributes (autocomplete="shipping street-address", autocomplete="billing postal-code") help all users and are especially valuable for those using assistive technology.
• Country/region selectors should use native <select> elements when possible. If you use a custom searchable dropdown, ensure it follows the ARIA combobox pattern.

---

Checkout Flow: Where Accessibility Failures Cost You Sales

The checkout is your highest-value page. It's also where accessibility barriers cause the most damage — users who can't complete checkout leave and don't come back.

Multi-Step Checkout

If your checkout uses multiple steps (cart → shipping → payment → confirmation), make the process clear and navigable:

• Step indicators must be accessible. "Step 2 of 4: Shipping Information" should be announced to screen readers, not just shown visually as a progress bar.
• Users must be able to navigate back to previous steps using keyboard.
• Don't use time limits on checkout steps. If you must (for flash sales or seat reservations), warn users and allow them to extend the time. This is a WCAG 2.2 Level A requirement (2.2.1 Timing Adjustable).

Cart and Order Summary

• The cart summary should use a structured format (table or definition list) that clearly associates each item with its quantity, price, and subtotal.
• "Remove item" and "Update quantity" controls must be keyboard accessible and have clear accessible names. A trash can icon without a label is meaningless to screen reader users.
• When the cart updates (item removed, quantity changed), announce the change using an aria-live region. "Item removed. Cart total: €47.50."

Payment

• Payment method selection (credit card, PayPal, iDEAL) should use radio buttons or a proper role="radiogroup" pattern.
• Credit card inputs need clear labels ("Card number," "Expiry date MM/YY," "CVV"). Don't rely on placeholder text or card icons alone.
• If you use third-party payment widgets (Stripe Elements, Adyen, Mollie), check their accessibility. Most major providers have improved significantly, but you're still responsible for the end-user experience.
• 3D Secure and authentication pop-ups must be keyboard accessible. Test the entire payment flow, including redirects and iframes.

Order Confirmation

• The confirmation page should clearly communicate the order status with text, not just a green checkmark icon.
• Confirmation emails should be accessible too — use semantic HTML in email templates, not image-only layouts.
• Provide a clear path to order tracking and customer support from the confirmation page.

---

Navigation and Site Structure

Main Navigation

• Navigation menus must be fully keyboard accessible. Users should be able to open submenus, navigate between items, and close menus using standard keys (Tab, Arrow keys, Enter, Escape).
• Mega menus are common in e-commerce and notoriously difficult to make accessible. Test thoroughly with keyboard and screen readers.
• Provide skip navigation links ("Skip to main content," "Skip to search") as the first focusable elements on the page.

Breadcrumbs

• Use <nav aria-label="Breadcrumb"> with an ordered list structure.
• The current page in the breadcrumb should use aria-current="page".

Pagination

• Pagination controls must be keyboard accessible and clearly labeled.
• The current page should be indicated both visually and programmatically.
• "Load more" buttons and infinite scroll patterns must be accessible. Infinite scroll, in particular, can be extremely disorienting for screen reader users — consider offering a paginated alternative.

---

Beyond the Basics: Additional E-Commerce Considerations

Customer Reviews

• Review submission forms must be accessible (labeled inputs, accessible star ratings).
• Star ratings displayed as images need alt text ("4 out of 5 stars"). Interactive star ratings must be keyboard operable.

Live Chat and Support

• Chat widgets must be keyboard accessible and work with screen readers.
• If you use chatbots, ensure the conversation interface is properly structured with ARIA live regions to announce new messages.

Promotional Banners and Pop-ups

• Modal dialogs (newsletter sign-ups, cookie consent, promotional overlays) must trap focus within the modal and return focus to the trigger element on close.
• Banners with auto-rotating content must have pause controls (WCAG 2.2.2) and must not auto-advance faster than users can read.
• Dismiss buttons must be clearly labeled and keyboard accessible — not just a tiny "×" icon with no accessible name.

Wishlists and Saved Items

• "Add to wishlist" and "Save for later" buttons need accessible names that include the product: "Add Blue Running Shoes to wishlist" is better than just a heart icon.

---

Testing Your E-Commerce Site for Accessibility

Automated scanners are a great starting point, but they catch only 30–50% of accessibility issues. For an e-commerce site, you need to supplement with manual testing:

1. Keyboard-only testing — Navigate your entire purchase flow (search → product → cart → checkout → confirmation) using only the keyboard. Can you complete a purchase without a mouse?
2. Screen reader testing — Test with NVDA (Windows), VoiceOver (Mac/iOS), or TalkBack (Android). Pay special attention to dynamic content (cart updates, filter changes, error messages).
3. Zoom and text resize — Zoom to 200% and ensure no content is cut off or overlapping, especially in checkout forms.
4. Color contrast — Verify that all text meets the 4.5:1 contrast ratio for normal text and 3:1 for large text (WCAG 1.4.3).

For a comprehensive testing approach, see our WCAG 2.2 beginner's guide which covers all four WCAG principles in detail.

---

Your E-Commerce Accessibility Action Plan

Getting your webshop EAA-compliant doesn't require rebuilding from scratch. Start with the highest-impact areas:

1. Audit first — Scan your site to identify existing violations and prioritize by severity.
2. Fix the checkout — This is your highest-value flow. Make it fully keyboard and screen reader accessible.
3. Address product pages — Alt text, headings, variant selectors, and pricing.
4. Tackle search and filters — Ensure users can actually find your products.
5. Handle forms — Labels, error handling, autocomplete attributes.
6. Test end-to-end — Complete a full purchase using only a keyboard, then with a screen reader.

Need a prioritized list? Our EAA compliance checklist walks you through 15 steps from initial audit to ongoing monitoring.

---

Start With a Free Scan

Not sure where your webshop stands? Find out in 60 seconds.

Scan your e-commerce site for free → Our automated WCAG 2.2 scanner identifies accessibility violations across your product pages, checkout flow, and navigation — and gives you a prioritized action plan to fix them.

The EAA is in effect. Your competitors are already working on compliance. Don't let accessibility barriers cost you customers — or invite regulatory action.