European Accessibility Act and SAP Commerce: A Compliance Guide for E-Commerce

The European Accessibility Act (EAA) is not coming. It is here. EU Directive 2019/882 became enforceable across member states on June 28, 2025, and e-commerce services are explicitly in scope. If you operate an online store that serves EU customers, you are now legally required to meet accessibility standards, and the enforcement mechanisms have teeth.

Yet in conversations with SAP Commerce teams across Europe, we consistently find that accessibility is treated as a “nice to have” or a future initiative. This is a compliance risk that grows every day it goes unaddressed. Fines vary by member state, but the penalties can reach hundreds of thousands of euros, and in some jurisdictions, authorities can order non-compliant services to be taken offline until remediated.

This guide covers what the EAA requires, where SAP Commerce Cloud (and specifically the Composable Storefront) stands today, and how to build a practical remediation roadmap.

The EAA is a harmonization directive, meaning it sets a common accessibility standard across all EU member states. Individual countries have transposed it into national law with varying enforcement mechanisms, but the core requirements are consistent.

Who Is Covered

The EAA applies to “e-commerce services,” which the directive defines broadly. If you sell products or services online to EU consumers, you are almost certainly covered. This includes:

• B2C e-commerce (the obvious case): any online store selling to consumers
• B2B e-commerce where the buyer is a microenterprise or individual: this is a grey area that many B2B companies are ignoring at their risk. If a sole trader or micro-business uses your B2B portal, the EAA may apply.
• Marketplace participation: if you sell through a marketplace, the marketplace operator has primary responsibility, but your product listings and any seller-managed pages also need to comply

Exemptions exist for microenterprises (fewer than 10 employees and under 2 million EUR annual turnover) and for situations where compliance would impose a “disproportionate burden.” But the disproportionate burden defense requires documented evidence of the assessment, and regulators are expected to scrutinize these claims. If you are running SAP Commerce Cloud, you are almost certainly not a microenterprise, and the platform provides enough accessibility infrastructure that a disproportionate burden argument would be difficult to sustain.

The Technical Standard: WCAG 2.1 Level AA

The EAA references the European standard EN 301 549, which in turn maps to WCAG (Web Content Accessibility Guidelines) 2.1 Level AA as the baseline for web-based services. If you meet WCAG 2.1 AA, you are meeting the EAA’s technical requirements for your web content.

WCAG is organized around four principles, often abbreviated as POUR:

Perceivable. Information and UI components must be presentable to users in ways they can perceive. This means:
– Text alternatives for non-text content (images, icons, charts)
– Captions and alternatives for multimedia
– Content that can be presented in different ways (e.g., simpler layout) without losing information
– Content that is distinguishable (sufficient color contrast, resizable text, no information conveyed by color alone)

Operable. UI components and navigation must be operable by all users. This means:
– All functionality available from a keyboard (no mouse-only interactions)
– Users have enough time to read and use content (no auto-advancing carousels without pause controls)
– Content does not cause seizures or physical reactions (no flashing content above thresholds)
– Users can navigate, find content, and determine where they are (clear headings, skip links, focus indicators)

Understandable. Information and UI operation must be understandable. This means:
– Text is readable and understandable (language declared, jargon explained)
– Pages appear and operate in predictable ways (consistent navigation, no unexpected context changes)
– Users are helped to avoid and correct mistakes (form labels, error messages, input validation feedback)

Robust. Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies. This means:
– Valid, well-structured HTML
– Name, role, and value attributes for all UI components (especially custom widgets)
– Status messages that can be programmatically determined (ARIA live regions)

Specific E-Commerce Requirements

Beyond general WCAG compliance, the EAA highlights several requirements that are particularly relevant for e-commerce:

• Product information accessibility. Product descriptions, specifications, pricing, and availability must be accessible. Images need meaningful alt text, not just “product image” or the filename.
• Transaction process accessibility. The entire purchase flow, from product selection through checkout and payment, must be operable by keyboard and compatible with screen readers. This includes form fields, error messages, payment method selection, and order confirmation.
• Identification and authentication. Login, registration, and account management processes must be accessible. CAPTCHAs that rely solely on visual recognition are non-compliant.
• Customer support accessibility. If you offer live chat, phone support, or email support, at least one of these channels must be accessible.

Composable Storefront (Spartacus)

SAP has invested meaningfully in Spartacus accessibility. The framework includes ARIA attributes, keyboard navigation support, focus management, and screen reader compatibility across most core components. SAP’s Composable Storefront has made significant progress toward WCAG compliance, covering most WCAG 2.0 requirements and an increasing portion of WCAG 2.1 criteria, though gaps remain in the out-of-the-box components.

What is covered well:
– Core navigation (header, footer, breadcrumbs, menus) generally meets WCAG standards
– Product listing pages have reasonable semantic structure
– Form components (login, registration, checkout forms) include labels, error association, and keyboard operability
– Cart and mini-cart interactions are keyboard-accessible
– Focus management during page navigation and modal dialogs works correctly in most cases
– Color contrast in the default theme meets AA standards

Where gaps exist:

• Custom components. Any component your team has built or significantly modified outside the Spartacus library is your responsibility. Spartacus provides the accessibility foundation, but custom Angular components do not inherit accessibility automatically. A custom product configurator, a bespoke filtering widget, or a custom checkout step needs its own accessibility implementation and testing.
• Third-party integrations. Payment iframes, review widgets, recommendation carousels, chatbots, and analytics consent managers are common sources of accessibility failures. These components are typically embedded via third-party JavaScript and may not meet WCAG standards. You are responsible for the overall page accessibility, including third-party content.
• Media content. Product images need meaningful alt text. Product videos need captions. PDFs (spec sheets, safety data sheets, user manuals) need to be accessible documents, not scanned images. This is a content problem, not a platform problem, but it is where many implementations fail.
• Dynamic content. AJAX-loaded content, infinite scroll, live search suggestions, and dynamically updated pricing need proper ARIA live region announcements. Without these, screen reader users have no way to know that content has changed on the page.
• Mobile touch targets. WCAG 2.1 includes a 44×44 CSS pixel touch target recommendation, though at Level AAA (Success Criterion 2.5.5), not AA. WCAG 2.2 introduced a Level AA minimum of 24×24 CSS pixels (SC 2.5.8). Either way, custom mobile UI elements often fall below these thresholds.

Accelerator Storefronts

If you are still running a JSP-based Accelerator storefront, your accessibility situation is significantly worse. Accelerator storefronts were built before accessibility was a priority in the SAP Commerce ecosystem, and the server-side rendering approach makes retrofitting accessibility more difficult:

• Semantic HTML structure is inconsistent (overuse of divs, insufficient heading hierarchy)
• ARIA attributes are largely absent from custom components
• Keyboard navigation is unreliable, especially in complex interactions (faceted search, product comparison, multi-step checkout)
• Focus management is poor (focus is lost after page transitions, modals do not trap focus)
• Form error handling often lacks programmatic association between error messages and input fields

Bringing an Accelerator storefront to WCAG 2.1 AA compliance is possible but expensive. In many cases, the effort approaches that of a Spartacus migration. If accessibility compliance is a driver, use it as additional justification for migrating to Composable Storefront rather than patching an Accelerator.

An effective accessibility assessment combines automated scanning, manual testing, and (ideally) user testing with assistive technologies. No single approach catches everything.

Automated Testing

Automated tools catch approximately 30 to 40 percent of WCAG issues. They are fast and repeatable, making them essential for baseline assessment and regression testing, but they cannot evaluate the full user experience.

Tools to use:

• axe DevTools (browser extension): the industry standard for automated accessibility scanning. Runs in-page and reports issues with WCAG success criteria references and remediation guidance.
• Lighthouse (built into Chrome DevTools): includes an accessibility audit that covers common issues. Less comprehensive than axe but useful for quick checks.
• WAVE (browser extension from WebAIM): provides a visual overlay showing accessibility issues in context, which is helpful for communicating findings to designers and content editors.
• Pa11y (command-line tool): useful for CI/CD integration, can scan pages programmatically and report issues in machine-readable formats.

Run automated scans across all page types in your storefront: homepage, category page, product detail page, search results, cart, each checkout step, account management pages, and any custom pages. Scanning only the homepage will miss most issues.

Manual Testing

The remaining 60 to 70 percent of accessibility issues require human evaluation:

Keyboard navigation testing. Unplug your mouse (or activate a keyboard-only mode) and try to complete core user journeys entirely with the keyboard. Can you:
– Navigate to a product and add it to the cart?
– Complete the checkout process?
– Use search and filters?
– Access account management features?
– Close modals and return to the previous context?

Watch for: focus getting trapped (you cannot tab out of a component), focus being lost (after an interaction, focus jumps to the top of the page), invisible focus (the focused element has no visible indicator), and inaccessible interactions (dropdown menus or sliders that require mouse interaction).

Screen reader testing. Test with at least one screen reader:
– NVDA (free, Windows) with Firefox or Chrome
– VoiceOver (built-in, macOS/iOS) with Safari
– JAWS (paid, Windows) with Chrome or Edge, if your audience is primarily enterprise users (JAWS is the most common enterprise screen reader)

Listen for: images without meaningful descriptions, form fields without labels, buttons without accessible names, state changes that are not announced (adding to cart, error messages appearing), and heading structure that does not reflect the content hierarchy.

Color contrast verification. Use a contrast checker tool (the WebAIM contrast checker is excellent) to verify text-to-background contrast ratios. WCAG AA requires 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). Check your brand colors, error states, disabled states, and placeholder text, all of which are common failure points.

User Testing

If budget allows, conduct usability testing with people who use assistive technologies daily. Automated tools and manual testing by developers will catch most technical violations, but user testing reveals whether your storefront is actually usable. There is a meaningful difference between “technically compliant” and “a blind user can successfully purchase a product.”

Organizations like AbilityNet (Europe) and Fable (international) provide access to testers with disabilities.

Once you have assessed your current state, prioritize remediation based on impact, effort, and legal risk.

Quick Wins (1-4 weeks)

These issues are common, easy to fix, and disproportionately impactful:

Alt text for images. Audit all product images and add meaningful alternative text. “Blue industrial pump, model XP-500, 2-inch inlet” is useful. “Product image” or “IMG_4532.jpg” is not. For decorative images, use empty alt attributes (alt="") so screen readers skip them.

Form labels. Ensure every form input has a programmatically associated label (using the <label> element with a for attribute, or aria-label / aria-labelledby). This applies to search fields, login forms, checkout fields, and filter inputs.

Color contrast. Adjust text colors that fail contrast requirements. This often means darkening light grey text on white backgrounds, a common design pattern that fails WCAG AA. Check error messages (often red on white, which can fail), placeholder text (almost always fails), and disabled button states.

Focus indicators. Ensure all interactive elements have a visible focus indicator. Browsers provide a default focus ring, but many CSS resets remove it. Add a custom focus style that is visible and consistent: outline: 2px solid #2ea3f2; outline-offset: 2px; is a good starting point.

Language declaration. Add the lang attribute to your <html> element. For multi-language storefronts, update it dynamically based on the active locale.

Page titles. Each page should have a unique, descriptive <title> element. “Home” or “Page” is insufficient. “Industrial Pumps – Category – Your Company” tells screen reader users where they are.

Medium Effort (1-3 months)

Keyboard navigation improvements. Fix tab order issues, add skip links (“Skip to main content” as the first focusable element), ensure all interactive elements are keyboard-accessible, and implement proper focus trapping in modals and overlays.

ARIA attributes. Add ARIA roles, states, and properties where semantic HTML alone does not convey the component’s purpose. Common needs: role="alert" for error messages, aria-expanded for dropdown menus, aria-live="polite" for dynamically updated content (cart count, search results count), and role="navigation" with aria-label for multiple nav regions.

Heading hierarchy. Restructure heading levels to create a logical document outline. Each page should have one <h1>, with <h2> through <h6> used in order without skipping levels. Screen reader users frequently navigate by headings, so a logical heading structure is essential for page comprehension.

Error handling. When form validation fails, provide clear error messages that are programmatically associated with the invalid field, move focus to the first error, and describe how to correct the issue. “Invalid input” is not helpful. “Email address must include @ symbol” is.

Touch target sizing. Ensure all interactive elements meet at least the 24×24 CSS pixel minimum required by WCAG 2.2 AA (SC 2.5.8), and aim for 44×44 CSS pixels where practical for better usability. Increase padding on buttons, links in navigation menus, and form controls as needed.

Major Work (3-6+ months)

Component redesign. Custom widgets that were built without accessibility in mind (product configurators, interactive size guides, complex filtering interfaces, drag-and-drop features) may need fundamental redesign. This is not about adding ARIA attributes to an inaccessible component. It is about rethinking the interaction model to be accessible from the ground up.

Third-party integration remediation. Audit every third-party component on your storefront. Contact vendors about their WCAG compliance status and timelines. For components that are not compliant and have no remediation plan, evaluate alternatives. Payment providers, in particular, have been improving their iframe accessibility in response to the EAA, so check for updated integration options.

PDF and document accessibility. If your product pages link to PDF spec sheets, safety data sheets, or user manuals, these documents need to be accessible: tagged PDF structure, alternative text for images within PDFs, readable tables, and logical reading order. This is a significant undertaking if you have hundreds or thousands of product documents.

Video and multimedia. Product videos need captions (not auto-generated, which are rarely accurate enough for compliance). Interactive media (360-degree product views, AR try-on features) need accessible alternatives.

Accessibility is not a one-time project. It is an ongoing practice that needs to be embedded in your development and content workflows.

Accessibility Testing in CI/CD

Integrate automated accessibility testing into your build pipeline:

• Run axe-core (the engine behind axe DevTools) as part of your automated test suite. Fail the build if new WCAG A or AA violations are introduced.
• Include accessibility checks in your end-to-end tests (Cypress, Playwright, or similar tools all have accessibility testing plugins).
• Run Lighthouse CI on key page templates as part of your deployment pipeline.

Automated tests catch regressions. They will not catch all new issues, but they prevent previously fixed problems from returning, which is one of the most common accessibility failure patterns.

Design System with Accessibility Built In

If your Spartacus implementation uses a design system or component library, bake accessibility requirements into each component’s specification:

• Every component spec should include keyboard interaction patterns
• Color combinations should be pre-validated for contrast
• Interactive components should include ARIA attribute requirements
• Each component should have documented accessibility testing criteria

This shifts accessibility from a QA concern to a design concern, which is both more effective and more efficient.

Training for Content Editors

Your content team creates product descriptions, uploads images, writes promotional copy, and manages landing pages. If they do not understand accessibility requirements, they will continuously create new compliance issues:

• Image alt text guidelines (what to write, when to use empty alt, how to describe complex images)
• Heading structure rules (do not skip levels, do not use headings for visual styling)
• Link text guidelines (“Click here” and “Read more” are uninformative. “View pump specifications” tells screen reader users where the link goes.)
• Color and formatting rules (do not convey information through color alone, do not use text in images)

A two-hour training session with ongoing reference documentation will prevent most content-related accessibility issues.

Compliance is the floor, not the ceiling. Accessible e-commerce delivers business value that extends well beyond avoiding fines:

Larger addressable market. Approximately 100 million people in the EU have some form of disability. Many more have temporary impairments (a broken arm, an eye infection) or situational limitations (using a phone in bright sunlight, browsing in a noisy environment). An accessible storefront serves all of these users.

Better UX for everyone. Accessibility improvements almost always improve the experience for all users. Clear form labels, logical navigation, readable text, and consistent error handling benefit everyone, not just assistive technology users. In our portfolio of e-commerce implementations, we have observed that accessibility-driven improvements consistently correlate with improved conversion rates and reduced support tickets.

SEO benefits. There is substantial overlap between accessibility best practices and search engine optimization. Semantic HTML, descriptive headings, alt text, and logical page structure help both screen readers and search engine crawlers understand your content. Accessible storefronts tend to rank better.

Future-proofing. Accessibility standards will tighten, not loosen. WCAG 2.2 is already published and adds additional success criteria. The EAA may be updated to reference newer standards. Investing in accessibility now means you are building from a solid foundation rather than perpetually playing catch-up.

Reduced legal risk. Beyond the EAA, accessibility litigation is increasing in jurisdictions worldwide. The US ADA, the UK Equality Act, and individual EU member state laws all create legal exposure for inaccessible digital services. A demonstrable accessibility program, documented assessments, remediation plans, and ongoing testing, provides a strong defense even if individual issues remain.

If you have done nothing on accessibility yet, here is the path of least resistance:

1. Run an automated scan of your storefront today. axe DevTools takes five minutes to install and run. You will have a concrete list of issues and their severity.
2. Try keyboard-only navigation through your core purchase flow. The experience will likely surprise you.
3. Estimate the scope. Are you looking at quick fixes, or fundamental component redesign? This determines your budget and timeline.
4. Brief your leadership. The EAA is enforceable now. Present the compliance risk, the remediation estimate, and the business case for investing beyond minimum compliance.
5. Start with quick wins. Alt text, form labels, color contrast, and focus indicators can be addressed in a sprint or two and will close a large percentage of automated scan findings.

Accessibility compliance on SAP Commerce is achievable, especially if you are on the Composable Storefront. The platform provides a solid foundation. Your job is to close the gaps in your custom code, your content, your third-party integrations, and your ongoing processes. The EAA deadline has passed, so the question is not whether to act, but how quickly you can reach compliance and how thoroughly you can maintain it.

As SAP Commerce consulting practitioners, we help teams assess their current accessibility posture, build remediation roadmaps, and integrate accessibility into their development workflows. If you are unsure where you stand, an expert assessment is the fastest way to understand your risk and your path forward.