The European Accessibility Act one year in: what non-EU companies still get wrong

A US e-commerce company closes a deal with a German retailer in March 2026. Two weeks later, the retailer's procurement team forwards them an accessibility conformance questionnaire from their own legal department. The questions are specific — Success Criterion by Success Criterion, WCAG 2.1 AA, evidence required. The US company does not have answers. The deal pauses.

That is the EAA in practice, nearly ten months after the enforcement date. Nobody is getting sued on day one. Nobody is being marched into an EU courtroom over a missing alt attribute. What is happening is quieter and more expensive: deals are slowing, procurement gates are hardening, and companies that treated the European Accessibility Act as an EU-only problem are finding out that it follows their customers.

This post is for teams headquartered outside the EU — specifically in the US and Canada — that sell digital products or services into European markets. If that is you, and your accessibility story is "we will deal with it when we have to," you are already past due.

What the EAA actually requires

The European Accessibility Act is a 2019 EU directive that took effect for private sector products and services on June 28, 2025. Each of the 27 EU member states has transposed it into national law, which means the specifics — penalty amounts, enforcement bodies, reporting requirements — vary by country. But the core requirement is consistent.

If you sell a covered product or service to consumers in the EU, it must conform to specified accessibility requirements, and you must be able to prove it. The covered categories include e-commerce, consumer banking, e-books and e-reader software, transport ticketing and information services, audiovisual media services, and telephony.

The technical baseline is harmonized standard EN 301 549, which in turn incorporates WCAG 2.1 Level AA. WCAG 2.2 is not yet the legal baseline in EN 301 549, but the updated standard is in progress and is expected to raise the bar within the next two years. If you are starting compliance work today, target WCAG 2.2 AA. It is a superset of 2.1 AA, and you will be ahead of the next revision.

There are exemptions. The "microenterprise" carve-out — fewer than 10 employees and less than €2 million in annual turnover or balance sheet — applies to services, not products. And disproportionate burden arguments exist, but they require documentation, not hand-waving. If you have raised a seed round, hired a sales team, and have customers in Germany, you are not a microenterprise.

Why "we are not an EU company" is not the answer

The most common mistake we see from US and Canadian teams is assuming the EAA does not apply to them because they have no EU entity. The directive applies to anyone placing a covered product or service on the EU market. Placing a service on the market means making it available to consumers in the EU. If your SaaS product has a pricing page in euros, or a checkout flow that accepts EU cards, or a terms of service that applies to EU consumers, you are placing a service on the EU market.

Member states differ on exactly how they enforce against foreign providers. Some will go through the customer — the EU-based business using your product — and push compliance obligations upstream contractually. Some will pursue the provider directly through the market surveillance authority. The practical result is the same: your enterprise customers will start asking for proof, and your contracts will increasingly require it.

This is already happening. Procurement teams at European retailers, banks, and public-sector-adjacent organizations are updating their vendor questionnaires to include WCAG conformance evidence and accessibility statements. Some are requiring VPAT-style documentation as a condition of purchase. If you cannot produce that documentation, you are disqualified before the commercial conversation starts.

The accessibility statement nobody writes

Every covered service under the EAA needs an accessibility statement. This is a public document — typically linked from the footer — that describes the conformance status of your product, lists known non-conformances, explains the disproportionate burden arguments (if any), and provides a feedback mechanism for users who encounter issues.

Most US and Canadian companies we talk to either do not have one or have a boilerplate statement from a template site that does not match their actual product. Regulators and enterprise procurement teams both read these. A thin, obviously generated statement is worse than no statement — it tells a compliance officer you treated the requirement as a checkbox.

A real accessibility statement names the standard (EN 301 549 / WCAG 2.1 AA or 2.2 AA), states the conformance level honestly (fully conformant, partially conformant, or non-conformant), lists the specific non-conformant content, gives the date of the last evaluation, and provides a contact for feedback. If you have partial conformance, that is fine — it is expected. What regulators do not accept is silence or vague claims.

What most teams actually fail on

The WCAG violations that show up most often in EAA-relevant audits are not exotic. They are the same violations that have been in the top-10 lists for a decade:

Images without alt text. Not just decorative images — product photos on e-commerce sites, icons that act as buttons, images used in place of text headings.

Form inputs without associated labels. A visible placeholder is not a label. Putting placeholder="Email" on an input does not associate a label with the input for a screen reader.

Color contrast below 4.5:1. Design systems ship with brand colors that look great on a presentation deck and fail contrast on the actual page. The lightest gray in your muted text scale is usually the culprit.

Keyboard traps in modals and menus. Custom dropdowns, date pickers, and modals that were built without role, focus management, or escape key handling. These fail multiple success criteria at once.

Missing or broken heading hierarchy. Pages that jump from <h1> to <h4>, or that have no <h1> at all because the design team wanted a visual hero with no semantic heading.

Our detection engine uses axe-core v4.11 plus 50+ proprietary rules to catch these, and they are the top of every scan report we run. They are also the fixes that get landed fastest because they are concrete and localized.

The fastest path to "defensible"

You do not need perfect conformance on day one. You need a documented, demonstrable process that shows you are identifying violations, fixing them, and tracking the remaining gaps. Regulators and procurement teams both understand that WCAG conformance is a moving target on a live product. What they do not accept is no process at all.

The practical path for a small engineering team is:

First, run a scan against your production URLs. A web scan will surface the violations a sighted user can trigger. A repo scan will surface the violations that live in your components and shared code. Between the two, you will have a prioritized list of real issues with source-file references.

Second, fix the highest-severity violations first. Missing alt text on product images, form inputs without labels, color contrast failures on primary actions, and keyboard traps in modals are the ones that block real users and show up first in enterprise audits.

Third, wire the scan into your CI pipeline. A GitHub Actions integration that runs on every pull request is the difference between compliance as a one-time project and compliance as a property of your codebase. You want to fail the build when someone ships a new violation, not discover it six months later during a procurement review.

Fourth, publish the accessibility statement. Be honest about what conforms and what does not. Name a contact. Date it. Update it when you ship fixes.

Fifth, generate the compliance report. Teams ask us specifically for AODA, ADA Title II, and EAA-formatted reports because the underlying WCAG data is the same but the formatting and framing a regulator or procurement reviewer expects is different. inklu generates all three today.

What to tell your enterprise customers right now

If you are in the middle of a European sales cycle and the accessibility questionnaire landed on your desk this week, here is the honest answer to give them.

You are actively running WCAG 2.2 AA scans against your product. You have a remediation process — pull requests reviewed and merged on a defined cadence. You have an accessibility statement. You can generate a conformance report for the current state of the product. You are targeting the EN 301 549 standard as it applies to EAA-covered services.

That answer wins deals. "We will get back to you" does not.

Where inklu fits

We built inklu because the gap between "we should be accessible" and "here is a pull request that fixes the violation" was where most teams stalled. Scanning is cheap and widely available. Reading the WCAG spec is free. Writing the actual fix, in the actual component, in the right style, with the right ARIA attributes, is the part that takes time and expertise.

inklu scans against WCAG 2.2 using axe-core v4.11 plus our own rule set, then opens GitHub pull requests with AI-generated fixes in HTML, CSS, JSX (TSX), and SCSS. The fixes are delivered as PRs against your branch, never committed to your default branch without your review. We generate AODA, ADA Title II, and EAA-formatted reports on demand. See the pricing page for token costs (web scan = 2 tokens, repo scan = 8 tokens, auto-fix PR = 1 token) and the FAQ for the specifics on languages, frameworks, and data handling.

If you are navigating an EAA procurement question this quarter and want to see what a scan-plus-PR workflow looks like on your actual codebase, book a demo at inklu.io or email hello@inklu.io. We will walk through your highest-severity violations and open a few fixes as PRs so you can see the workflow end to end.

The EAA is not going away, and the procurement questionnaires are not going to get shorter. The teams that treat accessibility as a property of the codebase — not a compliance event — are the ones that close the deals.