Website accessibility means a site that people with disabilities can perceive, operate and understand, and under the European Accessibility Act it is now a legal duty for many businesses that sell to consumers in the EU. In practice the Act points to the harmonised standard EN 301 549, which in turn rests on the W3C’s Web Content Accessibility Guidelines at level AA. This guide explains who is covered and since when, what the standards ask, the failures we find most often and how to fix them, a numbered audit process, the accessibility statement, and how enforcement works across the member states.
Last updated: 27 October 2026.
What is the European Accessibility Act?
The European Accessibility Act is Directive (EU) 2019/882, adopted on 17 April 2019. It sets common accessibility requirements for a list of products and services across the EU single market, so that a business meets one set of rules instead of a different one in each country.
Because it is a directive, each member state had to write it into national law, by 28 June 2022, and apply those rules from 28 June 2025. Since 28 June 2025, the European Accessibility Act has applied to covered products placed on the market and to covered services provided to consumers. What a business actually has to do is set out in each national law, which follows the directive closely but adds its own enforcement bodies and penalties.
The Act sits beside an older text, the Web Accessibility Directive, which covers the websites and apps of public sector bodies. The European Accessibility Act is the one that reaches private companies.
In short: if you sell certain services to consumers in the EU, your website and app must be accessible. The yardstick is EN 301 549, which uses WCAG level AA. Very small service businesses are exempt. Each country enforces its own version of the rules.
At Odduel, a creative and technology agency in Barcelona and São Paulo, accessibility is built into every site from the first wireframe, which is how our website development work is scoped. The rest of this guide is what we tell clients who ask where they stand.
Who must comply with the EAA?
The Act covers named products and named services, not every website. On the service side, the ones that touch most websites and apps are:
- E-commerce services: any service sold to consumers at a distance through a website or a mobile app, which is why most online stores fall within scope.
- Consumer banking services, including the websites and apps through which they are offered.
- E-books and the software used to read them.
- Electronic communications services and the services that give access to audiovisual media.
- Elements of passenger transport services by air, bus, rail and water: websites, apps, electronic tickets and real-time travel information.
The product side covers items such as computers, smartphones, e-readers, payment terminals, cash machines and ticketing machines. If you make or import those, the Act applies to the hardware and its software, not only to a website.
A business outside the EU is not out of reach: what matters is that the service is offered to consumers in the EU. A business that sells only to other businesses, with no consumer-facing service, is generally outside the e-commerce scope, though many sites serve both, and the consumer part is then covered.
The microenterprise exemption
The directive exempts microenterprises that provide services. A microenterprise, in the directive’s definition, employs fewer than ten people and has an annual turnover or balance sheet total under a low ceiling set in the text. A small studio selling services online may therefore be outside the duty.
Two points are often missed. The exemption is for services only: a microenterprise that makes or sells covered products must still meet the product requirements, with lighter paperwork. And being exempt today does not make an inaccessible site a good idea, because a business that grows past the threshold falls within scope, and customers with disabilities are customers either way.
Content and contracts with special treatment
The directive leaves some content outside the requirements: pre-recorded audio and video published before 28 June 2025, office documents published before that date, archived content not edited since, online maps where the essential information is offered in an accessible way, and third-party content the business neither funds nor controls. Service contracts agreed before 28 June 2025 may continue unchanged until they end, for at most five years.
A business may also claim that a requirement would impose a disproportionate burden or fundamentally alter the service. That claim has to be assessed and documented against the criteria in the directive, and the authorities can ask to see it. It is not a general opt-out.
Which standard applies?
The directive describes accessibility in functional terms: content must be perceivable, operable, understandable and robust. To turn that into tests, the EU relies on harmonised standards, and for websites and apps the relevant one is EN 301 549, the European standard for the accessibility of information and communication technology. Meeting a harmonised standard whose reference is published for the Act gives a presumption of conformity.
For web content, EN 301 549 incorporates the success criteria of the W3C’s Web Content Accessibility Guidelines at levels A and AA. The current version of the standard is built on WCAG 2.1. The newer WCAG 2.2, a W3C Recommendation since October 2023, keeps the 2.1 criteria (apart from one obsolete parsing criterion) and adds nine more, six of them at levels A and AA.
Our advice is to build and test against WCAG 2.2 AA. A site that meets it also meets the 2.1 criteria that the standard tests today, and it is ready for the next revision of EN 301 549 rather than needing a second pass.
| WCAG 2.1 AA | WCAG 2.2 AA | |
|---|---|---|
| Status | W3C Recommendation, 2018 | W3C Recommendation, October 2023 |
| Used by EN 301 549 today | Yes | Not yet |
| Focus visible and not hidden | Focus must be visible | Focus must also not be fully hidden by sticky bars or banners |
| Small controls | No minimum size at AA | Targets at least 24 by 24 CSS pixels, or enough spacing |
| Drag actions | Not covered at AA | A single-pointer alternative to dragging |
| Forms | Labels and error help | Also no re-typing of information already given |
| Sign-in | Not covered | No memory or puzzle test without an alternative |
| Help | Not covered | Help options in the same place on every page |
What does WCAG 2.2 AA mean in practice?
WCAG is written as testable success criteria grouped under four principles. Translated into what a visitor experiences, level AA asks for roughly the following:
- Perceivable: images carry text alternatives, videos have captions, text has enough contrast against its background (4.5 to 1 for body text, 3 to 1 for large text and for interface parts), and the page still works when text is enlarged to 200 per cent or the screen is narrow.
- Operable: everything can be done with a keyboard alone, focus is always visible, nothing flashes dangerously, moving content can be paused, and visitors get enough time to act.
- Understandable: the page declares its language, navigation behaves consistently, forms have labels and explain errors, and nothing changes context without warning.
- Robust: the code exposes names, roles and states correctly to assistive technology such as screen readers, and status messages are announced.
None of this demands a plain or dull site. The sites we build carry motion, large type and strong colour; what changes is that motion respects the visitor’s reduced-motion setting, colour never carries meaning alone, and every interaction has a keyboard path. Accessibility works best when it is part of the identity rules: a brand guidelines document that specifies accessible colour pairs saves arguments later.
What are the most common accessibility failures, and how do you fix them?
Most audits find the same faults again and again. They come from design decisions taken without the rules in mind and from components copied from one project to the next. The table lists the ones we see most often and what fixes them.
| Failure | Who it affects | WCAG criterion | Fix |
|---|---|---|---|
| Low contrast text, especially grey on white or white on bright colour | Low vision, older visitors, anyone in sunlight | 1.4.3 Contrast (Minimum) | Set accessible colour pairs in the design tokens and measure every new pair |
| Images without useful alternative text | Screen reader users | 1.1.1 Non-text Content | Describe informative images; give decorative ones an empty alt |
| Form fields without labels, or placeholder text as the only label | Screen reader and voice control users | 1.3.1, 3.3.2, 4.1.2 | A visible label tied to each field; errors in text next to the field |
| Controls that only work with a mouse | Keyboard and switch users | 2.1.1 Keyboard | Use real buttons and links; test every flow with the keyboard alone |
| Focus outline removed or hidden behind a sticky header | Keyboard users | 2.4.7, 2.4.11 | A strong focus style; scroll padding so focus is never covered |
| Headings used for size, not structure | Screen reader users | 1.3.1 Info and Relationships | One H1, headings in order, styles applied by class |
| Links that say only “click here” or “read more” | Screen reader users | 2.4.4 Link Purpose | Link text that names the destination |
| Videos without captions | Deaf and hard-of-hearing visitors | 1.2.2 Captions | Captions for every video with speech; transcripts for audio |
| Cookie banners and pop-ups that trap or skip focus | Keyboard and screen reader users | 2.1.2, 2.4.3 | Move focus into the dialog, keep it there, return it on close |
| Tiny icon buttons close together | Motor impairments, phone users | 2.5.8 Target Size (Minimum) | Targets of 24 by 24 CSS pixels at least, or spacing around them |
| Animation that cannot be stopped | Vestibular disorders, attention difficulties | 2.2.2 Pause, Stop, Hide | A pause control; honour the reduced-motion setting |
Automated tools catch some of these, such as missing alternative text, low contrast and missing labels. They cannot tell whether an alternative text is meaningful, whether the keyboard order makes sense or whether an error message helps. That is why the process below mixes tools with manual testing.
How do you audit and fix website accessibility?
An audit is useful only if it ends in fixes and stays true after the next release. This is the process we follow, whether the site is ours or inherited.
- Set the target and the scope. Agree on WCAG 2.2 AA and list the templates and journeys to test: home, a content page, a product or service page, search, the cart and checkout, sign-in, contact forms, and the cookie banner. On most sites a dozen templates cover nearly every page.
- Run automated checks. Use a recognised rules engine across every template and in each language version. Record the issues by criterion, not by page, because one component fault repeats everywhere.
- Test with the keyboard alone. Complete every key journey without a mouse: reach every control, see the focus at all times, open and close menus and dialogs, submit the forms with errors and without.
- Test with a screen reader and zoom. Listen to the main journeys with at least one screen reader on desktop and one on a phone, then enlarge text to 200 per cent and view at narrow width. Check headings, landmarks, labels and announcements.
- Review content and media. Check alternative texts, link wording, captions, document downloads and plain language in instructions and errors.
- Prioritise by impact. Fix first what blocks a task (a checkout that cannot be completed by keyboard), then what makes it hard, then the rest. Most fixes belong in shared components and design tokens, so one change repairs many pages.
- Fix, then retest. Re-run the same tests on the fixed templates and keep the results with dates, so you can show what was found and when it was corrected.
- Publish the statement and keep it in the release process. Write the accessibility statement (below), then add accessibility checks to every release, beside the rest of your website QA checklist.
Testing with disabled users adds what no checklist can: whether the site is actually pleasant to use. Where a budget allows, a short round of sessions on the main journeys is worth more than another automated scan.
Accessibility also overlaps with maintenance. Plugins and themes that are updated without review can break focus handling or labels, so the same discipline that keeps a site safe, described in our guide to WordPress security, keeps it accessible.
Do you need an accessibility statement?
Under the European Accessibility Act, service providers must make information available on how their service meets the accessibility requirements, in their general terms and conditions or another place that is easy to find, and in an accessible format. Most businesses meet this with an accessibility statement linked from the footer of every page.
A clear statement covers:
- the standard you aim for (WCAG 2.2 AA, through EN 301 549) and how far the site meets it;
- the known gaps, with the reason and a date for the fix where you have one;
- any content outside the requirements and any documented disproportionate burden;
- how and when the site was last assessed;
- a contact through which visitors can report a problem or ask for content in another format, and how quickly you answer;
- where a visitor can complain if the answer does not satisfy them, which depends on your national authority.
Write it plainly and keep it current. A statement that claims full compliance on a site with obvious faults does more harm than an honest one that lists what is still being fixed.
How is the EAA enforced, and what are the penalties?
Each member state appoints its own market surveillance authorities and sets its own penalties, which the directive requires to be effective, proportionate and dissuasive. The bodies, the procedures and the scale of the penalties therefore differ from country to country, and some national laws also let consumer organisations or individuals take action.
For a business selling across several EU countries, the practical answer is to meet the common standard everywhere rather than track each national variation. If you need the exact penalty rules for a market, read that country’s transposition law or ask a lawyer who practises there: the figures are national, and we do not quote them here.
What the authorities can generally ask for is evidence: the standard you followed, your test results, your statement and any disproportionate burden assessment. The audit trail from the process above is that evidence.
Questions people ask
Does the European Accessibility Act apply to my website?
It applies if your website or app delivers a covered service to consumers in the EU, such as e-commerce, consumer banking, e-books, electronic communications or passenger transport information. A purely informational business site may be outside scope, and microenterprises providing services are exempt. Check against the list in the directive and in your country’s transposition law.
Is WCAG 2.2 AA legally required?
The law requires accessibility, and the harmonised standard EN 301 549 gives a presumption of conformity. That standard currently uses WCAG 2.1 AA for web content. WCAG 2.2 AA includes those criteria and adds a few more, so building to WCAG 2.2 AA meets today’s standard and prepares the site for its next revision.
Can an accessibility overlay or plugin make my site compliant?
No. Overlays and toolbars change how a page looks or reads but do not fix the underlying code, labels, keyboard order or content, and some interfere with the screen readers visitors already use. A compliant site needs its templates and components fixed. Plugins can help with checks during editing, but they are not a substitute for the work.
How long does a website accessibility audit take?
It depends on the number of templates and journeys rather than the number of pages, because most faults sit in shared components. A small site with a handful of templates can be audited quickly; a large shop with accounts, search and checkout takes longer. A fixed plan follows a short look at the site and its key journeys.
What happens if my site is not accessible?
You risk action by the national market surveillance authority, which can require corrections and impose penalties under national law, and in some countries complaints from consumers or organisations. Just as important, you lose customers who cannot complete a purchase. Fix the blocking issues first and publish an honest statement while the rest is done.
If you are not sure whether your site meets the European Accessibility Act, start with an audit of the templates and journeys that matter most, then fix the shared components that cause most of the faults. We build accessible sites from the first wireframe and repair inherited ones as part of our website development work. Talk to us about your site and we will tell you plainly where it stands.
Further reading: UX audit checklist: what to check and how to run one in seven steps.
