Web & compliance
If you are searching for web accessibility, EAA website requirements, or "accessibility law Denmark", you are usually in one of three rooms: you run a webshop and heard the rules applied from summer 2025. A vendor emailed you an overlay. Or a customer asked whether your site works with a keyboard and a screen reader — and you cannot answer honestly.
We meet teams that overreact ("we must WCAG-certify the entire internet") or underreact ("that is only for the public sector"). Both are wrong. The European Accessibility Act hits specific products and services sold to consumers. It does not automatically hit your internal portal or your B2B brochure. It also does not hit "a small script in the corner". It hits how a person actually buys, pays, and finds help.
TL;DR
The main points
- The EAA is a duty on certain consumer-facing services — not a stamp on every website in Denmark.
- A webshop, a checkout, and payment/login are what the law typically points at. A pure B2B brochure is a different question.
- WCAG is the method. An overlay widget is not a shortcut — it is often what makes you stop asking.
- Keyboard, contrast, labels, focus, and honest error text beat a long PDF with an AA badge.
- Microenterprises as the law defines them are typically exempt for services. That is a legal call — not something an agency should guess.
- Start with the flows a person cannot complete. Not with repainting every icon.
Why this matters in the first place
For years accessibility was treated as niceness: something the public sector had to do, and something private teams "did if there was time". The EAA changes that frame for a concrete kind of private service — especially e-commerce, certain financial and transport-adjacent services, e-books, and electronic communications. In Denmark it is implemented as the act on accessibility requirements for products and services. Application started in June 2025. That is not a rumour. It is a date many shops have already passed.
That does not mean every marketing site is suddenly unlawful. It means you must be able to answer two questions before you buy a tool or promise a customer anything: is our service even in scope — and if yes, can a person using a keyboard, a screen reader, or low vision complete what you sell?
The second question is the one most teams skip. They buy an overlay, drop a badge in the footer, and call it compliance. The overlay does not change that your checkout button cannot be reached without a mouse, that form errors are only red borders, or that a video ad is the only explanation of shipping. The law asks whether the service can be used. It does not ask whether you bought a layer on top.
This is not legal advice. It is the engineering conversation you need before a lawyer can say anything useful. Without knowing your flows, "we are EAA-ready" is a sentence you cannot defend — not to the Danish Safety Technology Authority, and not to the customer who cannot pay.
What the EAA actually covers — and what it does not
The EAA is about products and services in named categories when they are aimed at consumers. E-commerce is the one we get asked about most: a site or app where a consumer can enter a contract — browse, cart, checkout, payment, account, delivery, returns. That is not only "the shop". It is also the steps you outsourced: payment, identity, the shipping picker. If those steps are part of the service, they are part of the problem.
Other categories typically include banking and certain financial self-service, electronic communications, e-books, certain transport and ticketing services, and a set of physical products with a digital surface. If you sell clothes online to consumers and you are not a microenterprise as the law defines one, you are in this conversation. If you run an internal time-tracking portal for your own staff, you are probably in a different one.
B2B is where people trip. A pure business service that is not sold to consumers is not what the EAA was written for. A shop that sells to both consumers and businesses, or a checkout that is the same for both, is a different picture. "We are B2B" is not a stamp you can put on a site where private individuals can still place an order. Scope is a legal call from what you actually offer — not from how you brand yourselves.
Microenterprises — the law uses headcount and a turnover or balance threshold — are typically exempt from the service requirements. Product rules can look different. We repeat this because vendors love to say "everyone must comply with the EAA". That is wrong. It is also wrong to assume you are exempt because you feel small. Count what the law counts. Ask a lawyer if you are unsure. An agency should not guess you into or out of scope.
WCAG is a method — not a certificate for the reception wall
When people say "we need to be AA", they usually mean Web Content Accessibility Guidelines at level AA. The harmonised standard that describes how digital interfaces should be perceivable, operable, understandable and robust is built on that thinking. POUR. It is a useful language. It is not a diploma you get after running an automated scanner.
A scanner is a fine first pass. It finds missing alt text, thin contrast, empty links, and inputs without a label. It does not find that your date picker traps focus, that "next step" is a div with a click handler, or that the error is only a red border. It also does not find that your copy is unparseable — including for people without a disability. Automation is a net. It is not the fishing.
The Danish public sector has lived under the Web Accessibility Directive for years. That is a different kind of duty, with statements and supervision that are not the same as the EAA. Copying a public-sector statement into the footer of a private webshop is not compliance. Borrowing their checklist — keyboard, contrast, captions, labels — is an honest place to start, whether or not you are in scope.
We treat WCAG as acceptance criteria on the flows that matter: home to product, cart, checkout, account, search, contact. A site can score neatly in a scanner and still be unusable at checkout. Conversely: a site with honest labels, visible focus, a sane heading order, and keyboardable dialogs is already far along — before anyone has said "AA".
Overlay and badge vs. what a person can actually complete
What teams typically buy
What looks like compliance on a slide.
- An overlay that promises AA without touching your components
- A footer statement copied from a public-sector site
- A scanner report with green numbers and no checkout test
- A feeling that the topic has been "taken off the table"
What actually decides the case
What a user and a supervisor can verify.
- Keyboard all the way through buy, login, and payment
- Labels, errors, and status that also exist as text
- Contrast and zoom that do not destroy the layout
- A real screen-reader test on the two or three flows you live on
How to assess your site before you promise anything
An afternoon. Without this order you buy the wrong thing — either an overlay or a pile of cosmetics.
- 01
Decide whether you are in scope — honestly
Do you sell to consumers in a category the law names? Are checkout, account, or payment part of the service? Are you a microenterprise as the law defines one? Write the answer down. If you are unsure, the next step is a lawyer — not a plugin.
- 02
List the flows a person must be able to complete
Find a product, add to cart, pay, create an account, reset a password, contact support, read the terms. That is your real backlog. A homepage with nice contrast and a broken checkout is not an accessible site.
- 03
Complete them with the keyboard alone
Tab, Enter, Escape. Can you see focus? Can you close modals? Do you get trapped in a date picker? If you lose the thread, a screen-reader user already lost it. This finds more than most scanners.
- 04
Run a scanner — and treat it as a net
Fix the obvious: missing labels, empty alt, contrast below what WCAG calls AA, links that say "read more" seven times. Stop when you start chasing false positives instead of testing checkout again.
- 05
Test with a screen reader on one flow
VoiceOver or NVDA on buy or login. You do not need to become experts. You need to hear whether buttons have names, whether errors are announced, and whether the order makes sense. What you cannot explain, you cannot claim is accessible.
“The EAA asks whether a person can use the service. It does not ask whether you bought a layer that promises they can.”
What we typically fix first — and what we deliberately leave waiting
First: keyboard and focus. Buttons that are divs, menus that only open on hover, dialogs without a focus trap and without Escape, missing skip links. Without that, the rest is cosmetics. On a Next.js site it often lives in your own components — not in the CMS. On WordPress it often lives in the theme and in the page builders that emit a <div> where there should have been a button.
Then: forms. A label that is visible and associated, errors that are text and tied to the field, honest autocomplete, and a checkout where each step has a heading. Payment and identity you embedded must be usable with a keyboard and must have a name. "It is the vendor's iframe" is an honest problem. It is not an exemption. You must be able to change vendor or demand an accessible embed.
Then: content and media. Alt text on meaningful images, empty alt on decoration, captions on the video that explains the product, and a heading order that mirrors the page — not a jump from h1 to h4 because the design looked nicer. That is also SEO. A page a screen reader can parse is a page a crawler can parse. Core Web Vitals and accessibility are not the same, but layout shift that steals the click on "buy" is both.
What we leave waiting: repainting every icon, writing statements before flows work, and "making the whole archive AA" while checkout is still a mouse trap. Prioritise what a person must be able to do today. The archive and the old campaign landing can wait until the purchase works. An agency that starts with an eighty-page report and no change in the cart has sold you theatre.
What you should typically do in the situation you are in
The left is what you typically say. The right is the next step we typically recommend.
Situation
You do not know whether the EAA even hits you
Next step
Write down what you sell, to whom, and whether checkout is part of the service — then a lawyer
Situation
You bought an overlay and call yourselves done
Next step
Turn it off and tab through checkout. What you cannot do is what you must fix
Situation
The scanner is green, but you have never tried without a mouse
Next step
Keyboard-test the two or three money flows. Scanner scores are not acceptance criteria
Situation
You are a pure B2B brochure with no consumer purchase
Next step
You are probably outside the EAA — still fix keyboard and labels, because that is good craft
Situation
Payment or login lives in an iframe you cannot style
Next step
Demand an accessible embed, or change vendor. It is your service
Checklist before you say "we are EAA-ready"
If you are missing several of these, the promise is early — whatever badge you have in the footer.
- You can explain whether your service is in scope, and you did not guess the exemption
- Buy, login, and contact can be completed with a keyboard, with visible focus
- Every field has a label, and errors are text — not only colour
- Meaningful images have alt, videos you sell with have captions
- You have tested one real flow with a screen reader — not only a scanner
- Payment, identity, and other embeds are in the test, not excused
Questions we get again and again
Does the EAA apply to every Danish website?
No. It applies to specific products and services, typically when they are sold to consumers — e-commerce is the most common example. An internal portal or a pure B2B brochure is a different question. Microenterprises as the law defines them are typically exempt for services. If you are unsure, that is a legal call from what you actually offer, not from whether you have a website.
Is it enough to install an accessibility plugin on WordPress?
Almost never, if the plugin is an overlay. It does not touch your theme, your page builder, or your checkout. A plugin can help with a few things — better captions, better media. It cannot turn a mouse trap into a keyboardable service. Fix the components. On WordPress that means the theme and the blocks you actually use. On Next.js that means your own primitives.
What about B2B webshops and customer portals?
A portal for existing business customers is rarely what the EAA was written for. A shop that also sells to consumers, or a checkout that is the same for both, can be. Separate the two. Even outside the EAA, a portal that cannot be used with a keyboard is a poor product — especially if your customers have buyers who are not on a mouse all day. The law is the floor, not the ceiling.
Do we need an accessibility statement?
Public-sector sites have had to declare for years. For private EAA services the point is that the service meets the requirements, and that you can explain how — including accessibility information about a product that you must pass on if the manufacturer provided it. A statement without a working checkout is a document. Get the flows working, then write honestly what is still broken and when you will fix it.
Where do we start if the budget is tight?
Keyboard through buy and contact. Labels and errors as text. Contrast on text and buttons. That is craft, not a programme. A scanner afternoon plus an honest checkout test beats a large report you do not act on. If you are building new, make button, field, and dialog right in the design system the first time — it is cheaper than retrofitting accessibility onto a theme that was never designed for it.
If you need to answer whether the site can be used
Let us test the flows you live on — with a keyboard.
A short review of checkout, login, and contact is often enough to separate a real EAA problem from an overlay you do not need.
