The European Accessibility Act and WCAG 2.2: Is Your Site Ready?

For years, accessibility sat on the "nice to have" list. Since 28 June 2025, when the European Accessibility Act (EAA) began to apply, that has changed. Digital services such as online shops, banking, booking and ticketing systems must now be accessible to users in the EU. For any brand that sells into Europe or serves European customers, this is a direct business requirement.

Who Does It Cover?

The Act looks at who the service is offered to, not where the company is based. An online store selling to consumers in the EU market is in scope even if its headquarters is in Istanbul. Microenterprises (fewer than 10 employees and annual turnover not exceeding €2 million) are largely exempt on the services side, but for any brand planning to grow, that exemption is temporary.

The technical reference point is the EN 301 549 standard, which in practice builds on WCAG for web content. The concrete target is meeting WCAG 2.1 AA, and ideally covering the new criteria introduced in 2.2 as well.

"An accessible interface is not an exception made for disabled users; it is a clearer, faster and more reliable interface for everyone."

What WCAG 2.2 Adds

WCAG 2.2 added new criteria focused on touch screens, cognitive load and keyboard use. These are the ones that are hardest to fix later if they are not considered at the design stage:

• Focus Not Obscured (2.4.11): When navigating by keyboard, the focused element must not be hidden under a sticky header or cookie banner.
• Target Size (2.5.8): Clickable targets should be at least 24×24 CSS pixels, or separated by enough spacing.
• Dragging Movements (2.5.7): Every drag-and-drop action needs a single-pointer alternative.
• Accessible Authentication (3.3.8): Login should not require solving a puzzle or recalling a password from memory; password managers and pasting must work.
• Redundant Entry (3.3.7): Information already entered in the same process should not be asked for again.

A Practical Checklist

When reviewing a site for accessibility, the first things to check are usually the same. Most of them are not extra cost, just good HTML habits:

<!-- 1. Meaningful structure: the right element, not a div -->
<header>, <nav>, <main>, <footer>, <button>

<!-- 2. Skip link -->
<a class="skip" href="#main">Skip to content</a>

<!-- 3. A visible label for every form field -->
<label for="email">Email</label>
<input id="email" type="email" autocomplete="email">

<!-- 4. A visible focus ring -->
:focus-visible { outline: 2px solid currentColor; outline-offset: 3px; }

<!-- 5. Respect motion sensitivity -->
@media (prefers-reduced-motion: reduce) { * { animation: none; } }

Beyond these, text contrast (at least 4.5:1 for normal text), meaningful alt text and error messages that do not rely on colour alone are baseline requirements. Automated tools (Lighthouse, axe) catch only part of the problems; manual testing with a screen reader and keyboard alone is always necessary.

What We Do at Webify

The basics we use on this very site are a skip link, a clear :focus-visible style on every interactive element, and animations that switch off under prefers-reduced-motion. On new projects we treat accessibility as part of the design system from day one, not a post-launch fix, because accessibility added later is always more expensive.