Web Accessibility Is Not Optional Anymore

Two things changed recently, and only one of them gets written about accurately.

WCAG 2.2 became a W3C Recommendation on 12 December 2024, adding nine success criteria to the previous version (W3C). And the European Accessibility Act began applying to products and services placed on the EU market after 28 June 2025 (Directive (EU) 2019/882).

The part written about inaccurately is the penalty. You will find a specific euro figure quoted across a great many articles selling accessibility software. It is not in the Directive.

Key Takeaways

• WCAG 2.2 is a W3C Recommendation as of 12 December 2024; it does not supersede 2.0 or 2.1, and level AA is what requirements normally point at (W3C).
• The European Accessibility Act applies to services placed on the EU market after 28 June 2025, including from companies outside the EU (Directive 2019/882).
• The Directive sets no fine. Article 30 leaves penalties to Member States.
• Microenterprises providing services are exempt from the requirements.
• The failures that actually broke our own site were invisible to a casual review — and one of them hid half the page from screen readers while looking perfect.

What WCAG actually is

The Web Content Accessibility Guidelines are a W3C standard, not a law. Laws point at them; that is where their force comes from.

WCAG defines "three levels of conformance … A (lowest), AA, and AAA (highest)" (W3C). In practice almost every contract, tender and regulation you will meet asks for AA. Level A is too weak to be meaningful and AAA includes criteria that are not achievable for all content.

Version 2.2 added nine criteria, including two that catch a great deal of modern interface work: 2.4.11 Focus Not Obscured and 2.5.8 Target Size (Minimum). The second one — a minimum pointer target of 24 by 24 CSS pixels — is the criterion most likely to fail on a site that looks entirely fine.

One point that saves confusion: "The publication of WCAG 2.2 does not deprecate or supersede WCAG 2.0 or WCAG 2.1." If a contract names 2.1 AA, that is still a coherent requirement. The W3C's own advice is to work to 2.2 "to maximize future applicability".

What the European Accessibility Act changed

The Directive covers, among other things, e-commerce — defined as "services provided at a distance, through websites and mobile device-based services by electronic means and at the individual request of a consumer with a view to concluding a consumer contract".

Three things worth being precise about:

It follows the market, not the company. The obligation attaches to services placed on the EU market. A Turkish or American company selling to consumers in the EU is inside the scope; being registered elsewhere does not put you outside it.

There is a transitional period for services. Services already on the market before the date have a five-year transition, but new services placed on the market after 28 June 2025 comply immediately.

Microenterprises providing services are exempt. The Directive says so directly. Note what the exemption removes: a legal obligation. It does not remove the customers who cannot complete your checkout.

About that fine

Article 30 states that "Member States shall lay down the rules on penalties" and that penalties "shall be adequate in relation to the character of the infringements and to the circumstances". No amount, no percentage.

So when an article tells you the EAA carries a fine of a specific size, the number came from somewhere other than the law. The honest answer to "what is the penalty" is: it depends on the member state whose market you are selling into, and you would need to look at that country's transposing legislation.

We would rather tell you that than quote a scary number we cannot source.

The failures that actually break sites

The failures that actually break a site are rarely the ones on the checklists, because a checklist lists criteria and a real site fails in specific ways.

We audited and rebuilt this site's accessibility recently. It now measures 100 on every page we test, in both languages. Getting there turned up four failures, and the instructive thing is that none of them were visible to a person looking at the screen.

An animation that removed half the page from assistive technology. Sections faded in on scroll using a library helper that sets visibility: hidden until the animation fires. Content with visibility: hidden is not in the accessibility tree at all. Because the animation only ran when a section scrolled into view, a screen reader user navigating by headings — which is how many people navigate — saw a page with almost nothing on it. It looked perfect to everyone else. Switching the animation to animate opacity instead of visibility fixed it without changing a single frame of what the page looks like.

Contrast that made prices invisible. Our accent colour is a bright cyan designed for dark panels. Used on a white pricing table it measures 1.8:1. The numbers were, functionally, not there. Nobody noticed because everybody already knew what they said.

Touch targets at 18 pixels. Footer links, breadcrumbs, the language switcher — all comfortably below the 24-pixel minimum that WCAG 2.2 introduced. The fix was padding with a compensating negative margin: the hit area grows, the layout does not move.

A comparison table that announced itself as empty. A grid built with ARIA roles had columnheader elements that were not inside a row. To a screen reader it was a table containing no rows. Visually it was a clean comparison grid.

The pattern across all four: accessibility failures are usually invisible to the person who built the page. That is precisely why they need to be measured rather than reviewed.

What to actually do

Put an automated check in the build. Lighthouse or axe, run on every page, failing the build below a threshold. It will not prove compliance — it cannot judge whether alt text is accurate or whether a flow works by keyboard — but it catches contrast, labels, heading order and invalid ARIA every single time, for free, forever. Ours runs on fifteen pages.

Then do the things a machine cannot check. Navigate a key flow with the keyboard alone. Read your alt text and ask whether it describes the image or just names the file. Turn on a screen reader once and listen to your own homepage; it is uncomfortable and it is the fastest education available.

Fix in this order: contrast, then labels and headings, then keyboard operability, then ARIA. ARIA last on purpose — incorrect ARIA is worse than none, and most of what people add with it was already available from using the right element.

Decide it early. Contrast and target sizes are cheap while a design is still a design and expensive once forty components exist. This belongs in the same conversation as the technical decisions a website rests on, not in a remediation project two years later — which is why we treat it as part of building the site rather than as a service sold afterwards.

In short

The standard is WCAG 2.2 at level AA. The law that changed is the European Accessibility Act, and it follows your customers rather than your registration. The fine everyone quotes is not in the Directive. And the failures that matter are the ones you cannot see — which is an argument for measurement, not for good intentions.

If you want to know where your site actually stands rather than assume, that is a short conversation — and we will tell you if the answer is "you are mostly fine".