The European Accessibility Act (EAA) became effective on June 28, 2025—and if you're building WordPress plugins or themes for European users, this regulation now affects your business. The stakes are real: non-compliance carries fines up to €100,000 per violation and potential exclusion from EU markets.
Unlike WCAG guidelines, which are voluntary standards that most developers treat as optional, the EAA is a legal requirement. It applies to anyone selling digital products to EU users—and that includes WordPress plugin and theme developers. This is a first-mover advantage moment. Most plugin authors haven't addressed this yet. If you move fast, you can capture market share among developers who need compliance assurance.
This guide walks you through what the EAA actually requires, how it differs from WCAG, and exactly what you need to implement in your WordPress code to stay compliant.
Table of Contents
- What is the European Accessibility Act?
- Who Does the EAA Apply To?
- EAA vs. WCAG: Understanding the Relationship
- Technical Requirements for WordPress
- Specific Accessibility Patterns You Must Implement
- How to Audit Your Plugin for Compliance
- WP HealthKit's Accessibility Audit Layers
- Penalties and Enforcement
- Timeline and Deadlines
- Frequently Asked Questions
What is the European Accessibility Act?
The European Accessibility Act is a directive from the European Commission designed to ensure digital accessibility for people with disabilities across the EU. It was adopted in 2019 and entered into force on June 28, 2025. The regulation mandates that digital products and services—including websites, apps, plugins, and themes—must be accessible to people with visual, hearing, cognitive, and motor disabilities.
Run a free accessibility-aware audit by uploading your plugin to WP HealthKit — our WCAG checks cover many EAA requirements. See how top plugins handle accessibility in the WP HealthKit directory. Check the security leaderboard to see which plugins score highest on quality and accessibility. Learn more about how WP HealthKit audits work on our ecosystem page.
The EAA isn't a suggestion. It's a legal obligation with teeth. Member states are required to enforce it through market surveillance, complaints mechanisms, and penalties. The EU has already designated market surveillance authorities in every country to monitor compliance. These authorities have the power to fine companies, ban products from EU markets, and take enforcement action.
Before the EAA, web accessibility was largely self-regulated. Organizations could choose to follow WCAG guidelines voluntarily. The EAA changed that calculus. Now, if your plugin is sold to EU customers and doesn't meet accessibility standards, you're breaking the law.
The regulation applies to a broad range of "digital products and services," including software, websites, mobile applications, and—importantly—software components that can be integrated into other software. This directly includes WordPress plugins and themes.
Who Does the EAA Apply To?
The EAA applies to any organization providing digital products or services to users in the EU. This includes:
Plugin and theme developers selling through WordPress.org, commercial marketplaces, or direct sales to EU customers. If your plugin has even one active installation in an EU country, you should be treating it as subject to the EAA.
Software-as-a-service platforms hosting content or managing sites for EU users. This applies to hosted WordPress platforms, page builders, and any tools that generate digital content.
Enterprise WordPress shops building custom plugins and themes for EU clients. Your client's compliance obligations may flow back to you.
Theme marketplaces and plugin aggregators redistributing WordPress code. You may face secondary liability if you're promoting non-compliant products.
The critical question is whether you're "active in the EU market." You don't need an EU office. You don't need to explicitly target EU users. If you accept payment from EU customers, advertise in EU languages, or your software is reasonably accessible from EU locations, you're active in the market. That's enough to trigger compliance obligations.
Some exceptions exist: the EAA exempts microenterprises (fewer than 10 employees, turnover under €2 million) from certain compliance requirements, but this exemption is narrow and doesn't eliminate obligations entirely. If you're a solo developer, you should still implement accessibility features—just understand that enforcement may be lighter.
EAA vs. WCAG: Understanding the Relationship
The EAA and WCAG 2.1 AA are closely related but legally distinct. Understanding the difference matters for your implementation strategy.
WCAG 2.1 AA is a technical standard maintained by the W3C (World Wide Web Consortium). It's a detailed specification with 50 success criteria organized around four principles: perceivable, operable, understandable, and robust. WCAG is widely considered the gold standard for web accessibility. Most accessibility professionals use WCAG as their measurement tool.
The EAA is a legal regulation that mandates accessibility but doesn't specify exactly how. The regulation requires digital products to be "accessible," but the standards it references are the European standard EN 301 549 and, for web and mobile, WCAG 2.1 Level AA. So the EAA essentially requires you to meet WCAG 2.1 AA, with some extensions.
This matters because it means you can't just check WCAG compliance and assume you're legally compliant under the EAA. The EAA adds enforcement teeth and includes additional obligations:
- User support and feedback mechanisms — you must have a process for users to report accessibility issues
- Periodic re-assessment — compliance isn't a one-time audit; you need ongoing monitoring
- Detailed accessibility statements — you must publish an accessibility statement on your product's page or website
- Remediation timelines — if issues are reported, you have defined timeframes to fix them
Think of it this way: WCAG 2.1 AA tells you what accessible code looks like. The EAA tells you you must achieve it, and adds legal procedures and enforcement mechanisms.
Technical Requirements for WordPress
WordPress has accessibility features built in, but they require intentional implementation. The core WordPress platform aims to meet WCAG standards, but themes and plugins often don't. Here's what you need to ensure in your WordPress code:
Semantic HTML Structure — Use proper heading hierarchy (h1, h2, h3, etc. in order), semantic elements like <nav>, <main>, <article>, and avoid using <div> for structure. Screen readers rely on semantic structure to understand page layout.
ARIA (Accessible Rich Internet Applications) — ARIA attributes enhance semantic meaning when HTML alone is insufficient. Use aria-label, aria-labelledby, aria-describedby, aria-hidden, aria-expanded, and role attributes appropriately. Don't overuse ARIA—it should enhance, not replace, semantic HTML.
Keyboard Navigation — Every interactive element must be operable via keyboard alone. Users should navigate via Tab, activate via Enter or Space, and close modals via Escape. Test your plugin without a mouse.
Focus Management — Users navigating with keyboards need visible focus indicators. Never remove the native focus outline without replacing it with equivalent styling. When opening modals, move focus into the modal. When closing, return focus to the triggering button.
Color Contrast — Text must have a contrast ratio of at least 4.5:1 for normal text, 3:1 for large text (18pt+). This applies to both foreground/background colors and icons. Use a contrast checker tool in your design process.
Form Accessibility — Every <input> needs an associated <label> element. Use aria-required, aria-invalid, and aria-describedby to communicate form state. Provide clear error messages tied to the input.
Alternative Text for Images — Every meaningful image needs descriptive alt text. Decorative images should have empty alt attributes (alt=""). For complex images, provide longer descriptions elsewhere.
Video and Audio — Provide captions for video and transcripts for audio. This is often overlooked but legally critical under the EAA.
Dynamic Content Updates — If your plugin loads content via JavaScript, use ARIA live regions (aria-live, aria-atomic) to announce changes to screen reader users.
These aren't optional enhancements—they're legal requirements for EAA compliance.
Specific Accessibility Patterns You Must Implement
Let's get concrete. Here are the accessibility patterns you need in your WordPress plugin code:
Keyboard Navigation Pattern
// Bad: Click-only navigation
<button onClick={handleClick}>Menu</button>
// Good: Supports keyboard and focus
<button
onClick={handleClick}
onKeyDown={(e) => {
if (e.key === 'Enter' || e.key === ' ') {
handleClick();
}
}}
aria-expanded={isOpen}
>
Menu
</button>
Buttons created with JavaScript must be real <button> elements or have role="button". They must respond to keyboard events. Use semantic elements (<button>, <a>, <input>) instead of divs with click handlers.
Screen Reader Compatible Forms
<div className="form-group">
<label htmlFor="email-input">
Email Address
<span aria-label="required">*</span>
</label>
<input
id="email-input"
type="email"
aria-required="true"
aria-describedby="email-hint"
/>
<div id="email-hint" className="form-hint">
We'll never share your email. Format: user@domain.com
</div>
<div role="alert" aria-live="polite">
{error && <span id="email-error">{error}</span>}
</div>
</div>
The label must be explicitly associated via htmlFor/id. Hints and errors are announced via aria-describedby and role="alert". This gives screen reader users full context.
Focus Management in Modals
function Modal({ isOpen, onClose, children }) {
const modalRef = useRef(null);
const previousActiveElement = useRef(null);
useEffect(() => {
if (isOpen) {
// Store the element that opened the modal
previousActiveElement.current = document.activeElement;
// Move focus into the modal
modalRef.current?.focus();
} else {
// Return focus when closing
previousActiveElement.current?.focus();
}
}, [isOpen]);
return (
<div
ref={modalRef}
role="dialog"
aria-modal="true"
aria-labelledby="modal-title"
tabIndex="-1"
>
<h2 id="modal-title">Modal Title</h2>
{children}
<button onClick={onClose}>Close</button>
</div>
);
}
Modal focus must be trapped—Tab should cycle within the modal, not the page behind it. When the modal opens, focus moves into it. When it closes, focus returns to the triggering button.
Accessible Dropdowns and Menus
<div
className="dropdown"
role="menubar"
>
<button
aria-haspopup="menu"
aria-expanded={isOpen}
aria-controls="dropdown-menu"
onKeyDown={(e) => {
if (e.key === 'ArrowDown') {
setIsOpen(true);
}
}}
>
Options
</button>
{isOpen && (
<ul id="dropdown-menu" role="menu">
<li role="none">
<button
role="menuitem"
onClick={() => handleSelect('option1')}
>
Option 1
</button>
</li>
{/* More items */}
</ul>
)}
</div>
Dropdowns need ARIA roles and keyboard support. Users expect arrow keys to navigate items. The button should have aria-expanded and aria-haspopup attributes.
Live Region Announcements
<div aria-live="polite" aria-atomic="true" className="sr-only">
{message && <span>{message}</span>}
</div>
When content updates without page navigation—like search results loading or validation messages—use live regions. aria-live="polite" announces changes after the user stops typing. aria-atomic="true" ensures screen readers announce the entire region, not just the change.
These patterns aren't optional. They're what EAA compliance looks like in code.
How to Audit Your Plugin for Compliance
Compliance requires both automated testing and manual review. Here's a systematic audit approach:
Step 1: Run Automated Accessibility Scanners
Tools like axe DevTools, Lighthouse, and WAVE identify obvious issues: missing alt text, low contrast, missing labels, improper heading hierarchy. These tools catch 30-50% of real accessibility problems.
Run these on every page and interactive element in your plugin. Document issues with screenshots. Automated tools won't catch everything—especially keyboard navigation and screen reader experience—but they're a fast starting point.
Step 2: Test Keyboard Navigation
Unplug your mouse. Navigate through every feature of your plugin using only Tab, Enter, Space, and Arrow keys. Check that:
- Every interactive element is reachable
- Focus is always visible
- Focus order is logical
- Modals trap focus
- Keyboard shortcuts are documented
This manual test catches issues automated tools miss.
Step 3: Test with a Screen Reader
Use free tools: NVDA (Windows, free) or JAWS (Windows, commercial). On macOS, use VoiceOver (built in). On iOS/Android, use native screen readers.
Test critical user flows—especially admin interfaces and settings screens. Does the plugin make sense to someone using a screen reader? Are buttons labeled? Are form errors announced? Are status changes announced?
Screen reader testing is where you find semantic structure problems and missing ARIA attributes.
Step 4: Evaluate Color Contrast
Use a contrast checker tool (WebAIM, Contrast Ratio). Measure all text colors and icon colors against their backgrounds. Ensure at least 4.5:1 contrast for normal text, 3:1 for large text.
If you use color to convey meaning—like red for errors—add text or icons as fallbacks. Color-blind users won't see the red.
Step 5: Check Color and Vision
Use a color blindness simulator (Coblis, Color Oracle) to see your plugin through color-blind eyes. Do your designs still make sense? Are interactive elements distinguishable?
Step 6: Document Findings
Create an accessibility audit report. Categorize issues as critical (blocks access), major (significantly impacts use), or minor (technical violations). For each issue, document:
- What the problem is
- Where it occurs
- Why it's a violation
- What the fix should be
- Priority level
This documentation supports your "accessibility statement" and shows good-faith compliance effort if enforcement occurs.
WP HealthKit's Accessibility Audit Layers
WP HealthKit was designed with accessibility compliance in mind. The platform includes specialized audit layers specifically for detecting EAA violations in WordPress plugins and themes:
Automated Compliance Scanning — WP HealthKit's core audit engine scans plugin code for common accessibility violations: missing alt attributes, improper heading structure, missing form labels, low contrast issues, and keyboard navigation gaps. The scanner analyzes both code and runtime behavior.
ARIA Validation Layer — This layer specifically checks ARIA usage for correctness. Invalid ARIA attributes, misused roles, missing aria-labels, and improper live region setup are flagged. This catches semantic errors that basic scanners miss.
Keyboard Navigation Testing — WP HealthKit can simulate keyboard-only navigation through your plugin interface and detect unreachable elements, missing focus indicators, and improper focus order. This is harder to automate but critical for EAA compliance.
Screen Reader Compatibility Analysis — The platform analyzes your plugin's DOM structure and semantic HTML to identify potential screen reader issues. It checks heading hierarchy, landmark structure, and whether dynamic content will be announced properly.
Color Contrast Verification — WP HealthKit's visual analysis detects insufficient contrast in text, icons, and interactive elements. It reports specific contrast ratios and recommends remediation.
Accessibility Statement Generation — WP HealthKit can generate a compliant accessibility statement for your plugin, documenting known limitations and contact mechanisms for accessibility issues—a requirement under the EAA.
When you upload your plugin to WP HealthKit, the platform runs these audit layers automatically. You get a comprehensive report showing which accessibility patterns you've implemented correctly and where gaps exist. This accelerates compliance work significantly.
Penalties and Enforcement
The EAA isn't toothless. Enforcement mechanisms include:
Administrative Fines — Member states can impose fines on non-compliant organizations. The regulation authorizes penalties up to €100,000 per violation. Violations can be counted per product affected or per user impacted, making potential liability very high.
Market Surveillance — Each EU member state has designated market surveillance authorities that monitor digital products for compliance. These authorities can initiate investigations based on user complaints or proactive monitoring.
Product Bans — In serious cases, authorities can order a product removed from the EU market entirely. For plugin developers, this could mean removal from WordPress.org or blocking of product pages in EU regions.
Accessibility Statements — Authorities can require you to publish an accessibility statement explaining compliance status and known limitations. Failure to provide this is itself a violation.
Remediation Timelines — If a user reports an accessibility issue, you typically have 30 days to acknowledge it and propose a remediation timeline. Failure to respond appropriately can trigger enforcement action.
Liability for Disabled Users — Some EU countries are testing legal frameworks for disabled users to sue organizations for accessibility violations. While the EAA itself doesn't create private rights of action everywhere, some member states' implementing legislation does.
The reality: enforcement is ramping up. Authorities are hiring accessibility experts. User advocacy organizations are filing complaints. The days of treating accessibility as nice-to-have are over.
Timeline and Deadlines
The EAA became effective on June 28, 2025. This is recent—you may already be subject to the regulation.
Existing Products — Products already on the market when the EAA took effect have a transition period. The regulation allows a reasonable transition period for compliance, typically interpreted as 12-24 months depending on the product's complexity and the member state's implementing guidance.
However, this transition period is not automatic. You must be actively working toward compliance. If you made no improvements by June 2026, enforcement is likely.
New Products — Products released after June 28, 2025 must be fully compliant on release. There's no transition period for new products.
Enforcement — EU member states are now establishing enforcement mechanisms. Some have already published compliance guidance. The European Commission itself is monitoring compliance. Real enforcement actions are likely by late 2026.
Your Timeline — If your plugin is already public:
- By June 2026: Complete accessibility audit and publish findings
- By December 2026: Implement critical accessibility improvements
- By June 2027: Achieve full WCAG 2.1 AA compliance
- Ongoing: Monitor for accessibility issues and remediate within 30 days
This timeline is aggressive but achievable with focused effort.
For the full legal text, see the European Accessibility Act directive and the W3C WCAG 2.1 guidelines which form the technical foundation of EAA compliance.
Frequently Asked Questions
Does the EAA apply to my small plugin if I only have a few users in Germany?
Yes, likely. The EAA applies if you're "active in the EU market." You don't need many users—you just need to be marketing or selling to EU customers. If your plugin page on WordPress.org is visible to EU users and you accept payment from them, you're covered. Microenterprises (fewer than 10 employees, under €2 million turnover) have some exemptions, but they still must make accessibility efforts. The safest approach is to assume the EAA applies to you.
What's the difference between WCAG AA and AAA? Which do I need for EAA compliance?
WCAG 2.1 Level A is basic accessibility. Level AA includes more stringent requirements like higher contrast and more complex keyboard navigation. Level AAA is the highest standard. The EAA requires WCAG 2.1 Level AA specifically—not AAA. Level AA is a good balance between accessibility and implementation feasibility. Focus on AA first, then consider AAA for high-traffic areas.
Can I automate accessibility testing completely, or do I need manual testing?
You need both. Automated tools catch obvious issues—missing alt text, low contrast, missing labels—but they miss 50-70% of real accessibility problems. Screen readers interact with pages in ways automated tools don't simulate. Keyboard navigation has edge cases automation doesn't cover. Budget time for manual testing with actual assistive technologies. It's slower but essential.
What if my plugin uses a third-party library that isn't accessible?
You share responsibility for accessibility, even if you use third-party code. If a library you're using has accessibility gaps, you have a few options: patch the library, replace it with an accessible alternative, or document the limitation in your accessibility statement. The EAA holds you liable for your plugin's experience, regardless of dependencies. Consider accessibility when evaluating third-party libraries.
How do I write an accessibility statement that satisfies the EAA?
Your accessibility statement should document: which accessibility standards your plugin meets, known limitations, how users can report accessibility issues, and your remediation timeline. Include contact information for accessibility concerns. Be honest about limitations rather than claiming full compliance if you haven't achieved it. The statement should be published on your product page or website. The EAA Alliance publishes a template for accessibility statements that meets regulatory requirements.
Can I charge customers for accessibility improvements as an add-on?
No. Accessibility is a legal requirement, not a premium feature. You can't segregate accessibility improvements behind a paywall. However, you can pursue accessibility as a competitive advantage—emphasizing your compliance as a reason customers should choose your plugin. Some customers will pay more for assured compliance, but you can't restrict accessibility to paid tiers.
What happens if I ignore the EAA and continue selling non-accessible plugins?
You expose yourself to significant risk. Fines can reach €100,000 per violation. Market surveillance authorities can order product removal. If disabled users sue (depending on your member state), damages could be substantial. Your reputation suffers when accessibility advocates call out non-compliance. The cost of compliance now is far less than the cost of enforcement later. Move now.
How do I know when I've achieved EAA compliance?
Compliance is demonstrated through: (1) a comprehensive accessibility audit showing WCAG 2.1 AA achievement, (2) documentation of any known limitations, (3) a published accessibility statement, (4) proof of testing with assistive technologies, and (5) a process for receiving and remediating accessibility reports. You should have a dated accessibility audit report from a qualified auditor—either third-party or WP HealthKit's audit layers. This documentation proves good-faith compliance if enforcement occurs.
The Bottom Line
The European Accessibility Act is a paradigm shift for WordPress developers. Accessibility has moved from a nice-to-have to a legal requirement with real penalties. But it's also an opportunity. Most plugin authors haven't adapted yet. If you move fast, you can capture market share by offering EAA-compliant products.
Start with an audit using WP HealthKit's accessibility layers. Identify gaps. Prioritize critical issues. Implement keyboard navigation and screen reader support. Test with real assistive technologies. Publish an accessibility statement. Document your compliance effort.
The next 12 months will separate compliant plugin developers from those facing enforcement action. Don't wait.
Ready to audit your plugin? Upload it to WP HealthKit to get detailed accessibility analysis, specific remediation guidance, and documentation for your accessibility statement. Our audit layers are built specifically for WordPress developers navigating EAA compliance.