I thought I had seen every way a WordPress project could fail. Then I audited a “fully accessible” enterprise site last Tuesday that ran three different overlay plugins and still failed a basic screen reader test. Most developers treat accessibility like a CSS linting error, something to clean up at the end. Without Accessible UX Research in front of the build, you are guessing with your users’ time.
Smashing Magazine has released a new book by Dr. Michele Williams that goes after the part nobody budgets for: the research phase. After 14 years of refactoring messy themes, I read “Accessible UX Research” as the missing piece that breaks the cycle of expensive, late-stage accessibility patches.
The problem with the accessibility checklist
Plenty of teams run a WCAG checklist and consider the job done. Compliance is not usability. A site can pass every automated test and still be a nightmare for someone with a motor impairment or a cognitive difference. Without Accessible UX Research, you are building fixes for problems you have not actually observed.
Dr. Williams’ book, Accessible UX Research, covers how to recruit disabled participants and run sessions that produce data you can act on. The goal is a product that works for more people from day one rather than a certificate on the wall. I have written about real accessibility improvements in WordPress core, and those tools only help if the design intent was inclusive to begin with.
Refactoring for inclusive results
Once you do the research, you find that standard WordPress patterns need help. One finding comes up over and over: hidden navigation elements get skipped by assistive technology when the ARIA states are not managed properly. Hooks are the cheapest place to fix that.
Here is the mistake I keep finding in legacy code, a menu toggle treated as a plain link with no state:
<!-- The Bad Way -->
<a href="#" class="menu-toggle">Menu</a>Apply Accessible UX Research findings and the requirement gets obvious: a screen reader needs to know whether that menu is expanded or collapsed. This is how I handle it in a custom theme with a PHP filter:
<?php
/**
* Prefix: bbioon_
* Add accessibility attributes to nav menu links based on research findings.
*/
function bbioon_accessible_nav_attributes( $atts, $item, $args ) {
if ( property_exists( $item, 'classes' ) && in_array( 'menu-item-has-children', $item->classes ) ) {
$atts['aria-haspopup'] = 'true';
$atts['aria-expanded'] = 'false';
}
return $atts;
}
add_filter( 'nav_menu_link_attributes', 'bbioon_accessible_nav_attributes', 10, 3 );
?>Inside the practical roadmap
Dr. Michele Williams stays out of the theory. Across 324 pages, the book covers how to:
- Plan research that includes disabled participants from the start.
- Recruit participants without defaulting to a one-size-fits-all panel.
- Ask better questions so the methodology does not smuggle in bias.
- Analyze results in a way that actually reaches your dev cycle.
If you have been stuck on implementing CSS contrast or similar technical hurdles, this book supplies the reasoning that makes those calls easier to make. Jared Smith of WebAIM wrote the foreword.
If this kind of accessibility work is eating your dev hours, I can take it off your plate. I have been working with WordPress since the 4.x days.
Research first, patches later
After a decade in the WordPress ecosystem, my honest read is that a lot of technical debt is accessibility debt wearing a different label. We build fast, we break things, and then we reach for a plugin to cover it. Michele’s book pushes the work earlier, into the phase where a decision is still cheap to change. If your work touches WordPress front ends, get this book.
