European Accessibility Act 2025: the complete guide for e...

WCAG 2.1 AA is now mandatory for EU e-commerce. This is the working reference we use on our own client projects — requirements, penalties, audit methodology, and a 90-day remediation plan.

June 28, 2025 — EAA enforcement date
WCAG 2.1 AA — required conformance level
€100,000+ — potential fine per violation
~30% — of EU sites currently compliant

The short version

If you sell digital goods or services to EU consumers, you have new obligations — and they're already enforceable.

The European Accessibility Act (Directive 2019/882) entered into force on June 28, 2025. It applies to e-commerce services, consumer devices, banking, transport ticketing, e-books, and more.

The technical standard is WCAG 2.1 Level AA — 50 success criteria covering perception, operation, understanding, and robustness. Implementation deadlines vary by member state, but enforcement has begun.

Fines range from a few thousand to €100,000+ per violation depending on country. Microenterprises (fewer than 10 employees AND under €2M turnover) are exempt for services; product obligations may still apply.

An accessibility widget alone does not make you compliant. Widgets cover surface issues; structural conformance requires source code work. This guide covers both.

1. What the EAA actually is

The European Accessibility Act — formally Directive (EU) 2019/882 — is the first piece of EU legislation that sets harmonized accessibility requirements across all 27 member states. It was adopted in 2019, gave companies six years of lead time, and took effect on June 28, 2025.

Before the EAA, accessibility law in Europe was a patchwork. The Web Accessibility Directive (2016/2102) covered public-sector websites. Some countries had their own private-sector laws — France's RGAA, Germany's BITV, Italy's Legge Stanca — but coverage varied wildly. A merchant serving customers across five EU countries needed five different compliance strategies.

The EAA consolidates this. It says: if you provide these specific products or services to EU consumers, your offering must meet harmonized accessibility requirements. The technical benchmark is EN 301 549, which in practice means WCAG 2.1 Level AA for websites, web apps, and mobile apps.

Why now?

Roughly 87 million Europeans live with some form of disability. Projected demographic data suggests that figure will grow meaningfully through the 2030s as the population ages. The EU argues — correctly — that an increasingly digital economy becomes an increasingly exclusive one if accessibility is not baked in.

There is also a single-market argument. Companies that want to sell across borders should not face 27 different accessibility requirements. Harmonization lowers friction for compliant businesses and tightens it for non-compliant ones.

Key dates

April 17, 2019 — EAA adopted by European Parliament
June 28, 2022 — deadline for member states to transpose into national law
June 28, 2025 — enforcement begins; new products and services must be compliant
June 28, 2030 — end of grace period for existing service contracts signed before June 2025

That 2030 grace period matters. If you have ongoing service contracts with customers that were signed before the enforcement date, you have until mid-2030 to bring them into conformance. New customers, new services, and new product versions have no such grace — they must be compliant now.

2. Who must comply

The EAA covers two broad categories: specific products (hardware and consumer devices) and specific services (what most e-commerce businesses fall under). For readers of this guide — people running or advising e-commerce operations — the relevant scope is the services list.

Covered services

E-commerce services (the big one for this audience)
Consumer banking services
Electronic communications services (phone, messaging)
Audiovisual media services and their access points
Passenger transport — air, rail, water, bus — including booking and ticketing
E-books, e-readers, and their dedicated software

"E-commerce services" is interpreted broadly. It includes B2C retail, marketplaces, digital subscriptions, SaaS sold to consumers, and any service allowing a consumer to conclude a contract online. Pure B2B services sit in a gray area — the directive targets "consumers," but if your B2B platform is also accessible to private individuals, assume you're in scope.

Who is exempt

The most important exemption is for microenterprises providing services. Microenterprises under EU definitions employ fewer than 10 people AND have annual turnover or balance sheet under €2 million. If both conditions apply, service obligations don't. The microenterprise exemption does not apply to products — if you manufacture a covered product, size doesn't save you.

A second exemption is the "disproportionate burden" clause. A company can argue that meeting a specific requirement would impose an unreasonable cost relative to its size and nature. This is not a blanket opt-out — it's assessed per requirement, must be documented, and is subject to review by national enforcement authorities. In practice, it's narrower than companies assume.

Geographic scope

The EAA is territorial in a specific sense: it applies to services offered to consumers in the EU, regardless of where the provider is established. A US company selling to Germans is in scope. A UK company selling to Irish customers is in scope. Member-state enforcement authorities can act against non-EU providers via consumer-protection cooperation mechanisms.

A US or UK merchant selling to EU consumers is in scope. The law follows the customer, not the seller's address.

In practice, if you ship to any EU country, accept payment in euros from EU billing addresses, or run ads geographically targeting the EU — assume you're covered.

3. WCAG 2.1 AA explained — in plain English

WCAG stands for Web Content Accessibility Guidelines. It's maintained by the W3C, and it's the de facto international standard for web accessibility. Version 2.1 was published in 2018; version 2.2 came out in 2023. The EAA currently references 2.1, though 2.2 is backward-compatible and a sensible target if you're starting fresh.

WCAG is organized around four principles, often abbreviated POUR: Perceivable, Operable, Understandable, Robust. Under each principle are guidelines; under each guideline are success criteria, each labeled A, AA, or AAA.

Level A — the floor

Level A covers the most fundamental requirements: things that make content accessible at all. Missing these effectively locks out entire groups of users. Examples: images must have alt text, video content must have an accessible alternative, the site must be operable with a keyboard, no content flashes more than three times per second.

Level AA — the legal target

AA adds the criteria necessary for typical use by most users with disabilities. This is what the EAA requires. Examples: text must meet minimum contrast ratios, content must be navigable with multiple methods, input errors must be identified and described, form fields must have meaningful labels, and the site must be usable when text is enlarged 200%.

Level AAA — best effort

AAA criteria are more stringent and are not required for compliance. Enhanced contrast ratios, sign language interpretation for video, reading level simplification. These are worth aspiring to, but most e-commerce sites won't hit AAA without a very deliberate investment.

The four principles, translated

Perceivable means users can perceive the information regardless of sensory capability. Blind users use screen readers, so images need descriptions. Deaf users can't hear audio, so videos need captions. Users with low vision need sufficient color contrast. Content that depends on seeing, hearing, or a specific perception mode needs an alternative.

Operable means users can operate the interface. Not everyone uses a mouse — some use only the keyboard, some use switch devices, some use voice control. Operable means all functionality can be reached, used, and left via multiple input methods. It also means nothing triggers seizures (no rapid flashing) and users have enough time to complete tasks.

Understandable means the content and interface behave predictably. Navigation is consistent across pages. Form errors are explained clearly. Language is declared so assistive tech pronounces words correctly. If your UI changes the context of the page (opens a modal, navigates away) that change must be predictable or user-initiated.

Robust means the code is clean enough that assistive technologies can interpret it reliably. Semantic HTML, valid markup, proper ARIA roles where needed. This is the most technical principle and the one most often gotten wrong in modern JavaScript-heavy e-commerce sites.

4. What this means for your e-commerce site, specifically

WCAG is written to be domain-agnostic. To make it useful for e-commerce, the abstract criteria need to be translated into the concrete flows your customers actually use: browsing, searching, adding to cart, checking out, managing their account. Each of these has characteristic accessibility pitfalls.

Product discovery

The home page and category listings are where most sessions begin. Accessibility pitfalls concentrate around search (autocomplete dropdowns that aren't keyboard navigable, results that don't announce to screen readers how many items were found), filters (facet toggles that change results without announcing the change), and sort controls (dropdowns implemented as custom components without proper ARIA).

The most common pass/fail items here: announcing filter and sort changes via aria-live, making autocomplete keyboard-navigable with arrow keys, and providing accessible names for every icon button.

Product detail pages

A PDP is a dense page with lots of interactive elements in close proximity: variant selectors, image galleries, zoom controls, add-to-cart, quantity pickers, related products, reviews, Q&A. Each element is a potential failure point.

Common failures: variant swatches implemented as clickable divs with no keyboard support; image galleries that only work on hover; the add-to-cart confirmation shown as a toast that screen readers never announce; star ratings conveyed only as filled icons with no text alternative for the numeric value.

Cart

Cart pages look simple but fail often. The two most frequent issues are quantity controls (increment/decrement buttons without accessible names, or a spinbutton that doesn't announce the new value) and totals updates (cart subtotal changes after a quantity change but isn't announced to screen readers). Users who can't see the screen have no way to confirm their intended change took effect.

Checkout

Checkout is the most-audited flow because it has the highest commercial stakes. If a user can't complete checkout, the accessibility failure has an immediate revenue cost. The patterns that matter:

Every form field must have a visible, programmatically associated label. Placeholder-only labels fail multiple criteria.
Required fields need both a visible marker (usually *) and aria-required="true".
Error states must be announced, not just shown visually. aria-live regions or linked error summaries both work.
Payment form fields need correct autocomplete attributes — cc-number, cc-exp, cc-csc, cc-name. These are technical criteria; misnaming them fails the WCAG 1.3.5 success criterion.
Guest checkout should be available. Forcing account creation to place an order is legally defensible but accessibility-hostile.

Mobile apps

The EAA covers mobile apps as well as websites. iOS uses accessibilityLabel, accessibilityHint, and accessibilityTraits via the UIAccessibility protocol. Android uses contentDescription and talks to TalkBack. React Native exposes most of this through the accessibilityLabel, accessibilityRole, and accessibilityState props.

The same four WCAG principles apply, adapted to touch UI: labels on every control, sufficient contrast, touch targets of at least 24×24 CSS pixels (44×44 preferred), respect for system font size settings, and respect for reduce-motion preferences.

5. Penalties, country by country

The EAA directs member states to set "effective, proportionate, and dissuasive" penalties but doesn't set fixed figures. Each country sets its own regime through national transposition. That means a violation that triggers a €5,000 fine in one country might trigger €50,000 in another.

The table below summarizes maximum exposures across the largest EU e-commerce markets. These are ceilings from national law, not typical first-offense penalties — but they set the outer range of what enforcement authorities can pursue.

Country	Max penalty	Enforcement body
Germany	Up to €100,000 per violation	Marktüberwachungsstelle (BMAS)
France	Up to €250,000 (repeat offenders)	DGCCRF
Italy	Up to €40,000; 5% of turnover for serious cases	AgID
Spain	Up to €1,000,000 for very serious breaches	Consumer affairs authorities
Netherlands	Up to €21,750 per violation; higher for repeat	ACM
Poland	Up to PLN 100,000 (~€23,000)	PFRON
Ireland	Up to €60,000 for serious breaches	NDA
Sweden	Proportionate to company turnover	DIGG

How enforcement actually works

The typical enforcement sequence is not "inspector shows up, writes fine." It looks more like this:

A consumer, advocacy group, or competitor files a complaint with the national enforcement body.
The authority reviews the complaint, may request documentation from the merchant (including the Accessibility Statement).
If the complaint has merit, the authority issues a remediation order — fix X, Y, Z within N days.
If remediation is not made, or is insufficient, administrative penalties follow.
Serious or repeat non-compliance can escalate to bans on service provision, though this is reserved for extreme cases.

Parallel to administrative enforcement, consumers and advocacy groups can bring civil actions. In Germany and France especially, consumer-rights organizations have track records of challenging inaccessible commerce.

What actually triggers fines

Authorities don't pursue "failed one WCAG criterion" — they pursue "systematically excluded users." The cases that tend to escalate:

Unable to complete checkout with a screen reader. This is the canonical serious complaint.
No keyboard access at all. If a user literally cannot use the site without a mouse, enforcement will be aggressive.
No Accessibility Statement published. The statement is a procedural requirement. Missing it shows lack of good faith.
Refusal to remediate after complaint. Authorities tolerate imperfect compliance far more than they tolerate defiance.

6. How to audit your site

The honest answer to "how do I know if I'm compliant" is that there is no single tool or test that gives you a yes/no answer. WCAG conformance is a combination of automated checks (which cover maybe 30-40% of criteria), manual testing (which handles structural issues and edge cases), and assistive-technology testing (which surfaces the user-experience problems no tool can detect).

Automated tools

Start here. Automated tools are fast, free, and catch the obvious problems. The canonical toolkit:

axe DevTools (browser extension) — the most accurate open-source engine, used under the hood by many commercial scanners.
Lighthouse — built into Chrome, gives an accessibility score and runs axe-core internally.
WAVE — browser extension with clear visual overlays, excellent for non-developers.
Pa11y — command-line tool suitable for CI/CD pipelines.

Run at least one automated scan on your homepage, a category page, a product detail page, the cart, and each checkout step. Aggregate the findings. This gives you a baseline without needing any manual effort.

Keyboard-only testing

The second thing to do — and it costs nothing — is unplug your mouse and try to complete a full purchase with only the keyboard. Tab through every field, Enter to activate, Space to toggle, Esc to dismiss. If at any point you can't reach an element, can't see where focus is, or get trapped in a component, you have a WCAG failure.

This test takes fifteen minutes and typically finds 30-50% of the real user-facing problems on a typical e-commerce site.

Screen reader testing

Harder, but informative. Install NVDA (free, Windows), or use VoiceOver (built into macOS/iOS), or TalkBack (Android). Listen to the site as it's announced. The first session will be uncomfortable — screen readers are not intuitive — but after 30 minutes you'll understand why your "check availability" button being announced as "button button button" matters.

User testing

The gold standard is recruited testing with disabled users. Services like Fable, UserTesting, and Applause have panels specifically for this. A two-hour session with a screen reader user trying to complete a real purchase will surface issues no automated scan and no developer checklist can find. Expect to pay €150–€400 per session.

7. The ten most common failures we see

After auditing hundreds of e-commerce sites, the same issues appear over and over. These are not obscure edge cases — they're the violations that appear on the homepage of most sites you'll encounter.

1. Missing or inadequate alt text on product images. The file name as alt ("IMG_2847.jpg"), alt="product", or missing alt attributes altogether. Product images need descriptions that identify the product, not just the file.

2. Form fields with placeholder-only labels. When a user tabs to the field, the placeholder disappears, and they no longer know what to type. The visible label also needs to be programmatically associated via for/id or aria-labelledby.

3. Insufficient color contrast, especially on gray text on white backgrounds. The 4.5:1 body-text ratio is violated frequently by "subtle" UI like placeholder text, secondary buttons, and metadata. Check your design tokens before you check individual pages.

4. Icon-only buttons without accessible names. The cart icon, the search icon, the mobile menu hamburger — all need either visible text or aria-label. A bare <button><svg></svg></button> is silent to screen readers.

5. Keyboard focus not visible. Removing the browser's default focus outline without replacing it is one of the most-cited violations. If a keyboard user can't see which element is focused, they can't navigate.

6. Cart updates not announced. User adds a product; the mini-cart icon updates the count from 2 to 3; the screen reader says nothing. An aria-live="polite" region announcing "Product added to cart. 3 items in cart" fixes this with one line of HTML.

7. Custom components missing ARIA. The dropdown you wrote is structurally a div with click handlers. A real dropdown needs role="combobox" or role="listbox", aria-expanded, and keyboard handling for arrow keys and Escape.

8. Headings used for styling, not structure. Designers style an H2 to look like body text, or use H3 for something that should be H2 because "it looks better." Screen reader users navigate by headings — misused hierarchy destroys navigation.

9. Images of text instead of real text. Banner graphics with promotional copy baked into the image. The text isn't resizable, isn't readable by assistive tech, and isn't searchable. Use real text on styled backgrounds.

10. Language attribute missing or wrong. The <html lang="..."> attribute tells screen readers how to pronounce content. A French site marked lang="en" causes the screen reader to read French text with English phonemes — nearly incomprehensible.

8. The Accessibility Statement — a legal requirement most miss

Beyond the technical conformance requirements, the EAA requires you to publish an Accessibility Statement. This is a public-facing document, usually linked from the site footer, that describes your conformance level, known limitations, and mechanisms for users to report problems.

Missing this document is one of the most cited reasons for complaints escalating — not because authorities love paperwork, but because it's the first thing they check. No statement means no evidence of good faith, which changes the tone of subsequent conversations.

What it must contain

A conformance claim — which WCAG version and level (typically "conforms to WCAG 2.1 Level AA with the exceptions noted below").
A list of known non-accessible content, with explanations. This is not an admission of failure — it's how you acknowledge known gaps responsibly.
An accessible contact mechanism — email, form, and phone. Users must be able to report issues through multiple channels.
A commitment to respond within a reasonable timeframe (often 14 days).
A reference to the national enforcement body if the user is not satisfied with your response.
A last-reviewed date. You must review and update the statement at least annually.
Information about the assessment method — self-assessment, third-party audit, or certification.

Templates exist — the W3C's WAI has a generator, and many EU enforcement bodies publish national templates. Using one is fine; what matters is that it's actually accurate for your site.

9. A realistic 90-day remediation roadmap

If you're starting from zero and want to get a typical mid-sized e-commerce site to meaningful WCAG 2.1 AA conformance, budget 90 days of concentrated effort. Not 90 days of full-time attention from a single developer — 90 days of calendar time with well-sequenced work.

Weeks 1–2: Discovery

Run automated scans across your top 20 page templates — not every page, but every distinct template (homepage, category, PDP, search results, cart, checkout steps, account pages, content pages). Run keyboard-only testing on the critical purchase path. Capture findings in your ticketing system with WCAG success criterion references. Prioritize by severity times traffic: a missing alt tag on the homepage matters more than a keyboard trap on the gift-card redemption flow.

Weeks 3–6: Quick wins

The content and design fixes that don't require architectural change. Alt text, contrast ratios, language attributes, form labels, heading hierarchy, skip-to-content link. These are boring but numerous — you'll knock out 40% of your findings here without touching component logic.

Weeks 7–10: Structural fixes

The actual engineering work. Refactor custom components for proper ARIA. Fix focus management in SPAs. Add live regions for cart updates. Rebuild the filter interaction. Repair the keyboard handling in the variant selector. This is where most of the budget and complexity lives, and it's work that can't be templated — it depends on your specific stack.

Weeks 11–12: Verification

Re-audit. Ideally bring in a third party for a fresh pair of eyes. Run user testing with assistive-tech users. Publish the Accessibility Statement. Set up ongoing monitoring (Pa11y in CI/CD is the standard move). Train your content team on accessible content creation so new issues aren't introduced faster than you're fixing them. Add accessibility acceptance criteria to your ticket template.

10. What it actually costs

The range is wide because the work is situational. A modest Shopify store with clean theme code and a few custom pages is fundamentally different from a custom Magento 2 build with 50 pages of legacy jQuery.

That said, realistic brackets from projects we've seen:

Site profile	Audit	Remediation	Total calendar
Shopify/WooCommerce, clean theme, ≤50 pages	€800–€2,500	€3,000–€10,000	4–8 weeks
Mid-complexity Shopware/Magento, custom theme	€2,000–€5,000	€10,000–€30,000	8–14 weeks
Enterprise/headless, multiple SPAs	€5,000–€15,000	€30,000–€100,000+	3–6 months

Two numbers are worth internalizing: accessibility widgets sold as SaaS cost €500–€4,000 per year, indefinitely. A one-time source-code remediation costs more up front but ends. Over a five-year horizon, properly remediated code is usually cheaper than widgetized compliance, and more legally defensible.

How ready is your site, really?

Twelve questions. No email required to see your score. Gives you a risk level and a tailored next step.

Frequently asked questions

Forty-two of the questions we hear most often, grouped by topic.

Scope & applicability

Does the EAA apply if my company is based outside the EU but I sell to EU consumers?

Yes. The EAA applies to services offered to EU consumers regardless of where the provider is established. A US or UK merchant selling to EU customers is in scope. Enforcement actions against non-EU providers happen through consumer-protection cooperation mechanisms between national authorities.

I only sell B2B. Am I covered?

The EAA targets "consumers," which under EU law means natural persons acting outside their trade or profession. Pure B2B is not in scope. However, if your platform is also accessible to private individuals, or if you serve sole traders (who can be consumers in some contexts), assume you're covered. The grey area is small.

What's the microenterprise exemption exactly?

Microenterprises under EU definitions have fewer than 10 employees AND annual turnover or balance sheet under €2 million. Both conditions must apply. The exemption covers services but not products — if you manufacture a covered product, your size doesn't exempt you.

What if I sell digital subscriptions (SaaS, streaming)?

Digital content and subscriptions sold to consumers are in scope as e-commerce services. Streaming services are additionally covered under audiovisual media services. Both sets of obligations can overlap.

Does EAA apply to marketplaces?

Yes. The marketplace operator is responsible for the accessibility of the platform itself — the search, browsing, cart, checkout, and account flows. Individual sellers are typically responsible for their own listings where they can customize content (product descriptions, images).

What about PDF product catalogs and manuals?

PDFs linked from an e-commerce service are part of the service. They need to meet accessibility requirements — typically Tagged PDF with proper structure, reading order, and alt text. A scanned PDF that's essentially an image fails basic accessibility.

Timeline & enforcement

What happened on June 28, 2025 exactly?

EAA obligations became enforceable. New products and services placed on the EU market after that date must meet accessibility requirements. Enforcement authorities in each member state gained the power to investigate complaints and impose penalties.

Is there a grace period for existing websites?

There's a grace period for existing service contracts signed before June 28, 2025 — they can continue until June 28, 2030 or contract end, whichever comes first. The grace period does not cover new customer relationships or new product/service versions.

How do I actually get fined?

The typical path: a consumer or advocacy group complains to the national enforcement authority, the authority investigates, issues a remediation order, and applies penalties if you fail to remediate. Authorities rarely pursue random audits — they respond to complaints.

Has anyone actually been fined yet?

National enforcement is still ramping up in most member states. Early enforcement has focused on banking and major e-commerce operators. Small and mid-sized merchants have seen remediation orders more than fines in year one, but the enforcement regime has teeth and is being tested.

Can consumers sue me directly?

Depends on the member state. Some countries allow private rights of action; others channel disputes through consumer-protection bodies. Germany and France have particularly active consumer advocacy organizations that pursue accessibility cases.

WCAG technical

Why WCAG 2.1 AA and not 2.0 or 2.2?

EN 301 549 (the EU harmonized standard that the EAA references) currently points to WCAG 2.1 AA. WCAG 2.2 was published in 2023 and is backward-compatible — if you target 2.2 AA, you're also 2.1 AA compliant. Aiming for 2.2 is defensible and future-proofs somewhat.

What's the difference between A, AA, and AAA?

A is the baseline (critical barriers removed). AA is the typical target for legal compliance — it's the level at which most users with disabilities can use the site. AAA is best-effort enhancement; not required for EAA compliance and often impractical for content-heavy sites.

Do I need to meet every AA success criterion?

For full conformance claim, yes — all applicable AA criteria must be met. You can claim conformance with documented exceptions under "disproportionate burden," but that has to be genuinely justified, not a blanket excuse.

What contrast ratio do I actually need?

4.5:1 for normal body text against its background; 3:1 for large text (18pt or 14pt bold and larger); 3:1 for UI components and graphical objects. Tools like the WebAIM Contrast Checker give you an instant check.

Does dark mode need its own accessibility checks?

Yes. Every color combination needs to meet contrast requirements. If you support dark mode (or any alternative theme), audit each theme independently. Often the dark theme has worse contrast than the light one because designers spend less time on it.

What about decorative images? Do they need alt text?

Decorative images should have alt="" (empty string) — not missing, explicitly empty. This tells screen readers to skip them. Images with no purpose other than visual styling fall into this category.

Widgets & tools

Does installing an accessibility widget make me compliant?

No. Widgets solve some surface issues — text resizing, contrast adjustment, dyslexia-friendly fonts — but cannot fix missing alt text, broken form labels, keyboard traps, or improper semantic structure. They are a useful first layer, not a compliance solution. Regulators and advocacy groups are aware of this distinction.

But AccessiBe/UserWay marketing says they make me compliant.

Marketing claims and legal reality are different things. Several lawsuits in the US and complaints in the EU have established that widget-only remediation does not satisfy accessibility requirements. Use them as a bridge, not a destination.

What's the difference between your free widget and AccessiBe?

Functionally similar set of visual adjustments. Main differences: RIDLY Accessibility is free with no recurring cost (AccessiBe is €490–€3,990/year); we offer a €149 one-time self-hosted Pro version with an audit engine; source code available for Pro; honest about what widgets cannot do.

Which automated scanner is the most reliable?

Deque's axe-core engine is the most widely respected open-source scanner — it powers axe DevTools, Lighthouse's accessibility audit, and many commercial tools under the hood. WAVE is excellent for non-developers because of its visual overlay.

How often should I re-run audits?

Ideally, automated checks run on every deploy via CI/CD. Full manual audits should happen at least annually, or whenever you do a significant redesign, launch a major feature, or change platforms.

E-commerce specifics

Do product images really all need individual alt text?

Yes, and descriptive alt text — "Red leather handbag with silver buckle, front view" is useful; "IMG_2847.jpg" or "handbag" is not. For gallery images showing the same product from different angles, each image should describe what makes it distinct ("front view," "side detail," "interior lining").

What about user-generated content (reviews, Q&A)?

You're responsible for the infrastructure — the reviews submission form, the display markup, the moderation tools. You're generally not responsible for user-submitted content being "accessible" in content terms (a user writing poor grammar isn't your WCAG violation). But user images in reviews do need alt text prompts during submission.

Can I force users to create an account before checkout?

Legal, but accessibility-hostile. WCAG doesn't explicitly prohibit it, but forcing account creation compounds friction for users with cognitive disabilities and those using assistive technology. Guest checkout is a strongly recommended pattern.

Does my third-party payment widget (Stripe, Klarna) need to be accessible?

Stripe and Klarna's hosted payment interfaces are accessible (they test extensively). If you embed their components within your own checkout, the surrounding context — headings, form structure, error handling — still needs to be compliant on your side.

What about our mobile app? Separate audit?

Yes. iOS and Android have distinct accessibility APIs. The same WCAG principles apply but implementation is different — UIAccessibility for iOS, AccessibilityService for Android, platform-specific touch target sizes, platform-specific focus handling. Budget a separate audit for each platform.

Do I need to offer a sign language video explaining my site?

Sign language is a WCAG AAA criterion (1.2.6) — not required for legal compliance. However, prerecorded audio content (podcasts, audio-only product demos) at AA level needs a text alternative like a transcript.

Process & practical

Should I hire an in-house accessibility specialist?

For large e-commerce operations (€50M+ GMV), yes — ongoing ownership matters. For smaller operators, an ongoing retainer with a specialist consultancy is more practical and usually cheaper per-hour than a full-time hire.

Do we need to redesign the whole site?

Very rarely. Most remediation is targeted fixes to existing code: design token contrast adjustments, component-level ARIA, keyboard handler additions. Full redesigns aren't usually accessibility-driven.

Can we claim "disproportionate burden" to skip parts?

You can, but it's narrower than it sounds. The burden must be genuinely disproportionate relative to your size and the benefit to users. You have to document your reasoning and make the documentation available if requested. It's not a general opt-out for inconvenient requirements.

Who owns accessibility internally — design, engineering, product?

All three. Design owns contrast, color choice, information hierarchy, and focus states. Engineering owns semantic markup, ARIA, keyboard handling, and performance. Product owns content strategy, flow design, and acceptance criteria. The healthy pattern is shared ownership with one person in the org as the accountable lead.

What if our platform (Shopify, Magento) ships broken accessibility?

You're still responsible for your customer-facing experience. Platforms have improved substantially, but themes and customizations often introduce new issues. You may have to work around platform limitations or move customizations to a more accessible-friendly approach.

Is there a "certification" I can get?

No single EU-wide certification. Some national bodies and private auditors offer conformance statements, but these aren't required by the EAA. A published Accessibility Statement backed by documented testing is the expected evidence.

How do I handle accessibility for thousands of product SKUs?

Automate. Alt text generation from product metadata, contrast checking in the design system, semantic markup at the template layer. If every PDP is generated from the same template, fixing the template fixes every product. The work is at the platform layer, not per-product.

RIDLY-specific

How can RIDLY help specifically?

Three paths depending on budget and control preference. Free widget at ridly.io/accessibility for a quick first layer. €149 one-time Accessibility Pro for self-hosted platform with WCAG audit engine. Custom Services for full code-level remediation with delivery-only senior engineers. The paths are designed to fit different stages of readiness.

Can you run an audit on my site?

Yes — reply to any outreach email with "audit" or email roman.tsehynka@gmail.com. We return a full WCAG 2.1 AA scan within 24 hours with severity-ranked issues and remediation estimates. Free, no obligation.

How long does a typical remediation project take with RIDLY?

Small Shopify/WooCommerce: 4–8 weeks. Mid-complexity Magento/Shopware: 8–14 weeks. Complex headless/enterprise: 3–6 months. We work delivery-only with senior engineers, so calendar time is shorter than at traditional agencies with learning curves.

Three ways we help

Pick the one that matches your stage. Every path starts at the same place — the free audit report.

Path A · Free widget

Free · CDN-hosted. Covers ~70% of common surface violations in five minutes. 20+ features, 33 languages. Honest positioning: a credible first layer while you plan real work. Install free widget →

Path B · Accessibility Pro

€149 one-time · no subscription. Self-hosted platform with Admin Panel, WCAG Audit Engine (80+ checks), AI-powered remediation suggestions, multi-site management. Source code included. Buy Pro · €149 →

Path C · Full remediation

Custom · 24h estimate SLA. Delivery-only team of senior engineers. Audit, fix, document. No retainers, pay per fix. Typical e-commerce remediation: €8K–€30K depending on scope. Get 24h estimate →

Written by Roman Tsehynka, founder of RIDLY · 15+ years in e-commerce · Lviv, Ukraine · April 2026. Questions? Email roman.tsehynka@gmail.com.