WordPress Accessibility & the European Accessibility Act: Agency Guide
The European Accessibility Act (EAA) is now enforceable. If your agency builds websites for clients who sell products or services to EU customers, accessibility is no longer optional — it is a legal requirement. Here is what you need to do at the code level.
What Is the EAA and Who Does It Affect?
The European Accessibility Act (Directive 2019/882) was transposed into national law across the EU and came into enforcement on 28 June 2025. It requires that digital products and services — including websites and e-commerce platforms — meet accessibility standards equivalent to WCAG 2.2 Level AA.
Who Is Affected?
- • Any business offering services to EU consumers (including UK agencies with EU clients)
- • E-commerce sites, SaaS platforms, banking services, transport booking
- • Micro-enterprises (<10 employees) may be exempt, but their clients often are not
- • Non-compliance penalties vary by member state but can include fines and service bans
The Top WordPress Accessibility Failures I See
After auditing dozens of agency WordPress sites, these are the most common issues that fail WCAG 2.2 AA:
Missing or Incorrect Heading Hierarchy
Jumping from H1 to H4 because the designer liked the size. Screen readers depend on logical heading order to navigate. This must be fixed in the theme code, not the content.
Poor Colour Contrast
Light grey text on white backgrounds is epidemic in modern design. WCAG 2.2 requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. I catch this during design handoff, before writing any code.
Non-Keyboard-Navigable Menus
Hamburger menus that only respond to click/touch events. Custom dropdowns with no
aria-expandedstates. Focus trapping missing from modals. All critical failures.Images Without Alt Text
Decorative images should have empty
alt=""attributes. Content images need descriptive alt text. Most page builders make it easy to skip both.Forms Without Labels
Placeholder text is not a label. Every form input needs a visible or programmatically associated
<label>. This is a basic WCAG requirement that many "modern" designs ignore.
How I Build Accessible WordPress Sites
Accessibility is not a plugin you install after launch. It is baked into every step of my design-to-code process:
Design Review
I audit the design file before writing a single line of code. Contrast ratios, touch target sizes (minimum 44x44px), focus state visibility, and heading hierarchy are all checked at the Figma stage.
Semantic HTML First
I use proper HTML5 landmarks (<nav>, <main>, <aside>, <footer>), correct heading hierarchy, and meaningful link text. This alone fixes 60% of accessibility issues.
Keyboard Navigation
Every interactive element is reachable via Tab. Modals trap focus correctly. Skip-to-content links are implemented. Custom components have appropriate ARIA attributes.
Automated + Manual Testing
I run axe DevTools and Lighthouse on every page, then manually test with keyboard-only navigation and VoiceOver. Automated tools catch ~40% of issues; manual testing catches the rest.
Quick Wins for Existing Sites
If your agency already has live client sites that need compliance, here are the highest-impact fixes:
- Add skip-to-content link — a hidden-but-focusable anchor that jumps past the navigation. Takes 5 minutes, huge impact for keyboard users.
- Fix heading order — ensure every page has exactly one H1 and headings flow H1 → H2 → H3 without skipping levels.
- Audit colour contrast — use the WebAIM Contrast Checker on all text/background combinations. Fix the CSS variables in the theme.
- Label all form inputs — add explicit
<label for="...">to every form field. If the design hides labels, usesr-onlyclasses. - Add alt text to images — audit the media library. Set decorative images to
alt=""and give content images descriptive text. - Test with keyboard only — unplug your mouse and navigate the entire site using only Tab, Enter, Escape, and arrow keys.
Why Page Builders Make This Harder
Most page builders output deeply nested <div> structures with generic classes. They rarely produce semantic HTML, and their ARIA implementation is inconsistent at best. This is one of the core reasons I prefer custom Gutenberg blocks or hand-coded themes — I control the HTML output completely, which means I can guarantee compliance at the code level rather than hoping a plugin does it correctly.
Need an Accessibility Audit or Compliant Build?
I offer WCAG 2.2 AA compliance audits for existing sites and build new WordPress themes with accessibility as a core requirement — not an afterthought.