E-commerce accessibility in 2025: EU and Poland obligations (and how to comply)

Web accessibility is a legal must-have in Europe. As of 2025, e-commerce businesses across the EU (including Poland) face new obligations to make their websites and apps accessible to people with disabilities. 

This article breaks down the broad accessibility topic and how to start making your site compliant. 

What WCAG means for e‑commerce websites

WCAG stands for Web Content Accessibility Guidelines. It serves as an international playbook on how to build websites that anyone can use, including people who are blind, deaf, have limited mobility, or have cognitive impairments. 

In practice for e-commerce, WCAG means: 

• blind shopper using a screen reader can “hear” what’s shown (regarding text descriptions for product images); 
• making sure all functions (like adding to cart or navigating menus) can be done with a keyboard for users who can’t use a mouse; 
• ensuring your text and background colors have enough contrast for readability; 
• and writing clear, concise content that’s easy to understand.

Four principles

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

• Perceivable: Users must be able to perceive the content.
  For example, images need alternative text descriptions, audio/video should have captions or transcripts, and text should be resizable and high-contrast for those with low vision.
• Operable: Users must be able to operate all interface components. This means all interactive features (menus, buttons, forms, product carousels, etc.) should be usable via keyboard alone, and there shouldn’t be time limits or flashing content that make usage impossible or unsafe.
• Understandable: Content and navigation must be understandable. Use clear language for product descriptions and instructions, make the site’s behavior predictable (no unexpected pop-ups or navigation changes), and help users avoid and correct mistakes (e.g. clearly indicating form input errors).
• Robust: Content must be robust enough to work with various assistive technologies. This means using clean, semantic HTML code and standard web practices so that screen reader software or other assistive tech can interpret your site reliably.

Practically, following these principles affects every page and feature. It’s a lot to consider, but WCAG is the foundation of the legal standards you have to meet. In fact, the new European laws essentially require e-commerce sites to conform to WCAG 2.2 (the current standard level), which includes about 50 specific success criteria covering all the above principles.

EU law: the European Accessibility Act and new web accessibility mandates

There’s a lot of noise around the European Accessibility Act (EAA) – a directive that becomes enforceable on June 28, 2025. This law marks the first time the EU is requiring private-sector services (not just government websites) to meet accessibility standards. For e-commerce companies, the EAA essentially says: make your online store accessible to people with disabilities or face legal consequences.

Here’s what the EAA means in a nutshell for e-commerce businesses:

• WCAG 2.1 AA compliance by June 28, 2025: The EAA mandates that e-commerce websites and apps must conform to WCAG 2.1 at the AA level by the deadline. In other words, all the guidelines for accessible web content become legal requirements.
• Applies to EU and beyond: The law applies to any company doing business in the EU. Even if your e-commerce company is based outside Europe, if you sell to customers in the EU, you’re expected to comply.
• Exemption for micro-businesses: Very small businesses are exempted, defined as those with fewer than 10 employees and under €2 million annual turnover. So a tiny boutique site might not be legally forced to comply. However, mid-sized and large e-commerce companies are squarely in scope. (And even small B2C businesses may choose to comply anyway to reach more customers.)

This act covers more than just websites. It spans various products and digital services (from ATMs to banking apps to e-books). Importantly, online shopping (e-commerce) is explicitly listed as in scope. By harmonizing accessibility rules (like using WCAG 2.1 AA as the benchmark), the EAA aims to make it easier for businesses to know what standards to follow and for people with disabilities to have consistent access across Europe.

Timing

EU member states had to transpose (implement) the EAA into national law by June 2022, and the rules fully kick in by June 28, 2025. In practical terms, any new e-commerce website or app launched after June 28, 2025 must be accessible from day one, and existing services should be upgraded to meet the standards by that date. 

Enforcement in the EU

The EAA is enforced by national authorities in each country. Regulators will have the power to inspect websites and apps, require proof of accessibility, and impose penalties for non-compliance. 

Poland’s new accessibility regulations for 2025

Poland has embraced the EU directive by passing a national law called the Act on Ensuring Accessibility Requirements for Certain Products and Services (often just referred to as Poland’s accessibility act). This law was adopted in April 2024 and comes into force on June 28, 2025, in line with the EAA’s timeline. For Polish e-commerce businesses (and any company serving Polish customers), here’s what to know:

Scope

The Polish law implements the EAA’s requirements locally. It covers e-commerce websites (online shops) as one of the key services, alongside others like banking, telecom, transport, etc. In short, if you operate an online store in Poland or directed at Poland, you will need to meet the accessibility standards.

New obligations

The law spells out various accessibility requirements. For digital services like e-commerce, this means you must adapt your website and mobile app interfaces to include needed accessibility features. 

For example, websites/apps must support multiple sensory modalities (providing information in text, audio, or visual alternatives as appropriate) and ensure users can perform all tasks (like filing a customer complaint) in an accessible way.

Enforcement bodies

Poland has designated authorities to supervise compliance. Notably, the President of the Management Board of PFRON (the State Fund for Rehabilitation of Disabled Persons) will oversee many aspects, along with sectoral regulators (for example, the Office of Electronic Communications for telecom services, the Financial Ombudsman for banking, etc.). 

These authorities are empowered to conduct audits, request accessibility documentation or test results, and even order non-compliant services to be fixed or pulled off the market.

Penalties in Poland

The Polish law introduces financial penalties for companies that fail to meet the requirements. Fines can go up to 10 times the average monthly salary in Poland. It which was about PLN 71,500 for 2023, roughly €15,000 per violation, but potentially as high as 10% of the company’s annual turnover in the worst cases. In other words, for mid-sized and large businesses, penalties could reach millions of złoty (or euros). Aside from fines, being publicly called out for violations or facing enforcement actions can damage a company’s reputation.

Which parts of an online store must be accessible?

Short answer: every part that a customer interacts with. The accessibility laws demand that the entire user journey on an e-commerce platform is barrier-free.

Let’s break down the key components of an online store that need to comply.

Navigation and site layout

Menus, category listings, search bars, and site links must be usable with assistive technologies. For instance, your navigation menu should be operable via keyboard (arrow keys, tab, enter) and announced clearly by screen readers. If you have search and product filtering, those controls need proper labels and keyboard focus.

Product browsing and pages

From the product listing grids to individual product detail pages, all content should be accessible. Images need descriptive alt text (so a screen reader can describe a product image to a blind user). Product info should be structured with proper headings and lists for easy understanding. If you have features like zoomable images or 360° viewers, ensure they don’t rely on hover-only and have accessible alternatives.

Shopping cart and adding items

The “Add to cart” buttons, quantity selectors, and the cart page itself must work for all. If someone uses only a keyboard or a switch device, they should be able to add an item, update quantities, or remove items without traps or confusion. Any pop-ups should be focus-trapped properly and announced to assistive tech.

Checkout process

This is often the most critical part to get right. Checkout forms (shipping address, payment details) need to have explicit labels on every field (not just placeholder text)

Form instructions and error messages must be presented in ways that screen readers can associate with the relevant fields.

The checkout should be navigable without a mouse. It means users can tab through fields and buttons in a logical order, submit forms with the keyboard, and not encounter components that require a drag-and-drop or other mouse-only action. 

Also consider accessibility of payment interfaces or third-party widgets (like card payment frames) – they should meet standards too.

Confirmation pages and e-documents

Order confirmation pages, downloadable receipts, or e-invoices sent to the customer should also be accessible. If you provide a PDF invoice, for example, ensure the PDF is tagged for accessibility or offer the information as accessible HTML. Any emails or documents should use accessible templates (proper headings, alt text in emails, etc.).

Customer service and support features

If your e-commerce has live chat, chatbots, contact forms, or FAQ sections, these need to be usable by people with disabilities. Live chat interfaces should be operable via keyboard and have clear focus indications. If you offer phone support, provide alternatives like email or text relay for deaf users. Essentially, any way a customer might seek help or post-sales support should not lock out people with disabilities.

Mobile apps (if applicable)

Many e-commerce companies also offer a mobile app. The same accessibility principles apply there. The app should work with iOS VoiceOver, Android TalkBack, support dynamic text sizing, etc. The EU rules cover mobile applications as well as websites, so don’t neglect your app in the compliance process.

How to start becoming compliant: audits, fixes, and common issues

Achieving WCAG compliance for an e-commerce site can feel daunting, but it’s absolutely doable with a systematic approach. Here’s how to get on the road to accessibility:

Audit your current website/app for accessibility gaps. 

Begin with a thorough accessibility audit of your e-commerce site. This usually involves a combination of automated testing tools and manual expert testing:

• Use automated scanners (some free, some paid) to catch obvious issues 
• Then do manual testing: try using the site keyboard-only (can you tab through menus and forms easily? can you activate all controls without a mouse?)
• Consider involving users with disabilities at this stage. For really critical user flows (like the checkout), having a blind user or a keyboard-only user test it will uncover usability hurdles that a developer might not notice. 
• The audit should result in a list of issues and where they occur. Document every problem and map it to the WCAG criteria it violates, as this will help prioritize fixes.
  

Make a plan and fix the issues

Once you know the gaps, it’s time to implement improvements. Prioritize critical barriers first, especially those that prevent users from buying things (like an unusable checkout is a top priority). Some common fixes for e-commerce sites include:

• Adding alternative text to all product images and icons (describing product photos meaningfully so a blind shopper knows what’s shown)
• Ensuring all form fields have explicit labels and form error messages are coded to alert assistive tech
• Improving keyboard navigation: e.g., making sure your menus, filters, pop-ups, and dialogs can be opened and closed with keyboard, and that an obvious focus indicator (a highlight box or underline) is visible as you tab through links/buttons. This may involve adding proper HTML elements or JavaScript event handlers to simulate clicks on Enter/Space keys, etc.
• Using semantic HTML markup for structure: e.g., use <button> for buttons (not just clickable <div>s), use headings <h1>…<h6> in logical order, use lists for product grids or nav lists, use table markup for any tabular data like size charts.
• Adjust CSS styles where the text is too light on a background. WCAG AA requires a contrast ratio of at least 4.5:1 for normal text. This might mean darkening your font colors or lightening the background of buttons, etc., to be easily readable for low-vision users.
• Ensuring responsive elements are also accessible. For instance, if you have a carousel or slider, ensure it can be paused and each slide is labeled for screen readers. If you have modals, manage focus by trapping focus inside the modal while open and returning focus to the trigger when closed.
• Add captions to videos (or remove auto-play), provide transcripts for audio clips, and avoid any content that flashes more than 3 times per second (to prevent seizures).
  

Train your team on accessibility

Compliance isn’t a one-person job or a one-time project – it requires awareness across your design, development, and content teams. Invest in some training so that everyone understands basic accessibility practices.

For developers, this might mean learning about ARIA roles for dynamic content, or how to use automated linters/checkers in code. 

Designers should learn about color contrast and accessible design patterns (like always providing visible focus states, designing forms with clear labels and error states, etc.). 

Content creators should learn to write meaningful link text (no more “click here” links), to add alt text for images, and to use headings and lists in content properly.

Making accessibility part of your team’s skill set ensures that new features or updates will be built accessibly from the start, preventing regression. A great practice is to include accessibility checks in your QA process – for instance, have a checklist to verify each new feature or page meets key WCAG criteria before it goes live.

Test with real users (if possible)

Once you’ve made improvements, it can be invaluable to have people with disabilities try using your updated site. This user testing can validate whether the changes actually solve the problems. 

You might discover, for example, that your new accessible date picker is still confusing to a screen reader user, or that while most of the site is good, an overlay in the cart page is still problematic. 

Real user feedback is gold – it highlights issues that compliance checklists might miss (like the usability angle, not just technical conformance). 

If you don’t have the resources to recruit users for testing directly, at least try to get feedback from any employees or partners with disabilities, or use online communities to get some insights. 

Document your efforts

As always – keep records of what you’re doing – audit reports, lists of fixes, training sessions held, etc. This documentation can serve two purposes: 

• If a regulator or anyone challenges your compliance, you can demonstrate that you have been actively working on it. 
• It creates internal knowledge so new team members can get up to speed on your accessibility standards. Some companies even create an internal “accessibility style guide” or knowledge base.

Plan for ongoing maintenance

Accessibility isn’t a one-time checkbox; websites change, content gets added, and standards evolve. Put in place a plan to monitor and maintain accessibility over time. Also, have a way for users to report accessibility issues – a simple accessibility statement on your site with a contact email shows good faith and can alert you to problems you didn’t catch.

Launching a new store in 2025: what changes now?

If you are planning to launch a brand new e-commerce venture in 2025 (or a major re-platform of an existing store), you’re in a unique position – you can bake in accessibility from the ground up. And you absolutely should: not only is it easier and cheaper to build it right from scratch than to fix it later, but for any store launching after June 28, 2025 in the EU, accessibility is a de jure requirement. In regulatory terms, a new digital service introduced post-deadline must comply immediately, with no grace period.

Here’s how launching in 2025 changes your approach:

• Work with UX/UI designers who understand accessible design principles. 
• Choose color schemes that meet contrast standards from the start; design form layouts with clear labels and error messages; plan your site navigation to be logical and not overly complex.
• When selecting an e-commerce platform or building custom, factor in accessibility support. For instance, some e-commerce platforms have stronger accessibility features or themes than others. 
• Have your QA team include accessibility scenarios (e.g., navigating via keyboard, running automated audits on each build). Catching issues during development of a new site is far easier than fixing them right before launch.
• If you’re populating a new site with products, ensure the content team is writing good alt text for images, using plain language for descriptions, and structuring content with headings. 
• Set up content templates that are accessible (for example, avoid embedding text in images; use real text so it’s readable by all).
• Before the site goes live, do a full accessibility review (like the audit process described earlier). 

Conclusion

Web accessibility has moved from the realm of “optional best practice” to a legal imperative for e-commerce. The EU and Poland have made it clear: if you sell online, your store needs to work for everyone.

And honestly? It’s worth doing right. More customers, fewer headaches, stronger brand.

In practical terms: don’t wait. If you haven’t already, make accessibility a priority in your roadmap. Allocate budget, get expert help if needed, train your team, and start chipping away at those WCAG guidelines.