WCAG compliance — who it actually binds and what has to be done

For years digital accessibility in Poland was a matter for public bodies. Directive (EU) 2016/2102, transposed by the Act on Digital Accessibility of Websites and Mobile Applications of Public Entities (ustawa o dostępności cyfrowej, 2019), covered the public sector; private firms treated WCAG as good practice — worth doing, not required.

On 28 June 2025 that changed. Obligations came into force for part of the private sector, with penalties of up to tens of thousands of złoty and with authorities to impose them.

The scale of the problem is not niche. WebAIM's annual analysis of a million home pages found in 2026 that 95.9% of them have detected WCAG violations — up from a year earlier. The average number of errors per page rose from 51 to 56.1. After years of slow improvement, the trend reversed.

This text answers three questions in order: does the obligation reach you, what exactly has to be done, and how much free tools catch. We start with the first, because the commonest claim on this subject — "everyone except microenterprises is covered" — is untrue.

Where the new obligation came from

The basis is Directive (EU) 2019/882, the European Accessibility Act. It exists to harmonise the internal market: a manufacturer who adapted a product in one country should not have to adapt it again in another.

Every Member State transposed it, and the obligations apply from 28 June 2025 across the EU. Article 2 sets the scope as a closed list of products and services — and that closed list is the most important thing here.

Four dates, two instruments

These are two different regimes, and mixing them up is the commonest source of confusion. An authority, a school or a library has been bound since 2020, under the older instrument. An online shop since 2025, under the newer one.

Who enforces, and what non-compliance costs

The EAA sets no penalty amounts. Article 30 requires Member States to lay down penalties that are "effective, proportionate and dissuasive", so the number that applies to you comes from the law of the country judging you, not from the directive. In Poland that is the act of 26 April 2024 on ensuring that economic operators meet the accessibility requirements of certain products and services (ustawa o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze, Journal of Laws 2024, item 731).

Supervision is not one body. The market surveillance system is made up of the President of the Management Board of PFRON (the State Fund for Rehabilitation of Disabled Persons), the market surveillance authorities and the customs authorities (Article 38(2) of the act). The authority depends on the service: for e-commerce it is the minister responsible for digitisation, for retail banking the Financial Ombudsman (Rzecznik Finansowy), for telecoms and e-books the President of UKE (the Office of Electronic Communications), and for services ancillary to passenger transport the relevant transport inspectorates and offices (Article 38(3)). The President of PFRON monitors the whole system and oversees those authorities (Article 39), but is not merely a coordinator: PFRON can itself carry out an inspection and impose a penalty (Article 39(7), Article 73(3)), and every notice about an inaccessible service goes to it first — it either handles it or, within 30 days, passes it to the competent authority (Articles 67–68). A firm therefore answers to its sector authority and to PFRON.

Penalties are two-tier, and this is where most publications simplify in a misleading way. The act allows a penalty of up to ten times the average monthly wage for the previous year (PLN 8,903.56 for 2025, so the maximum is about PLN 89,000), but no more than 10% of the previous financial year's turnover (Article 73(1)). That is a ceiling, not a rate: the amount depends on the gravity of the breach, the number of inaccessible products or services and the number of people harmed (Article 73(4)).

The difference is practical. For a large company the ceiling barely binds and the upper limit is that eighty-odd thousand. For a small firm the ceiling can fall much lower. The headline "a penalty of up to 10% of turnover" sounds more threatening than the construction of the provision warrants.

Does the obligation reach you specifically

The directive covers a closed list of products and services aimed at consumers. It does not cover "firms" in general.

The services include:

• e-commerce — online shops, marketplace platforms, booking systems
• consumer banking and financial services
• passenger transport services — tickets, timetables, mobile apps
• electronic communications services
• services providing access to audiovisual media services
• e-books and dedicated reading software

Plus a list of products: general-purpose computer hardware and its operating systems, smartphones and other consumer terminal equipment, self-service terminals such as payment terminals, cash machines and ticketing machines, and e-readers.

The product–service distinction is not a formality. A product's manufacturer, importer and distributor carry different obligations from a service provider. A firm selling its own device online can be caught from both sides: as a shop and as an operator placing a product on the market.

The microenterprise exemption and its trap

Microenterprises are exempt — under the directive's definition, firms employing fewer than 10 persons AND with an annual turnover or balance sheet total not exceeding 2 million EUR (Article 3(23)). Both conditions together.

But the exemption has an edge that is easy to miss: Article 4(5) exempts microenterprises providing services — not those placing products on the market. A microenterprise running an online shop is exempt as a service provider. One putting a terminal or an e-reader on the market is not.

A table you can send to the board

The last two rows and the one about B2B firms are the most important here, because they say what the industry dislikes saying: many readers have no obligation at all. A machine manufacturer selling only to other firms is not covered. It may want accessibility for other reasons — we come to those — but it does not have to.

WCAG, or how accessibility is measured

The directive does not describe what an accessible page looks like. It points to the harmonised European standard EN 301 549, which names WCAG at level AA as the technical standard.

WCAG rests on four principles, POUR:

• Perceivable — information can be received whatever sense is available. A product photo has a description, a video captions, a sale price enough contrast to read with weaker eyesight. Test: turn images off and see whether the page still says what it meant to.
• Operable — the interface works without a mouse, without a time limit and without traps. Test: go through the purchase process on the Tab key alone.
• Understandable — content and behaviour are predictable. A field has a label that does not disappear, an error message says what to correct, the menu looks the same on every page.
• Robust — the code is correct enough for assistive technologies to cope. The one an automated tool checks well, and therefore the one most teams have under control.

There are three conformance levels: A, AA and AAA. The legal reference point is AA — A is a minimum nobody treats as sufficient alone, and AAA is sometimes impossible across a whole site.

WCAG 2.1 or 2.2

The legal requirement today is WCAG 2.1 AA, through EN 301 549 V3.2.1 of March 2021 — the version cited in the Official Journal, and that citation is what creates the presumption of conformity.

It is about to move. ETSI published EN 301 549 V4.1.1 on 2 September 2026, aligning the standard with WCAG 2.2 AA. Publication by ETSI and citation in the Official Journal are two different events, and at the time of writing the citation had not happened. So 2.1 AA binds now, 2.2 AA will bind.

WCAG 2.2 has been the W3C Recommendation since 2023 and adds nine success criteria, of which six sit at level A or AA and therefore matter in practice:

One change almost nobody writes about: criterion 4.1.1 Parsing was removed in 2.2. Duplicate id attributes stopped being a violation. If a report still counts them as errors, the report is older than the standard.

Conformance works in one direction only: according to the W3C, content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and WCAG 2.1 — the reverse does not hold.

Building a new site, we would aim at 2.2 straight away — the extra effort is small and the reference point is moving there.

Six errors account for almost everything

The interesting thing in the WebAIM data is not that 95.9% of sites have errors. It is that six types of violation account for 96% of all errors detected.

That is good news dressed as a bad statistic. The repair is not bottomless — six things clear almost everything tools can detect at all. A second result from the same study confirms it: 20.5% of pages have five errors or fewer, and 30.4% no more than ten.

Three families of barrier

Visual. Missing alternative text turns a product photo into "image", and that is all a screen reader user hears. Contrast that is too low excludes not only people with low vision but anyone looking at a screen in sunlight. A separate category is information conveyed by colour alone — a red border round a field carries no content for someone who cannot distinguish that colour.

Navigational. A site that cannot be navigated with a keyboard is closed to some users entirely. A focus trap — a modal Tab cannot escape — can end the session for good. Then heading structure: if H1, H2 and H3 are chosen for looks rather than hierarchy, a screen reader loses the map of the page, because headings are its table of contents.

Multimedia. Video without captions excludes deaf users, and anyone watching without sound — which is how most mobile traffic watches. Audio description is harder and less often required, but material whose key information appears only in the picture does not work without it.

What this looks like in an online shop

Four places where e-commerce falls over:

• A field described only by a hint. <input placeholder="E-mail"> with no label looks clean and vanishes the moment the user types. Correctly: <label for="email">E-mail</label> beside the field.
• A button with no content. A bin icon in a <button> with no text and no aria-label is "button" to a screen reader. Nobody knows whether it removes the product or opens the basket.
• Focus with no outline. outline: none with no replacement of your own leaves a keyboard user with no idea where they are.
• An error message in colour only. A red border is not a message. A sentence saying exactly what is wrong has to appear beside it.

The fifth is contrast, which leads the table above at 83.9% — most often grey helper text, sale prices and labels under fields.

How much a free tool will catch

This is the part that audit sales pitches stay quiet about.

We ran Lighthouse 13.4.1 — built into Chrome, based on the axe-core engine — over our own site. One page scored 100 out of 100, the blog 96.

The score is pleasant but does not mean what it appears to. Lighthouse's accessibility category counts 76 audits. On our site 24 passed, 42 were marked "not applicable", and 10 as `manual` — meaning Lighthouse does not test them and leaves them to a person.

Among them, on our own site:

• whether interactive elements can be reached with a keyboard
• whether the tab order is logical
• whether the visual order matches the code order
• whether focus falls into a trap
• whether focus moves to content that has just appeared
• whether custom controls have labels and roles
• whether off-screen content is hidden from assistive technologies

One hundred out of one hundred in Lighthouse does not mean "WCAG compliant". It means the automatable part passed. A machine is excellent at counting contrast and missing alt attributes. It will not tell you whether the product can be bought without a mouse.

Four traps that will have you fixing working things

In that same audit of ourselves, three of our four manual findings turned out to be false alarms once checked against the documentation. We list them because anyone auditing under their own steam hits the same ones:

• `<label for>` works on `<button>`. A button is a labelable element, so a component with role="checkbox" can be described correctly without an aria-label.
• An element with `aria-hidden="true"` and `tabindex="-1"` is hidden on purpose. A hidden input under a UI-library component is not an unlabelled field.
• `placeholder` counts as an accessible name. A tool accepts it and reports no error — and it is still bad practice, because the name disappears after the first character.
• Criterion 2.4.1 is satisfied by landmarks or by headings. A "skip to content" link is recommended for keyboard users but not required if the page has a correct structure.

Implementation step by step

Step 1 — audit. Machine plus human, in that order. Free: Lighthouse in Chrome, the axe DevTools extension, WAVE. Then the keyboard test — the Tab key alone through the whole purchase process — and a screen reader: NVDA on Windows, VoiceOver on macOS, TalkBack on Android.

Commercial audit prices in Poland start at about PLN 500 for a quick review and reach PLN 15,000 for a full UX audit with user testing; a typical technical audit of a single site costs PLN 1,200–4,000. The spread comes from what is being priced: a short expert review and a full UX audit with users are an order of magnitude apart, and both get called "an accessibility audit". Ask which one a quote covers.

The keyboard test sounds trivial and is the most revealing part of the audit. Put the mouse aside and Tab from the home page to order confirmation. Note three things: where you cannot see what the focus is on; where Tab jumps somewhere unexpected; where you got stuck. Fifteen minutes of that usually yields more than an entire machine report.

Step 2 — repair. The order follows from the WebAIM table: contrast, alternative text, field labels, link and button names, language declaration. Changes in HTML, ARIA attributes and styles — in most cases days of work, not months.

Step 3 — documentation. Public bodies have to publish an accessibility statement with the assessment result and a feedback mechanism. Private firms covered by the EAA have to make public an explanation of how the service meets the accessibility requirements. Neither is a box to tick — it is the document an inspector starts from.

Step 4 — maintenance. Accessibility decays with every content change, and this is the part most often skipped. An editor inserting a photo with no description undoes the developer's work. Somebody adding a banner with the text burnt into the graphic makes that text cease to exist for a screen reader. A new component goes into the shop without labels, because nobody asked for them in the ticket.

Three things stop this: a short training session for the editorial team on alternative text and heading structure, an "accessibility" line on the pre-deployment checklist, and one automated check in the build so obvious errors do not reach production. None is expensive. All are cheaper than a second audit in a year.

What can be done in the first week

If you do not yet have a budget for the whole process, the order is this:

• check the contrast of helper text, prices and labels — statistically the commonest error and the cheapest to fix
• add alternative text to photos that carry information; leave decorative ones with an empty alt
• Tab through the contact form and the basket, and restore a visible focus outline if the styles switched it off
• make sure <html> has a lang attribute

That is four of the six items in the WebAIM table. They do not produce compliance, but they remove most of what tools and users see first.

Two sources are worth knowing: the W3C Web Accessibility Initiative, which publishes techniques and a quick reference for every WCAG criterion, and PFRON, which publishes guidelines to the act that actually applies to you — together with the Widzialni Foundation, which publishes practical guides and reports on the accessibility of Polish websites.

Why bother if the obligation does not reach you

If the table above put you on the "essentially no" side, three reasons remain to do it anyway.

The market. At the end of 2024 there were 3.9 million people in Poland with a disability certificate — 10.5% of the population. Over a decade that number grew by about 8%, mainly in the group over 60. Not a niche: one in ten potential customers.

Convenience for everyone. Limitations can be temporary and situational. A screen in bright sun is a contrast problem. Noise on a train is a need for captions. One free hand is keyboard operation. Solutions designed for people with disabilities win in those situations too.

SEO. Correct heading structure, sensible alternative text, descriptive links and a language declaration are simultaneously WCAG requirements and signals indexing relies on. No magic — accessibility forces semantics, and semantics help a search engine.

What next

If you want to know where you stand and you are planning changes in the coming months — we will run an audit: PLN 2,500 net, the result in five working days, a report with a list of fixes, priorities and an amount against each item, plus an hour of discussion in the price. If you then decide on a new site or a rebuild with us, we deduct that amount from the quote.

If you would rather check for yourself first — two things with no registration: a self-audit checklist and a website speed test that shows Core Web Vitals for your address.

If you are still planning, accessibility is cheapest to build in during design — described in building a website step by step. How it looks in an online shop we cover in UX and UI in e-commerce, and the testing tools in the guide to website testing.