Skip to content
srihanu
All case studies

WordPress Accessibility Remediation

The theme passed the demo. It failed every screen reader.

Context

A regional services company ran their entire public presence — marketing pages, a booking flow, and a customer portal login — on WordPress with a popular premium theme and Elementor. It looked polished in the demo. Then a procurement contract put an accessibility clause in front of them, a prospective enterprise client ran their own audit, and the site failed in ways the team couldn't see: a header menu that swallowed keyboard focus, booking-form fields with no programmatic labels, body text at 3.1:1 against a pale brand background, and an Elementor accordion on the pricing page that was invisible to a screen reader. The vendor's answer was to sell them a one-line accessibility-overlay widget. That doesn't fix markup — it paints over it, and it's exactly the kind of thing that draws demand letters rather than deflecting them.

Approach

We declined the overlay and remediated at the source. The work split three ways: the theme (a child theme so updates wouldn't wipe the fixes), the page-builder output (Elementor widgets reconfigured, and the few that couldn't be salvaged rebuilt as accessible blocks), and the global design tokens (contrast and focus styles set once, in the theme, so new pages inherit them). Every change was verified the way a real user hits it — keyboard-only, then NVDA on Windows and VoiceOver on macOS — not just with an automated scan.

What's inside

  • 01Built a child theme so remediations survive theme and plugin updates — no fixes living in the customizer's 'Additional CSS' box waiting to be lost.
  • 02Replaced the keyboard-trapping mega-menu with a semantic nav: real <button> toggles, aria-expanded state, Escape-to-close, and a visible focus ring that the theme had been suppressing with outline:none.
  • 03Fixed the booking form at the markup level — every field a programmatically associated <label>, errors wired with aria-describedby and announced via a polite live region, and the submit state no longer the only signal of success.
  • 04Reset contrast in the theme's design tokens: body text and link colors moved to ≥ 4.5:1, large text and UI components to ≥ 3:1 — applied globally so authored pages inherit compliant color instead of fighting it page by page.
  • 05Rebuilt the Elementor accordion and tabs that exposed no state to assistive tech as accessible block patterns, and gave the content team a short pattern guide so new pages don't reintroduce the same widgets.
  • 06Added pa11y-ci in a GitHub Action against a list of key URLs, so a future plugin update or a page edit that drops below AA fails the build instead of shipping silently.

What it demonstrates

The site moved from dozens of automated violations plus the manual failures no scanner catches to zero critical issues against WCAG 2.1 AA, validated by keyboard and screen-reader walkthroughs of the three flows that mattered: marketing, booking, and login. The overlay was never installed. The fixes live in a child theme and a CI gate, so the next theme update — and the next page the marketing team builds — stays compliant by default.

Stack

  • WordPress
  • Child Theme (PHP)
  • Elementor
  • WCAG 2.1 AA
  • pa11y-ci
  • NVDA & VoiceOver

Facing something similar?

Twenty minutes is usually enough to know whether we can help.