The Accessibility Act (EAA) — do your app and online store have to meet WCAG 2.2

Let us start with a correction, because a lot of misleading headlines circulate online: no regulation currently mandates conformance with WCAG 2.2. What is legally binding is WCAG 2.1 at level AA — and it has been for over a year. But if you are building a digital product whose life cycle reaches into 2027, aiming at 2.2 is simply cheaper than doing the same work twice. Below we explain why, and exactly what you need to have.

The Act of 26 April 2024 on ensuring that economic operators meet the accessibility requirements of certain products and services (Journal of Laws 2024, item 731) — Poland's implementation of Directive 2019/882, the European Accessibility Act — entered into force on 28 June 2025. This is no longer an "upcoming regulation". It is law in force, and 2026 is the first year in which supervisory authorities are genuinely ramping up.

Note: this article describes the requirements at a technical and product level. The legal classification of a specific business — whether you are in scope, whether an exemption applies, whether you can invoke a safeguard clause — is a conversation for a lawyer. Do not treat the following as legal advice.

Who this actually applies to

The Act covers designated products (computers, smartphones, payment terminals, ATMs, ticketing machines, e-book readers) and designated consumer services. From a product team's perspective the latter matter most:

• e-commerce — online stores and sales apps aimed at consumers,
• retail banking services — online and mobile banking, onboarding, credit applications,
• passenger transport services — websites, apps, ticket sales and booking, travel information,
• telecommunications services, access to audiovisual media services, e-books.

The key test for e-commerce is simpler than it looks: do you sell to consumers via a website or an app? If so, you are in scope — regardless of whether you sell shoes or a SaaS subscription.

Exemptions you can count on

• Micro-enterprises providing services (up to 9 people and turnover up to EUR 2 million) are exempt from the obligations. Note: the exemption covers services. A micro-business dealing in products only has limited administrative obligations, not a full exemption.
• Disproportionate burden and fundamental alteration of the product/service — safeguard clauses allow you to depart from some requirements. This is not a "we can't be bothered" loophole, though: you must carry out and document the assessment and present the documentation to the authority on request. Invoking these clauses without the paperwork is worse than not invoking them at all.
• A transitional period until 28 June 2030 applies to services provided under contracts concluded before 28 June 2025 — a buffer for contracts in progress, not a licence to build new inaccessible screens.

Where WCAG fits in — and why 2.1 rather than 2.2

This is where most articles online get it wrong. The chain looks like this:

The Act (EAA) speaks of functional accessibility requirements but does not name WCAG. → A presumption of conformity goes to whoever meets a harmonised standard, i.e. one referenced in the Official Journal of the EU. → For ICT that standard is EN 301 549. → The version currently harmonised is V3.2.1 (referenced in the OJ EU by implementing decision 2021/1339 of August 2021), and it points to WCAG 2.1 level AA.

WCAG 2.2 was published as a W3C Recommendation on 5 October 2023, but it is not yet part of the harmonised version of the standard. The draft EN 301 549 V4.1.0, which pulls in WCAG 2.2 AA, went to review in November 2025; the final V4.1.1 is expected in the Official Journal roughly around October 2026. Standardisation timelines do slip — check the current state before you build a project schedule on them.

The practical conclusion for a team:

• You must meet WCAG 2.1 AA today. That is your line of defence before a supervisory authority.
• You should design against WCAG 2.2 AA. The difference is only a handful of criteria, and rewriting the same frontend a year from now costs many times more than doing it properly today.

What exactly WCAG 2.2 adds

WCAG 2.2 is backwards compatible with 2.1 — it invalidates nothing and adds nine criteria (one, 4.1.1 Parsing, was withdrawn). The ones that genuinely hurt most often in e-commerce:

• 2.4.11 Focus Not Obscured (AA) — the focused element must not be hidden behind a sticky header, cookie bar or chat widget. A classic: a keyboard user "disappears" under the sticky bar in the cart.
• 2.5.7 Dragging Movements (AA) — every drag operation must have a non-drag alternative (price sliders, sorting, changing quantity).
• 2.5.8 Target Size (Minimum) (AA) — touch targets of at least 24×24 px, with exceptions. This hits dense pagination and the little "×" icons next to cart items.
• 3.2.6 Consistent Help (A), 3.3.7 Redundant Entry (A) — help in the same place on every screen; do not make users re-enter data they have already provided (delivery vs billing address).
• 3.3.8 Accessible Authentication (AA) — logging in must not require a cognitive test (transcribing a code from memory, a puzzle). Pasting and password managers must work. This criterion upends quite a few "creative" login flows in banking.

What fails in practice in stores and apps

Audits in Polish e-commerce keep coming back with the same set of problems. The order roughly matches how often they occur:

1. Contrast and focus states. Grey text on white below 4.5:1 and outline: none in the CSS reset. The cheapest class of errors to fix and the most common.
2. Forms without labels. A placeholder is not a label. Validation errors conveyed by colour alone, with no text and no aria-live. A checkout where the screen reader does not say what went wrong is an insurmountable barrier.
3. Keyboard navigation. Modals without a focus trap, dropdowns that only work on hover, inaccessible product filters, no "skip to content".
4. Undescribed interactive elements. <div onclick> instead of <button>, icons without an accessible name, carousels without a pause control.
5. Images and media. Empty alt where the image carries meaning (and a product photo does), no captions on video.
6. Dynamic updates. Add-to-cart, item counters, availability messages — changes a screen reader never learns about.

Mobile apps add a native layer: accessibility labels for VoiceOver and TalkBack, response to the system font-size setting (the layout has to survive 200% — in our experience CTA buttons are what break first), support for reduced motion, and no forced screen orientation.

What an overlay will not solve

Worth saying plainly: "accessibility overlay" widgets do not deliver conformance. A JS overlay that bolts on a floating icon and swaps contrasts will not fix HTML semantics, unlabelled forms or keyboard navigation — and sometimes adds barriers of its own. In several jurisdictions companies running such overlays still collected lawsuits. Treat them as cosmetics, not compliance.

Obligations teams forget about

Technical conformance is not everything. The Act also imposes information and procedural duties:

• Information about the accessibility of the service — you must publicly describe how the service meets the requirements. In practice: an "Accessibility statement" page in the footer, maintained and current, not copied from somebody else's site.
• A barrier reporting procedure — a consumer can report that something is unusable. You then have 7 days to respond: what you will do about it and when. That is an operational deadline that has to be wired into customer service and the backlog, not discovered on the day of the first report.
• Conformity assessment documentation — especially if you invoke disproportionate burden. It has to exist before the question arrives.

Supervision is spread across seven authorities in Poland — among them the electronic communications, rail, civil aviation and road transport regulators, maritime offices, the Financial Ombudsman and the digitisation ministry — and which one applies depends on the type of service. The administrative fine reaches ten times the average monthly salary for the preceding year, capped at 10% of turnover from the previous financial year.

Honestly: for a large store the fine itself is rarely the main risk. What hurts more is the cost of fixing things under time pressure — rewriting a checkout in emergency mode, on a deadline set by an authority, costs many times more than planned work. And there is a second, less obvious argument: roughly 12% of adults in Poland have a certified disability, and barriers in the cart also hit older users, users on poor connections and users in bright sunlight. An inaccessible checkout is an abandoned cart, whether or not anyone ever complains about it.

Where to start — a realistic plan

If you do not know where you stand today, a sensible order looks like this:

1. Measure the starting point (days, not weeks). Automation (axe, Lighthouse, Pa11y in CI) will catch 30–40% of problems — which is a lot and very little at the same time. The rest cannot be detected by a script: whether alt text makes sense, whether the focus order is logical, whether an error message is actually understandable. Automation says "no label"; it does not say "the label is meaningless".

2. Audit critical paths manually. Not the whole site — the paths that generate revenue: search → product page → cart → checkout → payment → account. Keyboard, screen reader (NVDA/VoiceOver), 200% zoom, high contrast mode.

3. Prioritise by risk and traffic. Blockers on the purchase path go first. Footer contrast can wait.

4. Fix at the source, not with patches. If you use a design system, a fix in the Button/Input/Modal component repairs hundreds of screens at once. That is where accessibility becomes cheap.

5. Wire it into the process. axe tests in CI on pull requests, accessibility criteria in the definition of done, accessibility in code review. Without that you drift back to the starting point within two quarters — the most common scenario we see in companies that ran a one-off audit and ticked the box.

6. Document it. Accessibility statement, reporting procedure, conformity assessment.

Summary

• The act implementing the EAA has been in force since 28 June 2025 — that is a fact, not a plan.
• What binds today is WCAG 2.1 AA via the harmonised EN 301 549 V3.2.1. WCAG 2.2 enters the standard with V4.1.1, expected in the Official Journal around October 2026.
• Build against 2.2 AA. The excess over the requirement is small, and it protects you from rewriting the same thing a year later.
• Beyond code: an accessibility statement, a reporting procedure with a 7-day deadline, and assessment documentation.
• Overlays do not deliver conformance. Fixes in the design system and tests in CI do.

We run WCAG 2.2 accessibility audits for online stores, web apps and mobile apps. We do not leave you with a PDF listing 300 errors — you get a report ordered by risk and traffic, concrete fixes at component level, and tests wired into CI so regressions do not come back. If you want to know where you really stand before WCAG 2.2 enters the standard — get in touch.