How to Make a WordPress Website Compliant with the EAA

WordPress EAA Compliance means making a WordPress site meet the accessibility requirements the European Accessibility Act expects for covered goods and services. This guide shows which standards to aim for, exact WordPress fixes, a practical test script, and a maintenance checklist you can use right away.

Does the EAA apply to your WordPress site?

The EAA sets accessibility obligations for certain products and services placed on the EU market. Public sector sites are already covered by other EU rules, but many private websites that sell goods, provide services, or act as digital interfaces will fall inside the EAA scope. Check legal advice or your national authority for whether your site is in scope.

Which accessibility standard to target

Auditors and EU guidance normally refer to WCAG and the European accessibility standard EN 301 549. Aim for WCAG 2.1 level AA as the baseline for web content. Use the relevant European harmonised standard where required for legal compliance.

Prioritised WordPress EAA compliance checklist (quick wins)

• Ensure semantic headings and document structure across templates.
• Confirm keyboard access to every interactive control.
• Add meaningful alt text for all informative images.
• Provide captions for video and transcripts for audio.
• Make forms accessible: labels, fieldset, clear error messages, and ARIA where needed.
• Ensure colour contrast meets WCAG AA for body text and UI elements.
• Make focus styles visible and consistent across browsers.
• Add a skip-to-content link and landmark roles for header/nav/main/footer.
• Use an accessibility-ready theme or fix theme template issues.
• Document accessibility and provide a contact for feedback.

Step-by-step: Fix the theme and templates

Choose or audit an accessibility-ready theme

Start with a theme tagged accessibility-ready on WordPress.org when possible. If you must keep a custom theme, run a template audit. Look for missing semantic tags, skipped heading levels, and non-keyboard components.

Header, navigation and landmarks

Add a visible skip-to-content link at the top of every page. Use <nav>, <main> and <header> elements. Ensure menus are reachable by tab and by arrow keys. Provide aria-expanded and aria-controls on toggles when using JavaScript menus.

Page builders and block editors

If you use Gutenberg, Elementor, or another builder, test the markup they produce. Some blocks output non-semantic HTML. Prefer blocks that produce headings, lists and paragraphs over raw divs. For complex custom blocks add proper labels and roles.

Content and media

Accessible content is the easiest compliance win. Use clear headings, short paragraphs, and meaningful link text. For all images include descriptive alt text. For decorative images use empty alt attributes.

Video and audio

• Provide captions for video and a full transcript for audio-only content.
• Do not rely on auto-generated captions without review.

Tables and lists

Use table headers and scope attributes for data tables. Use semantic lists for grouped items. Avoid layout tables for page design.

Forms and interactive components

Every form field needs a visible label. Use <label for=“id”> or aria-label when a visible label is impossible. Group related fields with <fieldset> and <legend>.

Validation and error handling

Place error messages next to the relevant field. Announce errors to assistive tech using aria-live or role=“alert” for dynamic responses. Make instructions persistent where needed rather than only in error text.

Widgets, modals and custom controls

Manage focus when opening modals. Trap focus inside modals and return focus to the triggering control when closed. For custom widgets supply role, aria-haspopup, aria-expanded and keyboard handlers that match native behaviour.

Dynamic content and JavaScript

Use WAI-ARIA patterns for live updates. Mark regions that change with aria-live when appropriate. Test keyboard activation and focus movement for all JavaScript-driven widgets.

Plugins: selection and testing

Only use plugins that follow accessibility best practice. Test every plugin in the admin and front end. Remove or replace plugins that break keyboard access, create unreadable contrast, or inject inaccessible markup.

Testing: automated and manual (exact test script)

Use both automated tools and hands-on tests. Automated checks catch many issues fast. Manual testing finds the rest.

Automated tools

• Run Lighthouse accessibility audits in Chrome for a quick baseline.
• Use axe DevTools or WAVE for detailed rule results.

Manual test script (run this on a few representative pages)

1. Keyboard test: Tab through the page. Ensure every control is reachable and focus order is logical.
2. Skip link: Press Tab from top of page and activate skip-to-content.
3. Headings: Open page outline. Verify headings form a clear outline without skipped levels.
4. Forms: Fill and submit a form with keyboard only. Trigger validation and confirm errors are announced.
5. Screen reader: With NVDA or VoiceOver, navigate headings, links and forms. Listen for meaningful link text and image descriptions.
6. Contrast: Check several text and UI elements with a contrast tool to confirm readability.
7. Media: Play a video and confirm captions are present and readable.

Decision framework: replace theme or patch it?

If the theme produces large structural issues across many templates or blocks and the vendor will not fix them, replacing the theme is faster. If problems are isolated to a few templates or a small set of controls you can patch them in the child theme or with targeted plugin fixes. Choose replacement when fixes would require repeated fragile workarounds.

Common mistakes to avoid

• Relying solely on automated scanners and ignoring manual checks.
• Installing many unvetted plugins without testing accessibility impact.
• Using cookie banners or popups that trap keyboard focus or hide controls.
• Removing focus outlines for aesthetic reasons and not replacing with an equally visible style.

Maintenance, documentation and evidence

Keep an accessibility log for the site. Record audits, fixes, and user feedback. Add accessibility checks to your release pipeline and code reviews. Provide an accessibility statement that lists conformance level, known limitations and a contact for accessibility issues.

Where to get help

Use specialist accessibility consultants for complex sites or when you need a conformity assessment. For many sites a combination of an automated audit, the manual test script above, and modest developer fixes will reach the required level of accessibility.

Next step: Run the quick wins checklist today, follow the manual test script on your core pages, and create an accessibility record that you update after each release.