European Accessibility Act: what EU clients now ask of web builders

The European Accessibility Act (EAA) has applied since 28 June 2025, and it covers online shops and other consumer services in the EU. If you build those for a client, the client carries the legal duty, and the contract clause that proves it carries your name.

What the Act covers, and who checks it

The Act sets common accessibility requirements for a defined list of products and services. The European Commission lists computers and operating systems, ATMs and ticketing machines, smartphones, television equipment, telephony services, audiovisual media services, passenger transport, banking services, e-books and e-commerce.

E-commerce is the one that reaches most web work. A law-firm summary from Reed Smith states that from 28 June 2025 new consumer-focused products and services offered in the EU must be accessible, and it names e-commerce services among them. If your client sells to consumers in the EU through a website or an app, their service is in scope.

Enforcement is national. Brussels publishes the rules, but supervision happens in each member state. In the Netherlands, the regulator ACM called on businesses to prepare for the rules on webshops and electronic communication services and has supervised them since 28 June 2025. ACM says it will check digital accessibility and approach companies where needed, starting with critical problems that have a significant negative impact and weighing the effort a company has made.

Why your own exemption does not protect the project

There is an exemption for very small businesses, and it is misread all the time. Reed Smith describes microenterprises as organizations with fewer than 10 employees and a turnover or balance sheet total of no more than EUR 2 million, and says they may be exempt. ACM puts the same thresholds the other way round: the service rules apply to businesses at or above them.

A one-person studio is probably under both lines. That is worth almost nothing commercially, because the exemption belongs to the service provider, and on a client's webshop the service provider is the client.

If the client is above the thresholds, they are responsible for a site you built. They cannot hand the obligation to you. They can hand you the work and the warranty, which is why accessibility language now shows up in briefs, acceptance criteria and sometimes in indemnity clauses drafted by someone who has never opened a screen reader.

Read an indemnity clause twice before you sign. Agreeing to build to a named standard is normal. Agreeing to cover a client's regulatory exposure for as long as the site exists, including content you will never touch, is a different promise.

Turn "must be accessible" into a testable sentence

"Must be accessible" cannot be built and cannot be tested. A clause needs a standard, a level and a test surface.

In Europe the usual answer is the harmonised standard EN 301 549, published by ETSI. For web content it points to the Web Content Accessibility Guidelines. The W3C describes WCAG as guidance for making web content accessible, with conformance expressed in levels A, AA and AAA. EN 301 549 currently references WCAG 2.1, and a later version is expected to move to WCAG 2.2, so check which version your client's lawyer has in mind.

The sentence you want in the contract reads something like this: the deliverable conforms to WCAG 2.1 Level AA as referenced by EN 301 549, tested on an agreed list of templates and user journeys, with results delivered as a dated report.

That one sentence gives you a finite target, gives the client something their lawyer can point at, and stops the scope drifting into "make it perfect for everyone, forever". The clause is a template to adapt. Have a lawyer in the client's country read it before it goes into a contract.

How to scope and price it

Retrofitting accessibility is where projects lose money, so treat it as its own line in the quote.

Name it as a line item. Do not bury it in the build price. The client should see it, question it and approve it, priced per template (home, listing, product, cart, checkout, account, forms) rather than per page.

Define the test surface. A sensible set is five user journeys tested with keyboard only, one screen reader and automated checks. Unlimited testing of unlimited pages is not a scope. It is a liability.

Carve out what you do not control: third-party embeds, payment widgets, chat bubbles, review scripts and anything the client adds after handover. You can commit to what you build and to flagging problems in what you do not.

Put the standard in the statement of work, not an email thread. The statement of work guide shows where obligations like this belong.

Charge for the report. A dated conformance report against a named standard is what a regulator asks for, and it is the thing the client cannot produce alone.

Expensive failures are structural: a custom dropdown nobody can operate with a keyboard, a checkout built from unlabelled divs, a colour system picked from a mood board without a contrast check. Catch those in design and they cost hours. Catch them in acceptance testing and they cost a rebuild.

If you are outside the EU, this still lands on you

Many of the designers and developers dealing with this sit in the US, the UK, India or the Gulf. Location does not help. The duty attaches to the service offered to consumers in the EU market, not to the passport of whoever wrote the CSS.

Two consequences follow. Assume any brief from an EU-facing client carries an accessibility expectation even when it is not written down, and price for it instead of finding out at acceptance. And be careful with warranties that outlive your involvement. Promising that you delivered a site conforming to WCAG 2.1 AA on the handover date is reasonable. Promising it stays conformant after a marketing team adds six months of content and three tracking scripts is not.

What regulators do in practice

The picture is uneven, so do not sell fear. Some national authorities spent the first period building capacity. Others, like ACM, published guidance and started checking. The consistent signal is triage: critical barriers first, with credit for demonstrated effort.

That helps your sales conversation. A client with a dated audit, a ranked fix list and a developer working through it stands in a different position from a client with nothing. You can sell the plan even when you cannot deliver perfection.

The offer then has three steps. First, an audit against WCAG 2.1 AA on the templates that carry revenue, as a written report with issues ranked by severity. Second, remediation priced per template. Third, a review each time the site changes materially. That sequence turns a compliance scare into a small retainer.

Handover checklist

Before an EU-facing build counts as finished, confirm the basics that cause most real failures:

• Every interactive element works by keyboard and shows a visible focus state.
• Form fields have real labels, and errors appear as text.
• Images have meaningful alternative text, and decorative images are marked as such.
• Text and interface components meet AA contrast.
• Headings follow a logical order.
• Video has captions.

Then record the date, the standard, the pages tested, the tools used and the open issues in one document, and hand it over with the files. If the client recorded acceptance of that document, you both have an answer when a supervisory letter arrives. The habit of documented client sign-off is what keeps that answer findable a year later.

How Delivvo keeps the accessibility paper trail with the work

Delivvo puts the quote, the contract and the sign-off in one place, so the accessibility scope and the proof of acceptance do not live in separate inboxes.

1. Build the quote from packages and add-ons in Delivvo. Add accessibility as its own add-on line, so the client sees and approves it as a separate item.
2. Send the contract through the same link. Clients sign by typing or drawing their name, and Delivvo records a SHA-256 fingerprint, the IP address, the device and an archived PDF of what they signed.
3. Share the dated conformance report in the client portal as a file. The client approves it there, with a name and a timestamp, using client approvals.
4. Each document carries a verification code, so anyone holding a printed copy can check what was issued and when on the verify page.
5. Keep the contract, the report and the invoice on the same project, so one search finds all three when a client asks a year later.

Because each document has its own number and code, you can answer a later question such as which version was approved and on what date by opening the project, not by searching old email. The report, the contract and the invoice stay linked, so the whole story sits in one folder that you can share with a client or their lawyer.

The contract builder gives you a starting point you edit clause by clause. It is a template, so check the wording with a lawyer. Clients pay you directly through your own gateway and Delivvo takes 0%. You can see how the contract and signing record work on the contracts and e-signatures page.

For the wider picture, see Delivvo for teams and the CRM for service businesses.

FAQ