{"id":1258,"date":"2026-09-15T16:08:57","date_gmt":"2026-09-15T16:08:57","guid":{"rendered":"https:\/\/netloria.com\/blog\/website-accessibility-european-accessibility-act-en\/"},"modified":"2026-09-15T16:26:20","modified_gmt":"2026-09-15T16:26:20","slug":"website-accessibility-european-accessibility-act-en","status":"publish","type":"post","link":"https:\/\/netloria.com\/en\/blog-en\/website-accessibility-european-accessibility-act-en\/","title":{"rendered":"Website Accessibility: EAA Requirements and How to Check"},"content":{"rendered":"

Website Accessibility: What the European Accessibility Act Requires and How to Check Your Site<\/h1>\n

\"\"<\/p>\n

\u26a1 Quick answer:<\/strong> Since 28 June 2025 the European Accessibility Act has applied across the EU, and it covers online stores selling to consumers in the Union regardless of where the company is registered. Microenterprises providing services (fewer than 10 staff and no more than \u20ac2 million turnover) are exempt. Meanwhile 95.9% of the top million home pages have detectable accessibility failures<\/a>, and 96% of those errors fall into just six types. Most of them are fixed at the design and front-end level in a matter of days.<\/p>\n

We touched on accessibility in our overview of design trends<\/a>, where it was one direction among several. This article is practical: who the law applies to, what breaks on most sites, and how to check your own without hiring an audit firm.<\/p>\n

Who the European Accessibility Act Applies To<\/h2>\n

Directive (EU) 2019\/882 doesn’t cover every website \u2014 it covers specific products and services. For a web studio and its clients, the key category is e-commerce services.<\/p>\n

The text of the directive<\/a> defines them as services provided at a distance, through websites and mobile apps, at the individual request of a consumer with a view to concluding a consumer contract. Put simply: if someone can place an order on your site, that’s e-commerce under the law. A brochure site with no online ordering usually falls outside that definition, although the directive separately covers banking, transport, e-books and audiovisual media services.<\/p>\n\n\n\n\n\n\n\n\n
Situation<\/th>\nDo EAA requirements apply?<\/th>\n<\/tr>\n
Store sells to consumers in EU countries, company has 15 employees<\/td>\nYes<\/td>\n<\/tr>\n
Same store, but 6 employees and turnover under \u20ac2 million<\/td>\nNo \u2014 microenterprise exemption for services<\/td>\n<\/tr>\n
Store with no sales or delivery to the EU<\/td>\nNo, though national rules may differ<\/td>\n<\/tr>\n
Corporate site with no online ordering<\/td>\nMostly no<\/td>\n<\/tr>\n
B2B platform where only businesses buy<\/td>\nThe directive targets consumer contracts, so usually no<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

A few details that are often reported inaccurately.<\/p>\n

The microenterprise exemption covers services only.<\/strong> Article 4(5) exempts microenterprises specifically from the service requirements. The test is fewer than 10 employees and annual turnover or balance sheet no higher than \u20ac2 million. Once a company grows past that threshold, the requirements start to apply.<\/p>\n

There is no single EU-wide fine.<\/strong> Article 30 leaves penalties to member states: they must be “effective, proportionate and dissuasive”, but each country sets the amounts. So any figure like “fines of up to X euros” without a country attached is incomplete.<\/p>\n

There is a transition period, but not for your website.<\/strong> Until 28 June 2030, products already used to provide a service before 28 June 2025 can stay in place \u2014 that refers to equipment such as terminals, not to new pages on an online store.<\/p>\n

There’s also a “disproportionate burden” provision (Article 14): requirements don’t apply where they would fundamentally alter the nature of the service or place a disproportionate load on the business. But that has to be assessed and documented, not simply asserted. This article isn’t legal advice: if you sell into the EU, check the implementing rules of the country where most of your customers are.<\/p>\n

Beyond the EU<\/h2>\n

The same standard sits underneath rules well outside the Union. EN 301 549, the European technical standard behind the EAA, has been adopted in Ukraine as \u0414\u0421\u0422\u0423 EN 301 549:2022 \u2014 according to the Digital Inclusion Monitoring Centre<\/a>, it has been mandatory for central government websites since July 2023. In December 2025 the government submitted a draft law that would extend accessibility duties to private companies providing electronic services. We mention it because we’re a studio based in Ukraine and watch it closely, but the broader point holds for most markets: accessibility requirements are spreading from the public sector into commerce, not the other way round.<\/p>\n

For the wider legal checklist for a website \u2014 privacy policy, cookies, form consent \u2014 see our separate piece on website legal requirements<\/a>.<\/p>\n

Six Failures Behind 96% of Problems<\/h2>\n

The WebAIM Million 2026 report scanned a million home pages. The picture repeats year after year \u2014 the same failures \u2014 and it’s getting worse: errors per page rose from 51 to 56.1.<\/p>\n\n\n\n\n\n\n\n\n\n
Failure<\/th>\nShare of home pages<\/th>\nWhose responsibility<\/th>\n<\/tr>\n
Low contrast text<\/td>\n83.9%<\/td>\nDesign<\/td>\n<\/tr>\n
Images missing alternative text<\/td>\n53.1%<\/td>\nContent and front-end<\/td>\n<\/tr>\n
Form inputs missing labels<\/td>\n51%<\/td>\nDesign and front-end<\/td>\n<\/tr>\n
Empty links<\/td>\n46.3%<\/td>\nFront-end<\/td>\n<\/tr>\n
Empty buttons<\/td>\n30.6%<\/td>\nDesign and front-end<\/td>\n<\/tr>\n
Missing document language<\/td>\n13.5%<\/td>\nFront-end<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Look at the third column. The top failure and half the rest are baked in at the mockup stage, before a developer opens an editor. That’s why at Netloria we check accessibility during design rather than after launch: fixing contrast in Figma takes a minute, while on a live site with a hundred templates it’s a project of its own.<\/p>\n

Low contrast<\/h3>\n

On average each home page has 34 separate instances of low-contrast text, up 15% in a year. WCAG 1.4.3<\/a> requires a ratio of at least 4.5:1 for normal text and 3:1 for large text. Large means at least 18 points, roughly 24 pixels, or 14 points bold \u2014 about 18.5 pixels.<\/p>\n

The usual offenders: light grey text on white chosen “for a lighter feel”; white text over a photo with no overlay; placeholder text in form fields; tiny captions under prices. Sound familiar? On an expensive monitor the mockup looks clean, and on a phone in sunlight the text simply disappears \u2014 which hurts not only people with low vision, but anyone who steps outside with their phone.<\/p>\n

Images without alt text<\/h3>\n

A screen reader reaches an image with no description and reads out the file name \u2014 something like “IMG underscore 4471 dot jpg”. For a product photo, that means a blind shopper never learns what the item looks like. The rule is simple: a meaningful image gets a short description of what it shows; a decorative one gets an empty alt attribute so the reader skips it.<\/p>\n

Form fields without labels<\/h3>\n

The most common design habit that breaks accessibility is using a placeholder instead of a label. Grey “Your phone” inside the field looks minimal, but it vanishes the moment someone starts typing, and it usually lacks sufficient contrast. A screen reader often doesn’t announce what the field is at all.<\/p>\n

Empty links and buttons<\/h3>\n

The cart icon, the close cross, the slider arrow, the social logo in the footer \u2014 all buttons and links with no text. Visually obvious; to a screen reader, just “button”. The user hears “button, button, link, button” and can’t tell which one opens the cart.<\/p>\n

It’s Not Only About People With Disabilities<\/h2>\n

The objection we hear most often from business owners is “we hardly have customers like that.” The problem is that accessibility affects a far wider group than it seems, and most of them would never describe themselves as disabled. A shopper over 60 who can no longer read small grey type. Someone with a broken arm using only a keyboard for a week. A person with dilated pupils after an eye exam. A driver dictating a search by voice. Anyone outdoors on a sunny day. When we at Netloria fix contrast and form labels on a project, we almost never pitch it to the client as “accessibility for disabled users” \u2014 we pitch it as usability for everyone, because in practice that’s exactly how it works out.<\/p>\n

There’s a second argument. Alt text, a proper heading hierarchy, a declared page language and descriptive link text are the same signals search engines and AI assistants use to understand a page. Google doesn’t promise a ranking bonus “for accessibility”, so don’t sell it as an SEO trick. But cleaner structure has never hurt anyone.<\/p>\n

An Accessibility Widget Won’t Fix It<\/h2>\n

A popular market offer is an overlay script that “automatically makes your site WCAG compliant” \u2014 a small panel in the corner with “larger text” and “high contrast” buttons.<\/p>\n

A telling case: on 22 April 2025 the US Federal Trade Commission approved a final order requiring accessiBe to pay $1 million<\/a>. The company had claimed its plug-in could make any website WCAG compliant. The FTC found those claims false, misleading or unsubstantiated and barred the company from repeating them without evidence.<\/p>\n

The logic is straightforward. A script doesn’t know what a product photo shows, doesn’t understand what each form field is for, and can’t rebuild navigation that doesn’t work with a keyboard. It can repaint a page, but it can’t repair structure built into the design and code.<\/p>\n

How to Check Your Site in an Hour<\/h2>\n

A full conformance audit is specialist work. The main problems, though, are visible without one.<\/p>\n

    \n
  1. Automated scan.<\/strong> Lighthouse, built into Chrome (Accessibility tab), or WebAIM’s free WAVE extension. Remember that automation only catches the subset of issues a machine can detect.<\/li>\n
  2. Keyboard test.<\/strong> Put the mouse aside and go from the home page to checkout using only Tab, Enter and Space. Can you see where focus is? Can you open the menu, choose a size, close a pop-up?<\/li>\n
  3. Zoom to 200%.<\/strong> Scale the page in your browser. Text shouldn’t overlap or get cut off.<\/li>\n
  4. Screen reader.<\/strong> VoiceOver is built into every Mac and iPhone; NVDA for Windows is free. Five minutes listening to your own checkout form usually persuades people more than any report.<\/li>\n
  5. A form error.<\/strong> Submit the form with an invalid phone number. Does the site explain in text what’s wrong, or just outline the field in red?<\/li>\n<\/ol>\n

    That last one is underrated. A red border with no text is a message invisible to people with colour vision deficiency \u2014 and they make up a noticeable share of men.<\/p>\n

    New Site vs Existing Site<\/h2>\n\n\n\n\n\n\n\n
    <\/th>\nNew site<\/th>\nExisting site<\/th>\n<\/tr>\n
    When to build it in<\/td>\nIn the design system: colours, type sizes, button states<\/td>\nAfter an audit, starting with the most-used templates<\/td>\n<\/tr>\n
    Biggest impact<\/td>\nA palette with verified contrast and labels built into form components<\/td>\nContrast, alt text, forms and icon buttons \u2014 the same six failures<\/td>\n<\/tr>\n
    Effort<\/td>\nAdds almost no time if done from the first mockup<\/td>\nDepends on the number of templates and plugins<\/td>\n<\/tr>\n
    Typical trap<\/td>\nMockup approved “by eye”, contrast never checked<\/td>\nHome page fixed, cart and checkout left untouched<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    For an existing store, the priority isn’t the home page but the path to purchase: product page, cart, checkout. That’s where friction costs money, and that’s where custom icon buttons and placeholder-only forms tend to live.<\/p>\n

    Mistakes We See Most Often<\/h2>\n