Websites and online stores
European Accessibility Act and your website: what to change in the template
Part of the guide: Core Web Vitals Thresholds: LCP, INP and CLS Explained
For most site owners the European Accessibility Act comes down to a single question: what exactly has to change in the template so the site can be used without a mouse, without good eyesight and without guesswork. The requirements have applied since 28 June 2025, and microenterprises are the only businesses exempt. Below is the part most write-ups skip — a requirement-to-fix map you can paste straight into a scope of work. This is information, not legal advice.
Who the European Accessibility Act covers, and who is exempt
The European Accessibility Act is Directive (EU) 2019/882 of 17 April 2019 on the accessibility requirements for products and services, applicable since 28 June 2025. It is a directive, so it binds every EU member state, but each state enforces it through its own implementing law. In Poland that law is the act of 26 April 2024 on ensuring that economic operators meet the accessibility requirements of certain products and services (Dz.U. 2024 poz. 731), published on 15 May 2024 and in force since 28 June 2025; it is commonly called the Polish Accessibility Act. If your company is established elsewhere in the EU, the directive is the same but the national statute is not, so read the local one.
The scope covers e-commerce, retail banking services, e-books, passenger transport services and audiovisual media services, and on the hardware side computers, smartphones and ATMs. For the Polish implementation, biznes.gov.pl lists the obligated parties as manufacturers, authorised representatives, importers, distributors and service providers — which includes a company that simply sells online under its own brand.
Microenterprises are exempt. This is the only exemption based on the size of the company, so a small company above the micro threshold is already covered. Do not guess the definition from memory: read it in the statute that applies to you, or check it with a lawyer, because everything downstream depends on it.
What the 28 June 2030 transition period actually covers
28 June 2030 is not a general grace period. The requirements cover products placed on the market after 28 June 2025 and services offered and provided after that date. A separate rule says that service contracts concluded before 28 June 2025 may continue unchanged until they expire, and no longer than 28 June 2030.
The difference is practical. “The shop was live before June 2025” is not the same statement as “a service contract concluded before 28 June 2025 is still running unchanged”. A new site, a new template and a substantial rebuild of an existing one are all cases where 2030 is nothing to lean on. If a redesign is on the roadmap anyway, accessibility is cheaper inside the scope from the start than as fixes after acceptance. How deep those fixes can go depends on what the site runs on, which is the WordPress versus a custom website decision — a bought theme and its plugins limit what you can change in the markup.
Which standard and which level: AA or AAA, WCAG 2.1 or 2.2
The reference level is AA, not AAA. WCAG (Web Content Accessibility Guidelines) is a set of success criteria in three conformance levels — A, AA and AAA — and EN 301 549, the technical standard referenced in the context of EU conformance, points to WCAG at level AA for web content.
The versions: WCAG 2.0 of 11 December 2008, WCAG 2.1 of 5 June 2018, and WCAG 2.2 of 5 October 2023 with an update of 12 December 2024. WCAG 2.2 is an approved ISO standard — ISO/IEC 40500:2025. WCAG 3.0 remains an early draft and is not a recommendation, so no proposal should rest on it. Whether the rules point at 2.1 AA or 2.2 AA has not been officially settled in Poland, and it is answered by each member state in its own implementing law: the market works on 2.2, the reference level is AA, and the exact reference belongs in the statute rather than in a vendor deck.
The map: accessibility requirement to a specific template fix
The table below turns the requirements into tasks a development team can price and tick off. Every row is written to be pasted into a scope of work.
| Requirement | Fix in the template | How to verify at acceptance |
|---|---|---|
| Text contrast | Replace grey captions, placeholders, text on banners and hover states with colours that pass the contrast test for level AA; set them once in theme variables, not case by case | An axe or WAVE report plus a manual review of text sitting on photographs |
| Visible focus | Remove the global outline: none from the CSS; add a clear :focus-visible style for links, buttons, fields and menu items |
Tab through the home page — the ring is visible at every step |
| Keyboard operation | Swap clickable <div> elements for <button> and <a>; the menu, filters, carousel and product variant picker have to work without a mouse |
The full path from the listing to placing an order, keyboard only |
| Form field labels | Every field gets a <label for> tied to an id; the placeholder stops being the only label; address fields get autocomplete |
Clicking the label puts the cursor in the field it belongs to |
| Alternative text | Product photos describe the product, not the file name; decorative graphics get an empty alt attribute; icon-only buttons get an accessible name |
A review of the listing and the product page, not an automated report alone |
| Heading structure | One first-level heading per page and no skipped levels below it; a bold paragraph stops pretending to be a heading | The page outline view in WAVE |
| Error messages | The validation error appears next to the field, is programmatically associated with it and says what to correct, instead of a generic “form error” | Submitting the order form empty and then filled in incorrectly |
| Touch target size | Enlarge the clickable area of icons (bin, quantity stepper, modal close) and separate adjacent actions on mobile | A test on a phone, with a thumb, one-handed |
| No focus traps | Modals and the mobile menu take focus when they open, close on Esc and return focus to the element that opened them | Open a modal and press Tab a dozen times — focus does not escape underneath |
If some of the forms — cart, payment, account registration — are rendered by an external system, the fixes have to be agreed on that side as well; this is the cost that hides in projects where system integration was planned around data rather than the interface. Most of the changes above touch the same template files you edit when improving Core Web Vitals, so it pays to commission one package of work instead of two.
What you can check yourself in half an hour, and what automation will not catch
Four things fit into half an hour: the Lighthouse report built into the browser, a WAVE and axe scan on the home page and a product page, a full pass through the checkout path using the keyboard alone, and a contrast check wherever text sits on a photo or on a brand colour. The keyboard pass is the most valuable of the four — it shows whether someone can buy, not just whether they can look. Lighthouse will also measure page loading performance along the way, which usually gets fixed together with accessibility.
Automated tools check what can be written as a rule: a missing alt attribute, a field with no label, two colours whose contrast is too low, an ARIA attribute used incorrectly. They cannot judge whether the alternative text actually describes the photograph, whether the focus order matches the page layout, whether an error message is understandable, or whether a label matches the field it stands next to. A clean report therefore does not mean the site is accessible, and nobody should declare full WCAG conformance on the strength of an automated audit alone.
The accessibility statement: what to put in it and where to keep it
An accessibility statement is a publicly available page describing the current state of the site and how to report a problem. Four elements belong in it: the conformance status (full, partial or none), the date it was drawn up and the date it was last updated, a list of known non-conformities together with what will be corrected and when, and a reporting channel — an email address or a form, with the response time you commit to.
Keep the link to the statement in the footer, next to the terms and the privacy policy, as an ordinary page rather than a PDF file. Do not write that the company “is EAA compliant”: conformance is assessed against a specific service and the current state of the site, so describe the state, the scope and the date instead of a declaration made once and for all.
Who handles complaints, and how to write the requirement into an RFP
Which authority handles complaints depends on the member state, because each one designates its own. In Poland, complaints about a lack of accessibility go to the President of the Management Board of PFRON, who may deal with the case directly or refer it to the competent market surveillance authority — among them the President of UKE, the minister responsible for digital affairs, the President of UTK or the Financial Ombudsman. Penalties are imposed by administrative decision. That is reason enough to write the accessibility requirement into your request for proposals as precisely as the rest of the scope you set out in a software project brief. If you would rather have the fix list drafted first, describe the site to us and we will come back with the order the work makes sense in.
"The site is to meet the accessibility requirements at level AA against the standard named in the contract. The supplier delivers: a report from an automated tool (axe or WAVE) with no critical errors, the result of a full checkout path walked with the keyboard alone, a list of completed template fixes broken down into contrast, visible focus, field labels, alternative text, heading structure, error messages, touch targets and focus traps, and the text of the accessibility statement. Acceptance follows manual verification, not the automated report on its own."
Checklist
Read the statute that applies where your company is established and check whether it counts as a microenterprise
Establish whether the service is offered after 28 June 2025 or runs on a contract concluded before that date
Walk the whole checkout path with the keyboard alone and note every place where focus disappears or loops
Run axe or WAVE on the home page, a product page and the cart, and attach the results to the scope of work
Order the template fixes: contrast, visible focus, field labels, alternative text, heading structure
Publish an accessibility statement with the status, update date, known non-conformities and a reporting channel
Write acceptance into the contract as a manual test, not as an automated tool report on its own
Frequently asked questions
- Does the European Accessibility Act apply to my online shop if I only employ a few people
- Only microenterprises are exempt, not small companies in general. Above the microenterprise threshold, e-commerce falls within the scope of Directive (EU) 2019/882 and of the national law implementing it — in Poland the act of 26 April 2024 (Dz.U. 2024 poz. 731). Check the definition of a microenterprise in the statute that applies where your company is established, or with a lawyer, because every other obligation follows from it.
- My shop was already live before 28 June 2025 — do I have until 2030
- Not in the form in which that claim circulates online. The requirements cover services offered and provided after 28 June 2025. A separate rule says that service contracts concluded before 28 June 2025 may continue unchanged until they expire, and no longer than 28 June 2030. That is an exception for specific contracts, not a grace period for every website.
- Which WCAG level is required: AA or AAA
- AA is the reference level in practice. WCAG defines three conformance levels — A, AA and AAA — and EN 301 549, the technical standard referenced in the context of EU conformance, points to WCAG at level AA for web content. AAA is the highest level and is not a typical acceptance threshold for a commercial site.
- WCAG 2.1 or 2.2 — which version should I build to
- There is no official ruling on which version the Polish rules point to, so it should not be treated as settled, and the implementing law of another member state may answer it differently. The market works today on WCAG 2.2 of 5 October 2023 (with an update of 12 December 2024), which is an approved standard as ISO/IEC 40500:2025. AA remains the reference level, and the exact reference is worth checking directly in the statute that applies to you.
- Is an accessibility overlay or widget enough to meet the requirements
- The claim that an overlay delivers legal conformance comes from vendor marketing materials, not from a legal finding. A script bolted onto a finished page does not change the HTML structure, the form labels, the focus order or the meaning of alternative text. The requirements are met by fixes in the template itself, which can be verified in the code and by a manual test.
- Who supervises compliance with the accessibility rules
- That depends on the member state, because each one designates its own authorities. In Poland, complaints about a lack of accessibility are received by the President of the Management Board of PFRON, who may handle the case directly or refer it to the competent market surveillance authority — among them the President of UKE, the minister responsible for digital affairs, the President of UTK or the Financial Ombudsman. Penalties are imposed by administrative decision.
Sources and methodology
These links lead to primary sources and the rules we use to prepare and update our material.
- EUR-Lex — European Accessibility Actaccessed: 2026-08-14
- W3C — Web Content Accessibility Guidelines 2.2accessed: 2026-08-14
- GESEL.IO editorial policy