If your company is not a microenterprise and uses a website or app to sell to consumers or let them start entering into a contract, digital accessibility has been a legal obligation for it since 28 June 2025. In Poland this comes from the act implementing the European Accessibility Act, known as the Polish Accessibility Act (Polski Akt o Dostępności). The act itself does not mention WCAG, but its technical reference point is the EN 301 549 standard, and the part of that standard covering websites carries over the WCAG success criteria at levels A and AA.
Below: who the rules cover and from when, what WCAG 2.2 requires of an online store and a company website, and how to test and fix a site, starting with the places where a customer tries to buy something. For every obligation we cite the provision or an official source.
- The Polish Accessibility Act has applied since 28 June 2025 and covers, among other things, e-commerce services provided to consumers. Services provided by microenterprises are excluded.
- PFRON treats as an e-commerce service any website where a consumer can send an enquiry or start entering into a contract, even if the transaction is completed offline.
- The reference point is the EN 301 549 standard. The formally cited version, V3.2.1, refers to WCAG 2.1, and version V4.1.1, published in September 2026, refers to WCAG 2.2.
- The obligations do not end with code: you need accessibility information in your terms of service, handling of consumer complaints within 30 days, and notification of shortcomings to the market surveillance authority.
- An automated test catches only some problems. The checkout path has to be walked through with a keyboard, at high zoom and with a screen reader.
Legal status as of 23 September 2026. This article describes the regulations and standards from the perspective of a company that builds websites and online stores. It is not legal advice. If you are not sure whether the act covers your company or whether you can rely on an exemption, consult a lawyer.
What the European Accessibility Act changed on 28 June 2025
The European Accessibility Act is Directive (EU) 2019/882 of 17 April 2019 on the accessibility requirements for products and services. Poland implemented it through the Act of 26 April 2024 on ensuring compliance with the accessibility requirements of certain products and services by economic operators (Journal of Laws, item 731). The act entered into force on 28 June 2025 and has not been amended since.
Before that, the obligation to make websites accessible in Poland applied mainly to public bodies, under a separate act from 2019. The Polish Accessibility Act extends it to private companies, but only in selected areas.
The act covers selected products, including computers, smartphones, payment terminals, ATMs and e-book readers, and selected consumer services: telecommunications, audiovisual media, digital elements of passenger transport, retail banking, e-books and e-commerce. For companies that have a website or an online store, the last item is the one that matters.
Who the act applies to: e-commerce services in practice
The act defines e-commerce services as services offered or provided at a distance through websites and mobile devices, by electronic means and at the individual request of a consumer, with a view to concluding a contract (Article 5(32)). The Ministry of Digital Affairs, which supervises this area, stresses on its page about e-commerce services that this means every form of offering services online, including services not named in the act, for example insurance, medical services, and the sale of clothes, cosmetics or medicines.
PFRON, Poland's State Fund for Rehabilitation of Disabled Persons, clarified where the line runs. In an answer from September 2025, the fund explains that if a business presents its products or services on its website and lets a customer send an enquiry or start the process of concluding a contract, it is providing an e-commerce service. It is enough that the customer can take the first step electronically. PFRON notes that its answers are for guidance only and are not a legal interpretation, but they were prepared in cooperation with the supervisory authorities.
The second condition is the consumer. The act covers services provided to consumers (Article 3(2)), meaning natural persons acting for purposes unrelated to their business or profession. A platform that sells only to businesses is not covered by the act. A store that serves both businesses and private individuals is.
Does the act cover a site like this?
| Situation | Assessment | What to watch out for |
|---|---|---|
| Store selling to consumers, company employs 30 people | Yes | The whole path: search, product page, cart, payment, account |
| Services website with an enquiry form for private individuals | Yes, according to PFRON | The form and the information needed to conclude a contract |
| Platform selling only to businesses | Outside the scope of the act | Business clients and public procurement may set their own requirements |
| Store run by a company that meets the microenterprise criteria | Microenterprise services are excluded | Check the status regularly, because a company can outgrow it |
| Brochure site with no form, booking or sales | Hard to point to any action aimed at concluding a contract | The assessment changes once a form or booking is added |
The exclusion for microenterprises comes from Article 4(1) of the act, which does not define the term itself. The directive treats as a microenterprise a company that employs fewer than 10 people and has an annual turnover or balance sheet total of up to EUR 2 million. Article 7 of the Entrepreneurs' Law (Prawo przedsiębiorców) contains a similar definition and requires the conditions to be checked in at least one of the last two financial years. If you are close to the thresholds, confirm your status with a lawyer or accountant.
The act also does not cover maps and interactive maps on websites, provided address data and location are presented in an accessible way, or content the company does not fund, create or control (Article 4(2)). Under Article 86, audio and video recordings and document files published before 28 June 2025 are excluded, as is archived content that nobody has updated or edited since that date.
Be careful with the transitional period to 2030. Article 85 allows contracts concluded before the act entered into force to remain unchanged until 28 June 2030, and allows continued use of products already in use within the meaning of the act, for example payment terminals. An online store's website is not such a product, so this provision does not give you five years to bring it into line.
A service provider's obligations: not just the website code
Article 32 of the act also imposes organisational obligations on the service provider. They are not about code, so it is worth assigning them to a specific person in the company straight away.
the service provider assesses on its own whether the service meets the accessibility requirements, and should be able to demonstrate this when the authority asks.
the terms of service or an equivalent document must include information about the service, the information needed to use it, and a description of how the service meets the accessibility requirements. That information must itself be accessible.
if the service does not meet the requirements, corrective action has to be taken, and later changes to the service, the law and the standards have to be taken into account.
the service provider must promptly inform the competent authority of any non-compliance, stating the scope of the shortcomings and the corrective action. For e-commerce this is the minister responsible for computerisation, who provides a template for this notice. According to PFRON, this also applies to temporary shortcomings, for example during a website rebuild.
a consumer can file a complaint about a lack of accessibility, and the company must deal with it within the statutory deadline.
The act provides two exemptions (Article 21): the requirements do not have to be met if that would require a fundamental alteration of the basic nature of the service or would impose a disproportionate burden. The company makes the assessment itself, comparing the net costs of compliance with the costs and revenue of the service in question. The assessment must be documented and kept for 5 years after the service stops being provided, and, according to guidance from the Ministry of Digital Affairs, the minister must be informed in writing that the exemption is being relied on.
A consumer complaint must include the consumer's name, contact details, the service concerned and the requirement the service does not meet, together with a demand that it be met. The company has 30 days to respond, and in particularly complex cases can extend the deadline to 60 days if it explains the reason for the delay within the original deadline. If it does not respond in time, the complaint is deemed to have been resolved in line with the consumer's demand, and the company has a maximum of 6 months to deliver it (Article 37). Separately from complaints, anyone can submit a notice of non-compliance to the President of the Management Board of PFRON, which can lead to an inspection (Articles 67 and 68).
Failure of a service to meet the requirements, as well as failing to carry out a conformity assessment or to notify the authority, can result in a fine of up to ten times the average monthly salary in the national economy for the previous year, but no more than 10% of turnover in the previous financial year (Article 73). The amount depends, among other things, on how serious the breach is and how many people it affects.
WCAG 2.2 in a nutshell: principles, levels and versions
WCAG, the Web Content Accessibility Guidelines, are guidelines published by the W3C consortium. They rest on four principles, which the Polish act repeats almost word for word in Article 12: content must be perceivable, the interface operable, the whole understandable, and the code compatible with browsers and assistive technologies, for example screen readers.
Each principle is broken down into success criteria at level A, AA or AAA. Conformance at level AA means meeting all A and AA criteria, and that is the target in EN 301 549.
WCAG 2.2 became a W3C Recommendation on 5 October 2023, and the current version of the document is dated 12 December 2024. In October 2025 the W3C announced that WCAG 2.2 had been approved as the ISO/IEC 40500:2025 standard, and according to EN 301 549 the two documents are identical. Version 2.2 added nine new criteria and removed one, 4.1.1 Parsing, which was considered obsolete. According to the W3C, content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and 2.1.
At the time of publication, WCAG 3.0 is a W3C Working Draft, not a standard.
EN 301 549: the link between the act and WCAG
The act describes the requirements in general terms: perceivable, operable, understandable, compatible. Article 20 makes them concrete: a service that conforms to harmonised standards is presumed to meet the requirements to the extent those standards cover them. In practice this means EN 301 549, the European accessibility requirements for ICT products and services.
In its list of standards for e-commerce services, the Ministry of Digital Affairs names version V3.2.1 from 2021 as the applicable one. It is available free of charge in English on the ETSI website, and PKN, the Polish Committee for Standardization, sells a Polish translation. This version refers to WCAG 2.1.
On 2 September 2026 ETSI published EN 301 549 V4.1.1. The new version adopts WCAG 2.2 as the basis for the requirements for websites, software and documents, and in it, conformance with WCAG 2.2 at level AA is equivalent to meeting the requirements for websites. As AccessibleEU, the European Commission's centre, points out, until the Commission publishes the reference to the new version in the Official Journal of the EU, V3.2.1 remains the reference point.
The conclusion for a project being built or rebuilt now is simple: design and test against WCAG 2.2 at level AA. That way you meet the WCAG 2.1 requirements cited in the current version of the standard, and once V4.1.1 is formally cited you will not have to go back to the same screens. The extra work mainly concerns the nine new criteria, six of which are at level A or AA.
A note for mobile apps: the new version of the standard clarifies that web views embedded in an app are assessed against the requirements for software, not for websites, so an app needs a separate review.
The nine new WCAG 2.2 criteria in an online store and on a company website
We give the criteria names as they appear in the W3C documentation.
The new WCAG 2.2 criteria in practice
| Criterion and level | What it means in practice |
|---|---|
| 2.4.11 Focus Not Obscured (Minimum), AA | A sticky header, cookie banner or chat window must not completely hide the element that has keyboard focus |
| 2.4.12 Focus Not Obscured (Enhanced), AAA | The focused element is fully visible |
| 2.4.13 Focus Appearance, AAA | The focus indicator is large enough and has a contrast of at least 3:1 between the focused and unfocused states |
| 2.5.7 Dragging Movements, AA | A price range slider, reordering or a map has an alternative that does not require dragging, for example number fields or buttons |
| 2.5.8 Target Size (Minimum), AA | Clickable elements are at least 24 by 24 CSS pixels, or have spacing that compensates; exceptions include links within text |
| 3.2.6 Consistent Help, A | If contact details, a chat or an FAQ appear on many pages, they must appear in the same order relative to the rest of the content |
| 3.3.7 Redundant Entry, A | Data entered earlier in the same process, for example a delivery address, is filled in automatically or available to select |
| 3.3.8 Accessible Authentication (Minimum), AA | Logging in must not rely solely on remembering, transcribing or solving puzzles; pasting a password and password managers must work |
| 3.3.9 Accessible Authentication (Enhanced), AAA | As above, but without the exception for object recognition tasks |
Two of these criteria are easy to miss. 2.4.11, because sticky elements are often added at the end of a project, for example as a marketing script, and nobody checks them with a keyboard. 3.3.8, because a password field that blocks pasting, or a one-time code that cannot be pasted, passes for a security measure. Criterion 3.3.8 does not ban passwords: it requires that users do not have to rely solely on memory and transcription, and pasting and password managers are explicitly listed as ways to meet it.
The most common barriers that block a purchase
Many of the barriers that actually prevent a purchase come from criteria that have been in WCAG for years. These are the easiest to check yourself:
- Form fields without labels. Placeholder text inside a field disappears once you start typing and is not a label. A screen reader then announces "edit field" with no name (criteria 1.3.1, 3.3.2, 4.1.2).
- Errors shown only by colour. A red border with no text tells neither a person with colour vision deficiency nor a screen reader what is wrong (1.4.1, 3.3.1).
- Contrast that is too low. Text needs a contrast of at least 4.5:1, and large text, from 18 point or 14 point bold, at least 3:1. Field borders, icons and button states need 3:1 against the background (1.4.3, 1.4.11).
- Elements that only work with a mouse. A button built from a
divelement, a menu that opens on hover, a modal you cannot leave with the Escape key, and a focus indicator hidden because it "looks ugly" (2.1.1, 2.1.2, 2.4.7). - Icon-only buttons. A magnifying glass, cart, heart and cross with no accessible name are indistinguishable to a screen reader (1.1.1, 4.1.2).
- A layout that falls apart when zoomed. Text must be resizable to 200%, and content must fit in a width of 320 CSS pixels without horizontal scrolling, which corresponds to 400% zoom on a screen 1280 pixels wide (1.4.4, 1.4.10).
- Carousels and motion with no pause. Content that moves automatically for more than 5 seconds alongside other content must be possible to stop (2.2.2).
- Time limits with no warning. A cart session or payment form that expires with no way to extend it (2.2.1).
- No page language. Without the
langattribute, a screen reader may read Polish text with English pronunciation (3.1.1).
These errors are usually fixed in the component code, without redesigning the look. Here is an example of a correctly described field with an error:
The label is tied to the field through for and id, so a screen reader reads out the field's name. The autocomplete attribute lets the browser fill in the data and serves criterion 1.3.5. The error message is text linked through aria-describedby, so it is read out together with the field, and aria-invalid marks the error regardless of the border colour.
How to test a site: from automated tools to a screen reader
Testing accessibility is not a single score in a tool. The W3C says plainly in its guide to selecting tools that tools cannot determine accessibility, they can only help assess it, and some criteria cannot be checked automatically. A sensible order looks like this:
home page, search, product listing with filters, product page, cart, delivery and payment, registration and login, contact form, terms of service. Check every template type at least once.
the axe extension, a Lighthouse report, whose accessibility audits are based on the axe-core library rules, or WAVE. You are looking for missing labels, button names, contrast problems and misused ARIA attributes.
walk the checkout path with the keyboard alone: Tab, Shift+Tab, Enter, Space, arrow keys, Escape. Check that focus is visible, the order is logical, the banner and modal can be closed, and focus does not disappear under a sticky header.
set zoom to 200%, then a window width of 320 pixels. Nothing should overlap or disappear, and the page should not require horizontal scrolling.
NVDA on Windows is free, VoiceOver is built into macOS and iOS, and TalkBack into Android. Place a test order. Check that buttons have names, form errors are read out and a change in the number of items in the cart is announced.
image alt text, heading hierarchy, "read more" style links, video captions, PDF documents.
each problem as a separate item: criterion, URL, description, priority. This list is the basis for the information in your terms of service, any notice to the market surveillance authority and the fix plan.
Run the automated check on every change, and the manual test on changes to the checkout path and before major releases. It needs no specialist equipment: a keyboard, a browser and a free screen reader are enough.
How to fix it: the order that removes the most barriers
A full review of a store can produce a long list of items, so the order matters.
Blockers on the checkout path come first: anything that prevents adding a product to the cart, entering details, choosing delivery or paying.
The second rule is to fix components, not pages. A form field, button, modal, menu and product card repeat across the whole site. One fix in a component removes the same error from every place it is used, and new pages are correct from the start.
The third is third-party services. The payment gateway, reviews widget, chat and booking system are all part of the path the customer goes through. Article 18 of the act explicitly lists making payments as an element of an e-commerce service that has to be perceivable, operable, understandable and compatible. Ask your providers for accessibility information about their solutions and test their elements the same way you test your own.
The fourth is protection against regressions. Automated tests can be added to the application's end-to-end tests, so that every change to the cart is checked before it reaches production:
A test like this will not replace walking the path with a keyboard, but it will catch typical regressions: a button with no name, a field with no label or a colour that has lost its contrast.
The fifth is about editorial work: informative images have alt text, headings form a hierarchy, text is not baked into graphics and videos have captions. The content panel can enforce some of this, for example by blocking publication of an image with no alt field.
Accessibility overlaps with other areas. We described entrance animations that switch off when the system reduced motion setting is on in our article on Core Web Vitals in practice. Correct headings, alt text and content in HTML also help search engine crawlers, as we explain in our technical SEO checklist before launching a website.
Accessibility overlays and widgets will not replace fixes in the code
There are widgets on the market that, once you paste in a single script, add a button to the site with options to enlarge text or change contrast, and promise legal compliance with no code changes. A button like that does not add labels to form fields, does not fix the focus order in the cart and does not give names to icon buttons. People who use screen readers or magnification have their own configured tools and need a website that works with them, not a second set of options.
In April 2025 the US Federal Trade Commission approved a final order under which the maker of one such overlay will pay USD 1 million for misleading claims that its AI-powered tool could make any website WCAG compliant. Polish law holds the service provider accountable for whether the service meets the requirements, not for which tool it installed.
Accessibility information in your terms of service: what to include
The obligation under Article 32(2)(1) of the act should not be confused with the accessibility statement that public bodies publish. PFRON explains that the information about how the service meets the requirements goes into the terms of service or another equivalent document, for example general terms and conditions or a document for a specific service. A standalone page on the website is not enough if the customer is not told where to find it.
The act does not provide a template for this consumer information. A sensible outline that is easy to keep up to date covers:
- Which service the information concerns: the store address, the app, the contact channels.
- Which technical requirements were adopted, for example WCAG 2.2 at level AA and the EN 301 549 standard, and when conformity was last assessed.
- How to use the service with assistive tools: keyboard operation, zoom, screen readers.
- Known limitations and how to work around them, for example the option to place an order by phone, together with the planned date for a fix.
- How to file a complaint about a lack of accessibility, through which channels, and within what time the company responds.
The information must itself be accessible. Terms of service as a scanned PDF do not meet the requirements of Article 12, which also cover the form: a text format, a legible font and sufficient contrast.
A new project or an existing store
In a new project, accessibility costs the least when it is a requirement from the first wireframe: contrast is checked in the colour palette, target size in the component system, and keyboard support is written together with each component. It is worth stating explicitly in the project scope: the conformance level, the list of paths covered by manual testing, the automated testing tools, and who prepares the information for the terms of service.
With an existing store, start with a review of the checkout path and with the question of which platform the store runs on. In subscription store platforms, some problems sit in the theme and the payment module, which you have limited influence over. In that case the list of errors is also a list of questions for the provider. If you are still choosing between a marketplace and your own store, we described the differences in legal obligations between the two channels in Your own online store or Allegro.
Prepare a test environment with a working test payment for the review. Without it, the review stops at the cart.
Frequently asked questions
Does digital accessibility apply to a small business?
Services provided by microenterprises are excluded from the Polish Accessibility Act. The directive defines a microenterprise as a company employing fewer than 10 people, with an annual turnover or balance sheet total of up to EUR 2 million. A company that does not meet these criteria and sells to consumers online is subject to the act even when the store is not its main sales channel.
Does a company website without a store have to be accessible?
It depends on what can be done on it. According to PFRON, a website where a consumer can send an enquiry or start entering into a contract is an e-commerce service. A website aimed only at businesses is not covered by the act.
Do I have to meet WCAG 2.2, or is WCAG 2.1 enough?
As of 23 September 2026, the formally cited version of EN 301 549, V3.2.1, refers to WCAG 2.1. The new version V4.1.1, published by ETSI on 2 September 2026, is based on WCAG 2.2. If you are designing now, aim for WCAG 2.2 AA: you will meet both.
Is an accessibility statement on the website enough?
An accessibility statement is an obligation for public bodies under a different act. Companies covered by the Polish Accessibility Act provide information on how the service meets the requirements in their terms of service or an equivalent document. An accessibility page can complement it, but does not replace it.
Who inspects online stores and what are the penalties?
For e-commerce services, the market surveillance authority is the minister responsible for computerisation, and the President of the Management Board of PFRON also accepts notices from anyone. A fine can reach ten times the average monthly salary for the previous year, but no more than 10% of annual turnover.
Accessibility planned from the first wireframe
Digital accessibility costs the least when it is written into the project scope just like performance or the mobile version. Bolted on after acceptance, it means going back to finished screens.
If you are planning a new website or a store rebuild and want to discuss accessibility requirements before the quote is prepared, get in touch through the contact form. You will find the types of projects we deliver on the offer page, and how we work from brief to acceptance on the process page. After handover you get full rights to the code and documentation, so further fixes can also be handled by another team.
