Who it applies to · shops, marketplaces, bookings, subscriptions, paid online services
Online shops and e‑commerce
E‑commerce is the one service in the act that concerns hundreds of thousands of companies — everyone who, at a distance, through a website or app, concludes contracts with consumers (art. 5(32)). The supervisory authority is the minister responsible for digital affairs (art. 38(3)(2)). This page walks through a shop the way an auditor will: from the product page to the order confirmation.
"In addition to meeting the accessibility requirements referred to in art. 12, e‑commerce services shall ensure: 1) the provision of information on the accessibility of products or services, where that information has been provided by the economic operator obliged to do so; 2) the perceivability, operability, understandability and compatibility of the functions and methods used to identify the parties to the e‑commerce service, to maintain security and to make payments, to provide electronic signatures and of the payment services that form part of that service." (our translation)
What art. 18 means in the basket
| Element of the act | In a shop that is… | Typical breach |
|---|---|---|
| identification of the parties | registration, login, "buy without an account", invoice details, e‑mail verification, social login | fields without labels, "invalid data" without naming the field, an SMS code in a field without autocomplete="one-time-code" |
| maintaining security | CAPTCHA, 2FA, session limits, confirmations | image CAPTCHA without an audio/logic alternative, a session expiring without warning during payment (WCAG 2.2.1) |
| making payments | method choice, card form, redirect to the operator, BLIK, instalments | a gateway iframe without a title and focus, radio buttons as clickable images, a "Pay" button that is a div |
| electronic signatures | accepting the terms, consents, instalment agreements, in‑app signing | a consent checkbox without a linked label, a finger‑drawn "signature" without an alternative |
| product accessibility information (point 1) | on the page of a product covered by the act (computer, e‑reader, phone, terminal): the manufacturer's accessibility information | no section; the manufacturer's data hidden in a PDF |
Art. 12 applies alongside: product descriptions, terms, returns policy, delivery prices — in a legible font, with contrast, as text, with image alternatives; and the whole shop — perceivable, operable, understandable, compatible.
The purchase path through an auditor's eyes
Home page and categories
An auto‑scrolling carousel without pause (2.2.2); a drop‑down menu that works only with a mouse (2.1.1); filters as inaccessible custom controls; "show more" without telling the screen reader that something loaded (4.1.3).
Product page
Photos without alternatives or with "IMG_2031.jpg" (1.1.1); size/colour choice by colour alone (1.4.1); price and promotion by strikethrough without text (1.3.1); an "Add to basket" button without confirmation for the screen reader (4.1.3); parameter tables without headers (1.3.1).
Basket
Quantity change with ± icons without names (4.1.2); removing an item with a bin icon without a label; recalculating the total without an announcement; a discount code error shown only by colour (3.3.1).
Identification
Login / guest; fields without
labelandautocomplete(1.3.5, 3.3.2); live validation that moves focus; being made to retype data (WCAG 2.2 3.3.7); CAPTCHA (1.1.1, 2.2 3.3.8).Delivery and payment
Method cards as images; an operator iframe without
title(4.1.2); a redirect without notice (3.2.5); a session timer with no way to extend (2.2.1); a payment button at 2:1 contrast (1.4.3, 1.4.11).Summary and consents
Checkboxes without labels (1.3.1); terms in a modal that does not trap focus and does not close on Esc (2.1.2, 2.4.3); a "tick the consents" error without saying which (3.3.1, 3.3.3).
Confirmation and account
Order status by icon alone; HTML e‑mails without alternative text; a PDF invoice without structure; order history as an image of a table.
Who is responsible for the payment gateway and other third‑party modules
Art. 18(2) speaks of payment services "that form part of that service". The payment operator is a service provider itself (consumer banking or a payment service) and answers for its own form. You answer for having chosen it, embedded it, and for the transition to and from it being accessible. The exclusion in art. 4(2)(b) (content not funded, not created and not under control) does not cover a module that is part of your sales process — you control its choice and configuration. Practically: choose operators with public accessibility information, test their form with the keyboard and a screen reader, put a WCAG clause into the operator contract. The same goes for the reviews system, chat, search, the instalment calculator and the delivery widget.
Marketplaces and selling on other people's platforms
Selling only through Allegro, Amazon or Etsy, you do not provide an e‑commerce service through your own website — the platform provides the service. But you answer for the content you put there: descriptions, photos with alternatives, parameters as text. Platforms pass the requirements on to sellers through their terms. Selling in parallel in your own shop, you are fully subject to the act.
What to put in the terms (art. 32(2)(1))
The act gives no template. A sensible "Accessibility" section in a shop's terms contains:
- a standard declaration: "The shop is designed in accordance with WCAG 2.1 level AA (EN 301 549)";
- the actual state: "The shop meets the requirements as regards … Known non‑conformities: … Planned removal date: …" — honestly, because this is what the authority compares with reality;
- the information needed to use the service (art. 32(2)(1)(b)): keyboard operation, shortcuts, high‑contrast mode, screen reader support, alternative ways to buy (phone, e‑mail);
- the complaints channel under art. 37(1)(3): e‑mail address or form, phone, postal address; the 30‑day deadline; instructions on notifying PFRON;
- the date of the last conformity assessment (art. 32(1)) and the person responsible.
The section should also be a separate page linked from the footer — art. 32 requires the information to be "in an accessible way", and terms in a modal at checkout are not.
Shop platforms — what is in the box
| Platform | Baseline | Watch out for |
|---|---|---|
| Shopify | Shopify's own Online Store 2.0 themes are audited; the Shopify checkout is accessible | marketplace themes, apps that add sections, custom scripts |
| WooCommerce | the core is good; quality depends on the theme and plugins | page builders, basket/checkout plugins, carousels; overlay plugins do not fix the code |
| PrestaShop | the default "classic" theme needs contrast and focus fixes | payment and delivery modules — test each separately |
| Magento / Adobe Commerce | Luma has known gaps; Hyvä does better | product configurators, custom lists |
| Shoper, IdoSell, Sky‑Shop, Shoplo (Polish SaaS) | depends on the template; vendors publish WCAG information to varying degrees | ask the vendor for a conformity declaration for the template and test the checkout with the keyboard |
| custom code / headless | full control, full responsibility | custom components (select, modal, tabs) without ARIA — how to do it |
A complaint in a shop — what it really looks like
A consumer could not complete a purchase with a screen reader; they write to the address in the terms, point out "the payment button is not read out" and demand to be able to pay. From that moment you count 30 days (art. 37(2)). A good reply: acknowledgement, a description of the fix with a deadline (max 6 months, art. 37(5)(1)(b)), a temporary alternative (a phone order with a payment link), the signature of a person with name and position (para. 5(2)). A bad reply: silence — after 30 days the demand is upheld, and not fulfilling it within 6 months is a breach an inspection will ask about. The whole path to a fine.
The signals the checker sees
The report from the free check marks a page as a shop when it detects at least two independent signals: a basket, "add to basket" buttons, prices in structured data (Product/Offer), paths such as /cart, /checkout, /koszyk, shop platform scripts, a payment form. For a shop the report additionally checks the accessibility information (art. 32), the terms link and the contact channel (art. 37), and suggests which of the discovered pages — basket, login, checkout — need a separate check, because the home page is never where a shop fails.