Understanding EAA compliance requirements for e-commerce: A technical perspective

The European Accessibility Act (EAA) has hundreds of pages of technical requirements your e-commerce site needs to meet. While the marketing team worries about brand messaging, you're staring at thousands of lines of code, wondering where to start.

The reality? Most e-commerce stores have significant web accessibility gaps. Scan results consistently show fundamental issues with keyboard navigation, screen reader compatibility, and form validation; all core components of EAA compliance. Non-compliance can trigger enforcement actions and penalties under the national laws that implement the Directive, and it may also create commercial and reputational risk

But this isn't about scaring you with penalties or preaching about inclusivity (though including 135 million Europeans with disabilities in your customer base is just good business). This is about giving you — the person implementing these changes — a clear technical roadmap for EAA compliance without breaking your site, your budget, or your launch schedule.

By the time you finish this guide, you'll have a checklist of technical requirements, code-level implementation strategies, and the testing tools you need to verify compliance.

What the EAA demands from e-commerce sites

The EU Accessibility Act codifies the Web Content Accessibility Guidelines (WCAG) 2.1 AA standard into law for e-commerce. That means your site must aim for "good practice" and meet legal requirements with technical precision.

For in-scope e-commerce services, the EAA (Directive (EU) 2019/882) sets legal accessibility requirements in its annexes. In practice, many teams use WCAG-based criteria and related standards to help meet those legal requirements.”

Let's clarify what this means for your site.

Not all criteria are created equal

For e-commerce services provided to consumers, the EAA applies from 28 June 2025 and requires meeting the applicable accessibility requirements in Annex I. WCAG 2.x Level A/AA is commonly used as a practical benchmark for web content, but the legal requirements are those set out in the Directive.

For e-commerce sites, the technical implications run deeper than for general websites. Your product listings, dynamic filtering, cart functionality, and checkout process all contain unique accessibility challenges that basic WCAG accessibility compliance guides don't fully address.

Some WCAG guidelines hit e-commerce sites particularly hard. Keyboard accessibility (2.1.1) affects every clickable thing on your site, from navigation menus to those tiny "add to wishlist" icons. Nothing — absolutely nothing — can require a mouse.

Focus management (2.4.3, 2.4.7) lets users tell where they are on your page. You need visible focus indicators on every interactive element and a logical tab order as users navigate your interface. No more invisible focus states or random tabbing sequences.

Code wrangling time: Where the real work begins

Let's decode what this means for your tech stack. The core technical components requiring attention include your HTML structure, CSS implementations, JavaScript behaviors, and API interactions. Each area needs methodical evaluation and likely modification.

In practice, meeting the EAA’s accessibility requirements for e-commerce services typically means using semantic, programmatically determinable structure (e.g., headings, lists, landmarks), which aligns with WCAG techniques and assistive-technology support.

For product catalogs (the heart of any e-commerce platform) you need accessible controls for filtering and sorting that work without a mouse. Keyboard users must be able to navigate through thousands of products. This requires careful JavaScript event handling and focus management that many popular e-commerce frameworks don't implement by default.

WCAG's responsive design requirements (1.4.4, 1.4.10) present unique challenges for e-commerce layouts. Your site must work perfectly at 200 percent zoom without horizontal scrolling or loss of functionality. Those complex product filter sidebars and multi-column layouts? They need to reflow perfectly on any device size.

Text alternatives (1.1.1) go beyond adding alt text to product photos. Your icons, meaningful background images, and complex visualizations, like size charts, all need text equivalents. If it conveys information visually, it needs a text alternative. No exceptions.

When your cart doesn't talk, customers walk

Dynamic content updates, like adding items to carts or adjusting quantities, require ARIA live regions to announce changes to screen reader users. Without these, a blind user might never know their action succeeded. And those fancy modal pop-ups for quick-view product details? They need proper focus trapping and escape key handlers to prevent keyboard users from getting stranded.

The checkout challenge: Where compliance meets conversion

Input assistance (3.3.1, 3.3.3, 3.3.4) makes or breaks your checkout process. You need clear error identification, helpful suggestions, and prevention mechanisms that help users complete forms. A confusing checkout form is non-compliant and costs you money.

Perhaps most critically, your checkout process must work flawlessly with assistive technologies. Form fields need explicit labels (not just placeholders), error messages must be programmatically associated with their fields, and payment gateways need keyboard operability.

If users with disabilities can’t complete a purchase due to accessibility barriers, that’s a serious accessibility failure and may indicate non-conformance with applicable EAA requirements (as implemented in national law), as well as lost revenue.

Once you understand the technical depth of these requirements, prioritize your resources. Some fixes might be as simple as adding attributes to existing elements. Others might require rebuilding entire components from the ground up. Knowing which is which saves time and budget.

Stop procrastinating, start Implementing: Your sprint-by-sprint guide

Most technical teams underestimate the scope of accessibility remediation. What seems like "just adding some alt text" quickly expands into rebuilding core components when you discover your third-party carousel plugin has no keyboard support or your filtering system requires JavaScript rewrites.

The audit: Where hope meets reality

Start with a comprehensive technical accessibility audit focused specifically on e-commerce functionality. This isn't just running an automated scanner (though tools like Siteimprove Accessibility can help identify issues). You need to manually test critical user paths, like browsing products, filtering results, adding to cart, and checking out, using only a keyboard and a screen reader.

Documentation is critical here. Map each accessibility issue to specific code locations and WCAG success criteria. Prioritize fixes based on user impact and technical complexity. Some issues might require simple HTML attribute additions, while others might mean refactoring entire components.

Your audit should identify significant accessibility barriers across your site — those issues that completely prevent users from completing tasks, not just minor inconveniences. These barriers become your highest-priority fixes.

First steps: Gain momentum with quick wins

Begin by tackling the low-hanging fruit. Missing alt text, poor color contrast, and basic keyboard traps; these issues often take minutes to fix but deliver immediate accessibility improvements. Knock these out while you're developing strategies for the more complex components.

Create an accessibility pattern library tailored to your e-commerce platform. Build a collection of pre-approved, accessible components — product cards, filter widgets, quantity selectors — so developers can grab and go without reinventing accessible components every time. Document each pattern with clear accessibility notes and implementation guidelines.

The three phases of panic (and progress)

Most e-commerce sites go through three distinct phases of accessibility implementation (and mild developer panic):

• Phase 1: Foundation repairs. Fix your structural HTML, improve semantics, add ARIA (Accessible Rich Internet Applications) attributes where needed, and make sure basic keyboard functionality works. Budget 2-3 development sprints, but expect massive accessibility improvements immediately.
• Phase 2: Interactive element surgery. This is where you tackle those complex bits like product filters, quantity adjusters, and cart functionality. Your existing plugins will probably fall short, so prepare to write custom JavaScript solutions. Budget 3-4 sprints, including testing with real assistive technologies, not just simulation.
• Phase 3: Checkout trauma. This is where compliance meets conversion, and third-party payment processors complicate everything. Your checkout and payment flows need flawless accessibility, or you're leaving money on the table. Budget at least two sprints plus extra time to wrangle with payment providers about their accessibility issues.

Don't attempt a massive accessibility overhaul in one giant push. Spread changes across several deployment cycles, focusing first on money-making paths like checkout flows, search functions, and product browsing. This staged approach lets you test without bringing down your entire site.

The expert advantage

Hire accessibility specialists if your team is new to this. Yes, it costs money. No, it's not as expensive as getting it wrong repeatedly. The right expert saves weeks of development time and prevents expensive mistakes. A technical accessibility consultant who knows e-commerce can give you code-level guidance that fast-tracks your compliance efforts.

Bring actual disabled users into your testing process. Meeting technical standards doesn't guarantee usability. Real people who use screen readers, keyboard navigation, and other assistive technologies will find issues that no automated tool catches. Have them test your most important user flows, especially the ones that lead to purchases.

Remember that behind all these technical accessibility requirements are humans buying your products. While this article focuses on compliance, your goal is to create an e-commerce experience that works for everyone.

Best practices for creating an accessible e-commerce store

Knowing accessibility principles is one thing. Implementing them in code is where teams hit the wall.

Product grids: More than pretty pictures

The product grid displays your merchandise in rows and columns. It's the heart of any e-commerce site and the first thing most customers interact with.

Why it matters: Screen reader users navigate digital content differently than visual users. A poorly structured product grid is like a maze without signposts for these users.

Most developers build product grids like this:

<div class="product-grid">

  <div class="product">

    <img src="product.jpg">

    <div class="name">Product Name</div>

    <div class="price">$99.99</div>

    <button>Add to Cart</button>

  </div>

  <!-- More products... -->

</div>

The problem: This code uses generic <div> containers that don't communicate any meaning to screen readers. It's like having a store with no signs, labels, or organization.

Here's how to build it properly:

<ul class="product-grid">

  <li class="product">

    <img src="product.jpg" alt="Brief product description">

    <h3 class="name">Product Name</h3>

    <p class="price" aria-label="Price: 99 dollars and 99 cents">$99.99</p>

    <button aria-label="Add Product Name to cart">Add to Cart</button>

  </li>

  <!-- More products... -->

</ul>

The solution: This improved version uses semantic HTML elements (<ul>, <li>, <h3>, <p>) that communicates structure to screen readers. The alt and -label attributes provide additional context about images and actions.

This gives screen reader users clear navigation points and shows the relationships between elements. Plus, it's cleaner and more semantic, anyway.

Filter this: Make complex controls accessible

Product filters allow customers to narrow down options by features like size, color, or price. This is a critical shopping tool for large inventories.

Why it matters: Many custom filter designs look pretty but break keyboard navigation and screen reader functionality, locking out users with disabilities.

The most common mistake is replacing standard form controls with custom DIVs that can't receive keyboard focus. Instead, keep the native functionality and style it properly:

<div class="filter-group">

  <h4 id="size-heading">Size</h4>

  <div role="group" aria-labelledby="size-heading">

    <label class="filter-option">

      <input type="checkbox" name="size" value="small">

      Small

    </label>

    <label class="filter-option">

      <input type="checkbox" name="size" value="medium">

      Medium

    </label>

    <!-- More options... -->

  </div>

</div>

The solution: This approach maintains standard HTML checkboxes that support keyboard access (Tab and Space keys). The aria-labelledby connects the heading to the filter group, helping screen reader users understand what they're filtering. You can style these controls with CSS while preserving their accessibility.

Plus one, minus none: Quantity selectors that work

Quantity selectors let customers choose how many of an item to purchase (those little +/- controls next to a number input).

Why it matters: Most quantity selectors only work with mouse clicks, preventing keyboard-only users from purchasing multiple items.

Those tiny +/- quantity controls? Most only work with mouse clicks, leaving keyboard users unable to buy more than one item. Here's how to fix them:

<div class="quantity-control" role="group" aria-label="Quantity">

  <button type="button" class="decrement" aria-label="Decrease quantity">−</button>

  <input

    id="quantity"

    name="quantity"

    type="number"

    value="1"

    min="1"

    max="99"

    inputmode="numeric"

    aria-label="Quantity"

  >

  <button type="button" class="increment" aria-label="Increase quantity">+</button>

</div>

The solution: This implementation uses proper <button> elements that receive keyboard focus and can be activated with Enter or Space keys. The aria-label attributes clearly describe each button's purpose to screen reader users.

Add JavaScript that handles both clicks and keyboard events (especially Enter and Space keys), and suddenly, all users can adjust quantities without frustration.

Error messages that help

Error messages appear when customers make mistakes in forms, especially during checkout; like entering an invalid email or forgetting to fill a required field.

Why it matters: Most sites display errors in ways screen readers completely ignore, leaving users with disabilities unaware of what went wrong or how to fix it.

Form errors during checkout can make or break a sale. Do this instead:

<div class="form-field">

  <label for="email">Email address</label>

  <input

    type="email"

    id="email"

    name="email"

    autocomplete="email"

    aria-describedby=""

  >

  <!-- Render/show this only when invalid -->

  <p id="email-error" class="error" role="alert" hidden>

    Please enter a valid email address.

  </p>

</div>

Example JS to toggle it:

const email = document.getElementById('email');

const err = document.getElementById('email-error');

 

function showEmailError(message) {

  err.textContent = message;

  err.hidden = false;

  email.setAttribute('aria-invalid', 'true');

  email.setAttribute('aria-describedby', 'email-error');

}

 

function clearEmailError() {

  err.hidden = true;

  email.removeAttribute('aria-invalid');

  email.setAttribute('aria-describedby', '');

}

The solution: This pattern creates a programmatic relationship between the form field and its error message using aria-describedby. The role="alert" and aria-describedby attributes make sure screen readers announce the error when it appears. This code tells assistive technology: "Hey, there's a problem with this field, and here's how to fix it."

Modal traps: The good kind

Modal dialogs (popups) display additional content or actions while temporarily blocking interaction with the page underneath—commonly used for quick-view product details.

Why it matters: Without proper "focus trapping," keyboard users get lost behind the modal with no way to interact with or close it, locking them out of your site.

Here's the code you need:

let lastFocusedElement = null;

 

function openModal() {

  const modal = document.getElementById('quick-view-modal');

  if (!modal) return;

 

  lastFocusedElement = document.activeElement;

 

  // Make sure the modal itself can receive focus if needed

  if (!modal.hasAttribute('tabindex')) modal.setAttribute('tabindex', '-1');

 

  // Focusable elements inside the modal (filtering out disabled/hidden)

  const getFocusable = () =>

    Array.from(

      modal.querySelectorAll(

        'a[href], button:not([disabled]), input:not([disabled]), select:not([disabled]), textarea:not([disabled]), [tabindex]:not([tabindex="-1"])'

      )

    ).filter(el => el.offsetParent !== null);

 

  const onKeyDown = (e) => {

    if (e.key === 'Escape') {

      e.preventDefault();

      closeModal();

      return;

    }

 

    if (e.key !== 'Tab') return;

 

    const focusable = getFocusable();

    if (focusable.length === 0) {

      e.preventDefault();

      modal.focus();

      return;

    }

 

    const first = focusable[0];

    const last = focusable[focusable.length - 1];

 

    // If focus escaped the modal for any reason, pull it back in

    if (!modal.contains(document.activeElement)) {

      e.preventDefault();

      first.focus();

      return;

    }

 

    if (e.shiftKey && document.activeElement === first) {

      e.preventDefault();

      last.focus();

    } else if (!e.shiftKey && document.activeElement === last) {

      e.preventDefault();

      first.focus();

    }

  };

 

  // Prevent duplicate listeners if openModal is called repeatedly

  modal.removeEventListener('keydown', modal.__trapHandler);

  modal.__trapHandler = onKeyDown;

  modal.addEventListener('keydown', onKeyDown);

 

  // Initial focus: first focusable, otherwise the modal container

  const focusable = getFocusable();

  (focusable[0] || modal).focus();

 

  // Your existing "show" logic goes here (class toggle, aria-hidden, etc.)

  modal.classList.add('is-open');

  modal.removeAttribute('aria-hidden');

}

 

function closeModal() {

  const modal = document.getElementById('quick-view-modal');

  if (!modal) return;

 

  // Your existing "hide" logic goes here

  modal.classList.remove('is-open');

  modal.setAttribute('aria-hidden', 'true');

 

  if (modal.__trapHandler) {

    modal.removeEventListener('keydown', modal.__trapHandler);

  }

 

  if (lastFocusedElement && typeof lastFocusedElement.focus === 'function') {

    lastFocusedElement.focus();

  }

  lastFocusedElement = null;

}

The solution: This JavaScript creates a "loop" of focusable elements inside the modal. When users reach the last element and press Tab, they circle back to the first element instead of escaping to the main page. The code also makes sure the Escape key closes the modal. Think of it as creating a temporary "room" where keyboard focus can't leave until the user closes the modal.

These patterns fix the most common e-commerce accessibility problems, but your site probably has unique components that need special attention. Document your solutions thoroughly for future development and to prove your EAA compliance efforts.

Test like a user — not just a developer (top tools)

You can't verify compliance by eyeballing your site. You need proper testing tools and methods. The right tools turn an overwhelming audit process into something manageable and thorough.

Ditch the checkbox mentality

Start with automated scanning tools as your first defense. Siteimprove Accessibility runs comprehensive checks against WCAG 2.1 criteria and flags technical issues automatically. Better yet, it gives you actual code examples for fixes, not just vague warnings.

An unwanted truth: Automated tools catch only about half of accessibility issues. The other half needs manual testing, especially for complex e-commerce accessibility features. You'll need more specialized tools in your arsenal.

Browser developer tools now come with accessibility inspectors built in. Chrome's Accessibility tab in DevTools or Firefox's Accessibility Inspector show you the "accessibility tree" (aka how screen readers see your page). These tools catch missing labels, improper ARIA roles, and structural problems that automated scans miss.

Hear what your customers hear

You must test with actual screen readers. No shortcuts here. For Windows, download NVDA (it's free and what many real users actually use). On Mac, VoiceOver is already built in (press Command+F5). Put on headphones, close your eyes, and try to buy something on your site. The experience will be eye-opening . . . or rather, ear-opening.

Don't forget keyboard testing tools like Tab Stop Checker. They reveal which elements your keyboard can't reach and where your tab order jumps around chaotically. Keyboard navigation issues are among the most common accessibility failures in e-commerce, and they're relatively easy to fix.

The overlay illusion: why shortcuts fail

Beware of overlays that claim to ‘fix everything’ with one line of JavaScript. They can leave underlying accessibility issues unresolved and may not be sufficient to meet your accessibility obligations. The most reliable approach is proper implementation at the code level. No shortcuts, no magic widgets, no fairy dust.

Instead, integrate real testing tools into your CI/CD pipeline. Siteimprove's API runs automated accessibility checks with each build, alerting your team to issues before they hit production. This catches regressions early, before they become expensive problems that require emergency fixes.

Go from compliance burden to technical advantage

Good accessibility creates cleaner, maintainable code by default. It boosts SEO performance through structured content. It opens your store to millions of Europeans with disabilities who have money to spend. And it prepares your platform for whatever new technology emerges next.

Yes, the path to compliance looks steep at first glance. But with systematic implementation and the right tools, your e-commerce site can exceed EAA requirements while delivering a better experience for everyone. The accessibility code you write today strengthens your entire technical foundation.

Ready to get started? Begin with a comprehensive accessibility assessment from Siteimprove. Our platform spots issues, prioritizes fixes, and tracks your progress toward compliance. We provide the code-level guidance technical teams need and the validation tools that integrate with your existing workflows. Want to see for yourself? Request a demo today.

Note: This content is for informational purposes only and does not constitute legal advice. The EAA is implemented through national laws, and legal obligations vary by country and context. Consult qualified counsel for legal guidance.