What does the European Accessibility Act mean for WordPress websites? Learn which businesses may be affected, what accessibility information may need to be published and how to identify common problems with keyboard navigation, forms, content and custom WordPress components.
Last updated
17/09/2026
The European Accessibility Act has applied across the EU since 28 June 2025.European Accessibility Act
For businesses operating websites, however, that does not mean that every company website in Europe suddenly became subject to exactly the same accessibility rules.
The European Accessibility Act, Directive (EU) 2019/882 covers specific products and consumer services. For websites, one of the most important categories is e-commerce services, which the Directive defines around services provided at a distance through websites or mobile services, electronically and at the individual request of a consumer, with a view to concluding a consumer contract. Its scope also includes areas such as consumer banking, certain passenger transport services, electronic communications, e-books and access to audiovisual media services.
That distinction matters.
A WordPress website that allows consumers to buy products or services online may raise different EAA questions from a simple corporate website that only provides information.
And even when a business falls within the scope of the Act, accessibility is not simply a matter of installing a WordPress plugin and considering the job finished.
It involves design, development, content and the way people can actually interact with the website.
Important: This article provides general information about web accessibility and the European Accessibility Act. It is not legal advice. The EAA is implemented through national legislation, and the requirements applying to a particular business can depend on the services it provides, its size and the relevant national rules.
The European Accessibility Act is not a general rule saying that every private website in the EU must meet an identical website checklist.
Its scope is defined around particular products and services.
For services provided to consumers after 28 June 2025, the Directive covers areas including electronic communications, access to audiovisual media services, certain passenger transport services, consumer banking, e-books and e-commerce services.
For many WordPress businesses, ecommerce is therefore particularly relevant.
That can potentially make accessibility relevant well beyond conventional online stores selling physical products.
A business should therefore begin with a scope question:
What service does our website actually provide to consumers?
That question comes before checking colors, alt text or keyboard navigation.
The accessibility requirements themselves are established by the Directive, particularly Annex I. Article 4 requires covered products and services to comply with the applicable requirements set out there. For websites, Annex I includes the principle that they should be made perceivable, operable, understandable and robust.
This is also an important distinction when discussing technical standards.
The law defines the accessibility obligations. A technical standard can provide a route for demonstrating conformity with those obligations.
It should not simply be described as the law itself.
Whether a particular WordPress website is affected depends on more than the technology used to build it.
WordPress itself is irrelevant to the legal scope.
What matters is the business, the service being provided, the consumer relationship and the applicable national implementation of the Directive.
For example, a WordPress website used to sell products or services directly to consumers may need to be considered in the context of the EAA’s ecommerce provisions.
A WordPress website used by a covered consumer banking or transport service may fall into the scope for different reasons.
A purely informational B2B company website should not automatically be treated as if it were legally identical to either of those examples.
For businesses running a WordPress store with WooCommerce, accessibility therefore needs to be considered alongside the wider technical requirements of the ecommerce platform. You can read more about how WordPress and WooCommerce work together in our guide to WooCommerce and WordPress shops.
There is an important exemption.
Under Article 4(5), microenterprises providing services are exempt from the accessibility requirements for services under the Directive and from obligations relating to compliance with those requirements.
A microenterprise is generally an enterprise employing fewer than 10 people and with annual turnover or annual balance sheet total not exceeding €2 million.
This exemption is particularly important for services.
The regime for microenterprises dealing with products is different, so the two should not be treated as interchangeable.
There can also be other considerations under the Directive, including provisions dealing with fundamental alteration and disproportionate burden.
For that reason, a company should not decide whether it is covered solely from a generic online checklist.
If legal applicability is uncertain, that part should be reviewed under the national law implementing the Directive in the relevant Member State.
Another common misconception is that everything that existed before 28 June 2025 is permanently exempt.
The Directive contains transitional measures, but they are more specific than that.
Under Article 32 of the European Accessibility Act, Member States must provide a transitional period ending on 28 June 2030 during which service providers may continue providing services using products they lawfully used to provide similar services before the relevant date.
The same Article says that service contracts agreed before 28 June 2025 may continue unchanged until they expire, but for no longer than five years from that date. In practical terms, that means no later than 28 June 2030 under this provision.
There is a separate date that sometimes creates confusion.
Article 31 allows Member States to delay application of measures concerning the obligations in Article 4(8) until 28 June 2027. That is not a general 2027 deadline for websites or pre-existing service contracts.
For businesses maintaining older websites, the practical lesson is simple:
Do not assume that “the website existed before June 2025” settles the accessibility question.
The relevant service, contract, national legislation and applicable transitional provision all matter.
Accessibility is not only about how a website is built.
For service providers covered by the European Accessibility Act, there is also an information requirement.
Under Article 13(2), service providers must prepare information explaining how their services meet the applicable accessibility requirements and make that information available to the public in accessible written and oral formats. The information must be maintained for as long as the service is in operation.
Annex V of the European Accessibility Act goes further. It says that the service provider should include information assessing how the service meets the applicable accessibility requirements in its general terms and conditions or an equivalent document. This should include, where applicable, a general description of the service, explanations necessary to understand its operation and a description of how the relevant Annex I accessibility requirements are met.
This is sometimes described in practice as an accessibility statement, although the important point is the information required by Article 13 and Annex V rather than the label placed on the document.
It should therefore be more than a generic statement that a company “cares about accessibility”.
For a WordPress website, preparing accurate accessibility information may require first reviewing templates, navigation, forms, checkout flows, keyboard operation, content structure and other components.
In other words, you need to understand the current state of the service before you can meaningfully explain how it addresses accessibility.
The European Accessibility Act is no longer only a future compliance issue.
National market surveillance authorities in some Member States have already begun reviewing services covered by the new rules, including e-commerce services.
This does not mean that enforcement is identical across every EU Member State. The Directive is implemented through national legislation, and the responsible authorities, procedures and enforcement priorities can differ between countries.
It does mean that businesses should not treat accessibility requirements as something that exists only on paper.
And because information required under Article 13 and Annex V can be inspected externally, businesses should consider both the technical accessibility of the service and the accessibility information they are required to provide.
Legal applicability is one question.
Whether people can actually use the website is another.
For web teams, the Web Content Accessibility Guidelines, WCAG provide a practical technical framework for identifying and fixing accessibility problems.
WCAG organizes accessibility around four broad principles: content and interfaces should be perceivable, operable, understandable and robust.
On a typical WordPress website, that translates into very concrete issues.
Text needs enough contrast against its background to remain readable for people with impaired vision and other visual limitations.
For normal text, WCAG Level AA generally specifies a minimum contrast ratio of 4.5:1, with different requirements applying to large text.
A light-grey paragraph on a white background may look visually elegant while still being difficult to read.
A visitor should not need a mouse to operate essential website functionality.
Menus, links, buttons, forms, dialogs and other interactive elements need to work through a keyboard interface.
This is one of the easiest areas to test manually.
Images that communicate meaningful information need appropriate text alternatives.
That does not mean stuffing every image with SEO keywords.
The purpose of alt text is to provide an appropriate alternative for relevant non-text content. Decorative images are a different case and should not be treated as though they contain essential information.
A form can look perfectly clear visually while being confusing to someone using a screen reader or keyboard.
Fields need meaningful labels. Errors need to be understandable. Required information should not depend only on color, and users need to know what went wrong and how to correct it.
This becomes especially important on checkout, registration, booking and contact forms.
When someone navigates using the Tab key, they need to know which element is currently active.
Removing the browser’s focus indicator for visual reasons without providing an accessible replacement can make a website extremely difficult to navigate.
Video can introduce additional accessibility requirements, including captions and alternatives depending on the content and context.
This is particularly relevant for businesses using product demonstrations, webinars, tutorials and marketing video directly on their websites.
WordPress itself can be used to build highly accessible websites.
It can also be used to build inaccessible ones.
The result depends on the theme, plugins, custom code, content and decisions made during development.
Dropdown menus are a common example.
A menu may work perfectly when a user hovers over it with a mouse but become impossible or confusing when navigating with a keyboard.
Mobile menus, mega menus and custom navigation components deserve particular attention.
Editors sometimes choose headings because of how they look rather than what they mean.
That can produce pages where an H1 is followed by an H4, headings are used purely for visual styling, or important sections have no semantic heading at all.
Accessibility and visual design should not depend on the same HTML decision.
WordPress makes it easy to add alternative text to images.
That does not guarantee that it is actually added or that it is useful.
An accessibility audit may therefore reveal a content-management problem rather than a development problem.
Installing a popular form plugin does not automatically make every form accessible.
Custom styling, validation, labels, error messages, conditional fields and third-party extensions can all change the result.
These components can create problems with keyboard focus, screen readers and controls.
A modal that opens visually but leaves keyboard focus somewhere behind it creates a very different experience for a keyboard user.
The fact that a page can be assembled visually does not guarantee that the resulting HTML structure is accessible.
Custom components, widgets and page-builder elements should be tested based on their actual output and behavior, not only on how they appear in the WordPress editor.
A quick test cannot prove that a website complies with the European Accessibility Act or WCAG.
It can, however, expose obvious problems that justify a deeper audit.
Start with one important page.
For an ecommerce site, that might be a product page or checkout. For a service business, it could be a key landing page or contact form.
Use an established accessibility testing tool to scan the page.
Pay attention to issues such as missing form labels, contrast failures, missing alternative text, structural problems and invalid accessibility attributes.
Do not treat the resulting score as a compliance certificate.
Automated testing can identify certain machine-detectable failures, but many accessibility questions require human judgment and interaction with the page.
Reload the page and try to use it using only your keyboard.
Use Tab to move forward through interactive elements and Shift + Tab to move backward.
Ask:
Can you reach the main navigation?
Can you see where the focus is?
Can you open and close the menu?
Can you reach every important button and link?
Can you use the form?
Can you open and close pop-ups?
Can you complete the main action on the page?
Does focus ever disappear or become trapped?
Keyboard testing is particularly valuable because an interface can appear perfectly functional with a mouse while exposing major problems as soon as the mouse is removed.
Increase browser zoom and inspect what happens to the page.
Does text remain readable?
Does content disappear?
Do buttons overlap?
Does horizontal scrolling make the interface difficult to use?
Can important functionality still be reached?
These checks will not tell you that your website is compliant.
They can tell you something more immediately useful:
where to start looking.
Not every accessibility issue needs a developer.
That distinction is particularly useful for WordPress teams because content editors often control a significant part of the website.
Accessibility should also become part of ongoing technical care rather than something checked only when a website is launched. Our guide to WordPress website maintenance explains what regular technical maintenance should cover.
| Accessibility issue | Usually handled by | What to check |
|---|---|---|
| Missing or poor alt text | Content team | Add meaningful alternatives for informative images and handle decorative images appropriately |
| Incorrect heading structure | Content team | Use headings according to content hierarchy, not visual appearance |
| Unclear link text | Content team | Replace vague links such as “click here” with descriptive text |
| Missing video captions | Content team | Add accurate captions and, where appropriate, transcripts |
| Poor color contrast | Design / Development | Check text, buttons and interface elements against accessibility contrast requirements |
| Keyboard navigation problems | Development | Make sure menus, buttons, forms and other controls work without a mouse |
| Missing visible focus | Development | Ensure keyboard users can always see which interactive element is active |
| Inaccessible forms | Content / Development | Check labels, instructions, validation and error messages |
| Pop-ups and modal windows | Development | Check focus management, keyboard controls and screen reader behavior |
| Inaccessible theme or custom components | Development | Review the HTML structure, semantics and interaction behavior produced by the theme or plugin |
Some issues sit between content, design and development. Color contrast may require a designer to adjust the visual system and a developer to implement the change consistently, while forms may require both better instructions and changes to the underlying markup.
That is why accessibility is better treated as a property of the whole website than as a task assigned to one person at the end of a project.
This is where discussions about the European Accessibility Act can become confusing.
The accessibility obligations come from the Directive and the national laws implementing it.
Article 15 of the EAA establishes a mechanism for presumption of conformity. Where relevant harmonised standards have been cited in the Official Journal of the European Union, conformity with those standards can create a presumption of conformity with the Directive’s requirements to the extent covered by those standards.
That is different from saying:
“EN 301 549 is the law.”
As of September 2026, businesses should therefore distinguish between:
the legal requirements established by the EAA and national legislation,
the technical standards used as a route for demonstrating accessibility,
and the practical testing needed to determine whether real users can operate the website.
EN 301 549 and WCAG are highly relevant technical benchmarks, but the legal obligations themselves come from the applicable legislation.
This is an area businesses should watch.
ETSI has published EN 301 549 V4.1.1 (2026-09), the new version of the European accessibility standard.
The updated standard incorporates WCAG 2.2 requirements for web content. WCAG 2.2 itself adds criteria covering issues including keyboard focus being obscured, accessible authentication and minimum target size.
Publication of a technical standard should not be described as meaning that every business website automatically became legally required to meet every WCAG 2.2 criterion on the date the standard was published.
The standards process and the legal framework need to be considered separately.
From a practical development perspective, however, a business beginning accessibility improvements in late 2026 has a good reason to consider WCAG 2.2 rather than designing remediation work around an older benchmark alone.
That can reduce the risk of fixing a website today only to revisit avoidable accessibility issues later.
Do not begin by installing an “accessibility plugin”.
Begin by understanding the website.
Determine what services it provides and whether those services may fall within the scope of the European Accessibility Act and relevant national legislation.
Then examine the website itself.
Run an automated scan.
Navigate important journeys using only a keyboard.
Review forms, menus, checkout flows and other interactive components.
Check content practices such as headings, alternative text and video captions.
Review whether the accessibility information required under Article 13 and Annex V has been prepared and made available where applicable.
Identify which issues can be fixed by content editors and which require changes to the WordPress theme, plugins or custom code.
For websites that support important consumer transactions, a structured accessibility audit can provide a much clearer picture than a plugin score or automated scan alone.
And accessibility should not be treated only as a compliance project.
A website that can be understood and operated by more people is simply a better website.
If you are unsure where your WordPress website currently stands, start with an accessibility review of the pages and user journeys that matter most.
The goal is to identify concrete barriers, separate content problems from development problems and establish what should be fixed first.
A technical review can also provide the factual basis needed before preparing or updating the accessibility information required for services covered by the EAA.
This article is for general informational purposes and does not constitute legal advice. For questions about whether the European Accessibility Act or national accessibility legislation applies to your business, consult an appropriate legal professional in the relevant jurisdiction.
Text is based on information open to public as of 17th of Septemeber 2026.
How much does a WordPress website cost in 2026? Learn what determines the price, which costs are often left out of development quotes and how to compare two WordPress proposals based on scope, not price alone.
Your WordPress contact form looks like it works, but no emails arrive? Learn how to identify whether the problem is caused by the form, WordPress, SMTP, DNS authentication or email delivery.
A WordPress staging site lets you test updates, plugins, redesigns and new functionality before they reach your live website. Learn how staging works, why it matters, and why it is especially important for business and WooCommerce websites.
Your 24wp website is developed by experts from Cubes — an IT company that has been creating complex IT ecosystems and stable web systems for a decade.
Visit cubes.rs