The European Accessibility Act Is Being Enforced. Your AI-Generated UI Is the Exposure.

What Changed, And Why It Is Different This Time

Previous EU accessibility legislation - the Web Accessibility Directive - applied to public sector bodies. Government sites, universities, public agencies. If you were building a SaaS product, it did not touch you.

The EAA is the opposite. It reaches ordinary private businesses selling to EU consumers, and it applies to companies based outside the EU that serve EU customers. If you take money from someone in Berlin or Dublin through a web app, you are in scope regardless of where you are incorporated.

The timeline has already passed the point where this is theoretical. Enforcement started 28 June 2025. All 27 member states have transposed the directive into national law. The first EAA lawsuits were filed in France in November 2025, with the Netherlands and other member states planning enforcement activity through 2026.

The Standard You Are Being Measured Against

The EAA does not describe pixel-level requirements. It points at a harmonised standard, EN 301 549, and the current version - v3.2.1 - incorporates WCAG 2.1 Level AA in full. Version 4.1.1, expected in 2026, moves to WCAG 2.2.

EN 301 549 also covers ground WCAG does not: hardware, mobile applications, documentation and video players. For a typical web product, though, WCAG 2.1 AA is the operative bar.

Each member state enforces independently, so penalties, timelines and complaint processes differ. The practical planning assumption is that you are exposed to the strictest regime among the countries your customers live in, not the most lenient.

Why AI-Generated Interfaces Fail This Specifically

Generated UI code is usually visually correct and semantically empty. The model produces markup that looks right in a screenshot, which is what it was optimised to do, and skips the attributes that carry no visual weight.

// ❌ BAD - renders perfectly, fails WCAG 2.1 AA in four ways
export function ProductCard({ product, onAdd }) {
  return (
    <div className="card" onClick={() => onAdd(product)}>
      <img src={product.image} />

      <div className="title">{product.name}</div>

      <span style={{ color: '#9aa0a6' }}>{product.price}</span>

      <div className="btn" onClick={() => onAdd(product)}>
        <svg>{/* cart icon */}</svg>
      </div>
    </div>
  );
}

Four failures, none of them visible: the image has no alt, so a screen reader announces nothing. The clickable div is not keyboard reachable - no tab stop, no Enter handler. The icon-only button has no accessible name. And #9aa0a6 on white is roughly 2.6:1 contrast against a 4.5:1 requirement.

Every one passes a visual review. Every one fails EN 301 549.

How To Fix It

// ✅ GOOD - same visual result, keyboard and screen reader accessible
export function ProductCard({ product, onAdd }) {
  return (
    <article className="card">
      <img src={product.image} alt={product.imageAlt ?? ''} />

      <h3 className="title">{product.name}</h3>

      {/* #5f6368 on white is 5.9:1 - clears the 4.5:1 minimum */}
      <span style={{ color: '#5f6368' }}>
        <span className="sr-only">Price: </span>{product.price}
      </span>

      <button type="button" onClick={() => onAdd(product)}
              aria-label={`Add ${product.name} to cart`}>
        <svg aria-hidden="true">{/* cart icon */}</svg>
      </button>
    </article>
  );
}

A real button is focusable, activates on Enter and Space, and announces its purpose - all for free, which is why the rule is "use the element that means what you mean". Decorative images take alt=""; informative ones need real text.

Finding these across a generated codebase is the harder half. Tools like VibeDoctor's Vibe Check (vibedoctor.io) automatically scan your codebase for missing alt attributes and buttons without accessible names, and flag specific file paths and line numbers. Free to sign up.

Two Things That Will Not Save You

Overlay widgets. The one-line script promising instant compliance is explicitly rejected by the EU as a compliance solution, and overlay vendors have been losing in court. Installing one does not move you into compliance and may draw attention.

Automated scanning alone. This is the uncomfortable part for a tooling article: automated tools catch only around a quarter to a third of WCAG issues. They are excellent at the mechanical, countable failures - missing alt, missing labels, contrast ratios - which is genuinely most of what AI-generated code gets wrong, and they will not find broken keyboard navigation or illogical focus order.

Those need manual testing with real assistive technology. The honest sequence is: automate the mechanical failures because there are hundreds of them and they are cheap to fix, then test the flows that matter - signup, checkout, settings - with a keyboard and a screen reader.

A Realistic First Pass

1. Unplug your mouse and complete your primary flow. Signup through checkout, keyboard only. If you get stuck, so does a real user, and no scanner would have told you.
2. Fix every missing alt and unlabelled control. High volume, low effort, and it is what automated tooling finds reliably.
3. Check contrast on greys. AI-generated palettes love #999 and #aaa for secondary text. Both fail.
4. Publish an accessibility statement. Member states expect one and its absence is an easy thing for a regulator to spot. It is a page of text.

FAQ

Sources

• Level Access, European Accessibility Act compliance overview - enforcement date, member state transposition, EN 301 549 and WCAG mapping.
• AEL Data, EAA fines by country - Ireland up to EUR 60,000, Germany up to EUR 100,000 (severe cases beyond EUR 500,000), France up to EUR 375,000, Sweden revenue-based with no fixed cap.
• Accessibility.Works, SaaS EAA compliance and EN 301 549 - scope for private businesses and SaaS-specific requirements.