The accessibility act and online shops that sell into the EU
Who the European Accessibility Act actually binds, what EN 301 549 asks for in practice, and how to check your own shop before anyone else does.
Marko Stančić8 minutes
Directive (EU) 2019/882 · since 28 June 2025Are you in scope
Do you sell to consumers in the European Union?NoB2B only, or selling outside the Union only: out of scope.
Do you have ten or more employees, or a turnover above two million euro?NoA micro-enterprise providing a service is exempt from the requirements.
You are in scope: WCAG 2.1, level AAAndA public accessibility statement in your terms of service.
Where the company is registered changes nothing. The obligation follows the market you sell into.
Field note / Accessibility and regulation
The European Accessibility Act has applied since 28 June 2025 and binds anyone selling to consumers in the European Union, regardless of where the company is registered. If your shop takes orders from the EU, it applies to you, and being registered in Serbia doesn't change that.
This is the article I wanted to read the first time a client asked me whether any of it concerned him. There's almost nothing written about it in Serbian, and what does exist repeats the title of the directive without naming a single concrete criterion. So this goes in the order that's useful in practice: who is in scope, what the standard actually asks for, what's broken on almost every Serbian shop, how to check it yourself, and when it's time to call someone.
One caveat before anything else. This is an engineering text, not legal advice. The directive is transposed into national law in each member state, so supervision, complaints and penalties vary from country to country. Ask a lawyer about your company's legal position. What I'm describing here is what has to behave differently on the site.
Who it actually applies to
Directive (EU) 2019/882 covers a defined set of products and services, and among the services it names e-commerce explicitly: a service provided at a distance, through a website or a mobile application, at the individual request of a consumer and with a view to concluding a consumer contract. Translated into working language, that's an ordinary shop with a cart and a checkout.
The load-bearing word is consumer, and the obligation follows the market rather than the company's address. If you sell to private individuals in the Union and ship to them, you're providing a service on the Union market and you're in scope exactly like a trader in Vienna. If you work strictly B2B, if you sell only in Serbia and countries outside the Union, or if the site is only a catalogue with no cart and no payment, the picture is different and worth clarifying before you change anything.
There's also a microenterprise exemption, and it's the part that gets repeated most inaccurately. The directive treats a microenterprise as a company that employs fewer than ten people and has an annual turnover or an annual balance sheet total not exceeding two million euro. Microenterprises providing services are exempt from the accessibility requirements. Three things usually get missed. The headcount condition and the financial condition apply together; you don't pick one of the two. The exemption is written for services, while the rules for products work differently. And the exemption ends once the company grows past the threshold, which normally happens well before anyone remembers the website.
The directive also allows an exemption for disproportionate burden, but that's not a sentence in an email. It requires a documented assessment that is kept and periodically renewed. If you don't have it in writing, in practice you don't have it.
Working principle
The obligation follows the market you sell into, not the country your company is registered in.
What the standard asks for in practice
The law speaks in principles. The concrete criteria come from the European standard EN 301 549, which for web content points at WCAG 2.1, level AA. That's good news: WCAG treats a site as a list of testable conditions rather than a philosophy, and most of them can be met without a redesign.
Level AA, reduced to what it means on a shop, comes down to this. Anything you can do with a mouse has to be doable with a keyboard. Focus has to be visible and has to move in an order that makes sense. Text has to have sufficient contrast against its background. Content has to survive 200 percent zoom and a 320 pixel width without horizontal scrolling and without losing functionality. Every image carrying information needs a text alternative. Every form field needs a label that is programmatically associated with it, not just placed next to it on screen.
WCAG 2.1 AA / minimum contrastThresholds from the standard, not a measurement
Body text4.5:1
Large text from 24px3:1
Controls3:1
1:13:14.5:1
Alongside the technical part there's an administrative obligation almost everyone skips. The service provider has to explain publicly, in the general terms and conditions, how the service meets the accessibility requirements. That page should be accurate rather than promotional: the date it was last checked, and a list of the gaps you already know about.
Five things wrong on almost every shop
The order is not arbitrary. This is how I usually find them when I open a Serbian shop and walk through it with the keyboard first.
Keyboard traps in the cart and the filters. You tab into the coupon modal, the filter panel or the product gallery and can't get back out. That's a level A criterion, the most basic tier in WCAG, and on its own it can make buying impossible. It's usually created by a plugin that keeps a panel open until something is clicked with a mouse.
Contrast on prices and sale labels. Light green or mint on white looks expensive in the mockup and fails the check. The same goes for grey delivery text and thin white numerals on a pastel badge. The price and the discount are information, not decoration.
The product photo used as the only description. The contents of the bouquet, the dimensions, the material and the delivery window are baked into the image, while the alt attribute is empty or says IMG_2043. Anyone who can't see the image can't see the offer. The same text written into the HTML fixes accessibility and search at once.
Fields labelled only by placeholder. Placeholder text disappears the moment the customer starts typing, doesn't reliably become the field's name for a screen reader, and almost always has weak contrast. At checkout, where every field carries a cost, this is the most expensive item on the list.
Custom dropdowns and modals with no roles and no focus management. A div with an onclick looks like a button but is nothing to assistive technology. When a modal opens, focus has to move into it, stay inside it while it's open, and return to the element that opened it.
The fifth item is why catalogue filtering deserves separate attention. When we built the Cvetam catalogue that customers enter by occasion and price range, the entry point was not a standard WooCommerce listing but a custom control. A control like that has to be a real button, with a name, a state and a place in the focus order, not a coloured rectangle that happens to respond to a click.
The fourth item is the quickest to fix, and the difference in code is small:
HTML
<!-- Wrong: the label exists only as a placeholder -->
<input type="email" name="billing_email" placeholder="Your email">
<!-- Right: the label is programmatically associated -->
<label for="billing_email">Email address</label>
<input id="billing_email" type="email" name="billing_email"
autocomplete="email" placeholder="name@example.com">
A fifteen minute self-check
You need neither an audit nor a budget to find out where you stand. You need fifteen minutes and three passes over the same route: home, category, product page, cart, checkout.
Do the first pass with the keyboard only. Take your hand off the mouse and tab through the whole buying flow. You're watching three things: whether you can see where focus is at every moment, whether it moves in an order that follows what's on screen, and whether you land somewhere you can't get out of. If you can't add a product to the cart and finish an order without a mouse, the problem isn't a detail, it's the whole flow.
The second pass is magnification. Set browser zoom to 200 percent, then narrow the window to phone width. You want text that isn't cut off, content that doesn't overlap, no horizontal scrolling, and a sticky header that doesn't eat half the screen. The button that completes the order still has to be reachable and usable.
The third pass is an automated tool: any free checker in the browser, run against three or four different page types rather than only the homepage. Here it pays to be honest. Automation reliably catches only some of the criteria, mostly the measurable ones such as contrast, missing alt text and unlabelled fields. No tool can judge whether an alt text is accurate, whether the focus order makes sense, or whether an error message is understandable. An empty report doesn't mean the site is compliant; it means you've cleared the failures a machine can see.
A tool doesn't measure accessibility. It only shows you where to start looking.
When it stops being a do-it-yourself job
The first three items on the list are usually theme and CSS work: contrast, alt text, field labels. That can be handled in-house and is worth doing immediately, because the same work also improves search and the number of orders that get completed.
The line is crossed at the fourth and fifth problems. When the keyboard trap sits in a plugin you don't maintain, when someone else extended the checkout, when the theme uses custom controls instead of standard elements, or when you need a compliance statement you can defend, the fix stops being configuration and becomes development. That's the point where it pays to treat WooCommerce development at the code level as planned work with a sequence to it, rather than a series of patches that cancel each other out.
The sequence I recommend is unexciting, which is exactly why it works. First walk the buying flow with the keyboard and remove anything that blocks an order. Then fix contrast and field labels, because they're cheap and they show up across the whole site. Then take the custom controls one at a time and give each a role, a name and focus management. Finally write the accessibility statement with a date and the known gaps, and make a note to review it the next time you touch the checkout.
None of these steps requires a redesign. They require someone to walk the site once without a mouse and write down what doesn't work.
The company paperwork, the store pages and the checkout details a Serbian WooCommerce shop needs in place before card payments are approved and go live.
8 min read
Apply the thinking
Let's make the site work for everyone
If the accessibility obligations are unclear, bring the site as it stands. We can map what has to change, and in what order.
Where the company is registered changes nothing. The obligation follows the market you sell into.
Field note / Accessibility and regulation
The European Accessibility Act has applied since 28 June 2025 and binds anyone selling to consumers in the European Union, regardless of where the company is registered. If your shop takes orders from the EU, it applies to you, and being registered in Serbia doesn't change that.
This is the article I wanted to read the first time a client asked me whether any of it concerned him. There's almost nothing written about it in Serbian, and what does exist repeats the title of the directive without naming a single concrete criterion. So this goes in the order that's useful in practice: who is in scope, what the standard actually asks for, what's broken on almost every Serbian shop, how to check it yourself, and when it's time to call someone.
One caveat before anything else. This is an engineering text, not legal advice. The directive is transposed into national law in each member state, so supervision, complaints and penalties vary from country to country. Ask a lawyer about your company's legal position. What I'm describing here is what has to behave differently on the site.
Who it actually applies to
Directive (EU) 2019/882 covers a defined set of products and services, and among the services it names e-commerce explicitly: a service provided at a distance, through a website or a mobile application, at the individual request of a consumer and with a view to concluding a consumer contract. Translated into working language, that's an ordinary shop with a cart and a checkout.
The load-bearing word is consumer, and the obligation follows the market rather than the company's address. If you sell to private individuals in the Union and ship to them, you're providing a service on the Union market and you're in scope exactly like a trader in Vienna. If you work strictly B2B, if you sell only in Serbia and countries outside the Union, or if the site is only a catalogue with no cart and no payment, the picture is different and worth clarifying before you change anything.
There's also a microenterprise exemption, and it's the part that gets repeated most inaccurately. The directive treats a microenterprise as a company that employs fewer than ten people and has an annual turnover or an annual balance sheet total not exceeding two million euro. Microenterprises providing services are exempt from the accessibility requirements. Three things usually get missed. The headcount condition and the financial condition apply together; you don't pick one of the two. The exemption is written for services, while the rules for products work differently. And the exemption ends once the company grows past the threshold, which normally happens well before anyone remembers the website.
The directive also allows an exemption for disproportionate burden, but that's not a sentence in an email. It requires a documented assessment that is kept and periodically renewed. If you don't have it in writing, in practice you don't have it.
The obligation follows the market you sell into, not the country your company is registered in.
What the standard asks for in practice
The law speaks in principles. The concrete criteria come from the European standard EN 301 549, which for web content points at WCAG 2.1, level AA. That's good news: WCAG treats a site as a list of testable conditions rather than a philosophy, and most of them can be met without a redesign.
Level AA, reduced to what it means on a shop, comes down to this. Anything you can do with a mouse has to be doable with a keyboard. Focus has to be visible and has to move in an order that makes sense. Text has to have sufficient contrast against its background. Content has to survive 200 percent zoom and a 320 pixel width without horizontal scrolling and without losing functionality. Every image carrying information needs a text alternative. Every form field needs a label that is programmatically associated with it, not just placed next to it on screen.
Alongside the technical part there's an administrative obligation almost everyone skips. The service provider has to explain publicly, in the general terms and conditions, how the service meets the accessibility requirements. That page should be accurate rather than promotional: the date it was last checked, and a list of the gaps you already know about.
Five things wrong on almost every shop
The order is not arbitrary. This is how I usually find them when I open a Serbian shop and walk through it with the keyboard first.
The fifth item is why catalogue filtering deserves separate attention. When we built the Cvetam catalogue that customers enter by occasion and price range, the entry point was not a standard WooCommerce listing but a custom control. A control like that has to be a real button, with a name, a state and a place in the focus order, not a coloured rectangle that happens to respond to a click.
The fourth item is the quickest to fix, and the difference in code is small:
A fifteen minute self-check
You need neither an audit nor a budget to find out where you stand. You need fifteen minutes and three passes over the same route: home, category, product page, cart, checkout.
When it stops being a do-it-yourself job
The first three items on the list are usually theme and CSS work: contrast, alt text, field labels. That can be handled in-house and is worth doing immediately, because the same work also improves search and the number of orders that get completed.
The line is crossed at the fourth and fifth problems. When the keyboard trap sits in a plugin you don't maintain, when someone else extended the checkout, when the theme uses custom controls instead of standard elements, or when you need a compliance statement you can defend, the fix stops being configuration and becomes development. That's the point where it pays to treat WooCommerce development at the code level as planned work with a sequence to it, rather than a series of patches that cancel each other out.
The sequence I recommend is unexciting, which is exactly why it works. First walk the buying flow with the keyboard and remove anything that blocks an order. Then fix contrast and field labels, because they're cheap and they show up across the whole site. Then take the custom controls one at a time and give each a role, a name and focus management. Finally write the accessibility statement with a date and the known gaps, and make a note to review it the next time you touch the checkout.
None of these steps requires a redesign. They require someone to walk the site once without a mouse and write down what doesn't work.