Does an online store need to meet WCAG in 2026?

Does an online store need to meet WCAG? In 2026, a store serving consumers in the European Union may have a legal accessibility duty, but the answer is not simply that every business website must display a WCAG badge. The service, the way a customer concludes a contract and the size and status of the provider all matter. Compliance also covers more than a homepage scan.

If you are commissioning a new store or replacing an existing one, define accessibility before wireframes and integrations are approved. Retrofitting an inaccessible checkout, navigation system or payment journey after launch is usually harder than selecting suitable components from the start.

Short answer: covered ecommerce services usually do

The European Accessibility Act has applied through national legislation since 28 June 2025. The official EU Directive 2019/882 includes ecommerce services within its scope. It defines them as services delivered at a distance through websites or mobile services, electronically and at a consumer's individual request, with a view to concluding a consumer contract.

A B2C store with a basket and online payment is therefore much closer to the core definition than a brochure website where a visitor can only read information and call the business. The real customer journey matters more than the label used in the navigation.

The Directive exempts microenterprises providing services, while national laws set out enforcement and local procedures. Do not assume that a sole trader is automatically exempt or that a store is outside the rules because it uses a marketplace or hosted platform. Confirm the legal position of the particular operator and markets with an adviser when the answer affects contractual obligations.

For businesses operating in Poland, the government's guidance on ecommerce services explains the scope of the Polish Accessibility Act, including the service-provider exemption for microenterprises.

WCAG, EN 301 549 and the law are not interchangeable

Three layers are often compressed into the phrase “WCAG compliant”:

• the European Accessibility Act and national legislation create legal duties,
• EN 301 549 sets accessibility requirements for ICT products and services,
• WCAG provides testable success criteria for web content.

Polish government guidance currently lists EN 301 549 V3.2.1, which incorporates WCAG 2.1 criteria. W3C recommends the current WCAG 2.2 for new accessibility work and explains that it extends WCAG 2.1.

WCAG 2.2 Level AA is a sensible technical target for a new store, but a supplier agreement should not stop at that phrase. It should identify the pages and complete journeys in scope, the evaluation method, expected evidence and the process for correcting defects. A legal assessment must also consider the applicable national act and technical standard.

Treat the purchase journey as one service

Making the homepage and product template accessible is not enough. A customer should be able to complete the whole task without a mouse and with assistive technology. Test at least:

• search, navigation, filters and sorting,
• product lists and product detail pages,
• variant and quantity selection,
• the basket, voucher codes and delivery options,
• address fields, consent controls and validation,
• payment, authentication and the return to the store,
• order confirmation and transactional messages,
• customer accounts, sign-in and account recovery,
• terms, returns information and downloadable documents.

A payment gateway, review widget, chat service or collection-point map remains part of the customer's experience even when another company supplies it. Assess third-party components before committing to an integration. The contract should state who will investigate accessibility defects, provide an alternative route and coordinate a fix with the vendor.

Common accessibility barriers in online stores

Missing image alternatives are only one part of the problem. Barriers that can stop a purchase include:

• no visible keyboard focus or an illogical focus order,
• menus, filters, dialogs or product options that require a mouse,
• form fields without persistent labels,
• errors that rely on colour or do not explain how to continue,
• an add-to-basket update that a screen reader never announces,
• low contrast in text, controls or focus indicators,
• layouts that break when text is enlarged or the viewport narrows,
• information communicated only by position, shape, icon or colour,
• motion that cannot be paused,
• authentication that depends only on memory or recognising an image.

Many of the same improvements help a shopper using a phone in bright light, a damaged screen, a slow connection or one hand. Accessibility does not replace conversion optimisation, but it removes obstacles for people who may already be ready to buy. The diagnostic guide on why an online store is not selling covers the wider acquisition and checkout picture.

An accessibility widget is not a compliance plan

A toolbar that changes contrast or text size can be an optional feature, but it cannot repair incorrect HTML structure, a keyboard trap, unnamed controls or a failed payment flow. It also cannot make an inaccessible PDF or third-party checkout usable.

Accessibility has to exist in the design, code, content and maintenance process. A layer placed over the finished interface is not a substitute for semantic components, complete-journey testing and source-level repairs.

How to evaluate an online store

Automated testing is useful, but it cannot be the sole acceptance test. W3C's web accessibility evaluation guidance states that no tool alone can determine whether a website meets accessibility standards and that knowledgeable human evaluation is required.

A proportionate acceptance process combines:

1. automated checks on representative templates,
2. manual keyboard testing of complete journeys,
3. screen-reader checks for critical tasks,
4. zoom, reflow and viewport testing,
5. review of labels, errors, status messages and dynamic updates,
6. a report identifying location, criterion, severity and reproduction steps,
7. a retest after remediation.

Do not test only a successful order. Include a missing required field, an invalid postcode, an unavailable variant, a declined payment, an empty search result and a second payment attempt. The guide to website contact forms and better enquiries explains related principles for labels, validation and confirmations.

What to put in the project scope

Ask every prospective supplier to answer the following questions in writing:

1. Which standard, version and conformance level is the target?
2. Which templates and complete user journeys will be evaluated?
3. Does acceptance include keyboard and screen-reader testing?
4. Who tests payment, delivery and other third-party integrations?
5. Will you receive a report and a retest after fixes?
6. Who is responsible for content added through the CMS later?
7. How are regressions after platform updates handled?
8. Does the scope include the required public accessibility information?

Polish rules, for example, require a covered ecommerce provider to publish information about the service, how to use it and how it meets accessibility requirements in its terms or an equivalent document. The government provides a separate explanation of these information duties under the Polish Accessibility Act. Other EU countries implement the Directive through their own national processes, so confirm the requirements for each market you serve.

Accessibility continues after launch

A new promotion, review plugin, checkout release or unlabelled product image can introduce a barrier into a previously tested store. The operating plan therefore needs editorial rules, checks for new integrations and periodic retesting of the most important journeys.

An audit and focused remediation may be enough when the platform allows its components and purchase flow to be corrected. A rebuild becomes more reasonable when the theme, hosted checkout or essential integrations prevent accessible alternatives. The guides to technical SEO for a new website and improving or rebuilding a website help separate repair work from a wider replacement project.

AMCompany designs and develops online stores with accessibility, buying journeys, performance and technical SEO considered together. Explore the services and portfolio. To define a new build or audit, describe the store and its critical integrations.