I once worked on a massive WooCommerce configurator: custom components, dynamic price updates, the works. On paper we were golden. We ran the automated lighthouse audits, ticked off the “aria-label” boxes, and felt like geniuses. Then we sat down for some Accessible UX Research with a real user who relied on a screen reader. They could not get past the first step, because our technically valid DOM was a logical maze. Checking boxes is not the same thing as building for humans.
That project changed how I look at development. Most developers I know are pragmatists: we want things that work and don’t come back as bug reports. Accessibility, though, gets treated like a final coat of paint, so we patch, add a few labels and move on. My own reflex back then was to throw more ARIA at the problem, which produced more noise for the user rather than more clarity. The fix was never going to be in the code. It was in the research phase we had skipped.
How accessible UX research stops the patching cycle
That is why Michele A. Williams’ new book, Accessible UX Research, matters to developers as much as to designers. Learning how to include users with a range of abilities during testing saves you hours of refactoring clever code that turns out to be unusable. If you have ever hit the frustration of a broken accessibility workflow, this is the way out of it.
Inclusive research exposes what I call the developer’s bias: the assumption that because something works with a mouse and a 4k monitor, it works everywhere. UX Insight makes the point that bringing in diverse participants early prevents the technical debt you pile up retrofitting accessibility later. It is closer to building a culture of inclusion from the first line of code.
A practical example. Rather than guessing how a screen reader handles a complex menu, you can use a filter so the navigation attributes stay dynamic and context aware. This is the kind of logic you start writing once you have watched someone struggle with a static “aria-label.”
/**
* Properly add accessibility attributes to navigation items.
*
* Instead of hardcoding, we use filters to ensure attributes
* are only present when they serve a functional purpose.
*/
function bbioon_add_a11y_nav_attributes( $atts, $item, $args ) {
// Check if the menu item has children (aria-haspopup)
if ( in_array( 'menu-item-has-children', $item->classes ) ) {
$atts['aria-haspopup'] = 'true';
$atts['aria-expanded'] = 'false';
}
// Ensure we don't have redundant labels that clutter screen readers
if ( ! empty( $item->description ) ) {
$atts['aria-describedby'] = 'bbioon-nav-desc-' . $item->ID;
}
return $atts;
}
add_filter( 'nav_menu_link_attributes', 'bbioon_add_a11y_nav_attributes', 10, 3 );Small technical shifts like that only happen once you understand why the user’s experience breaks down. The CVS Health Inclusive Design Playbook goes into more of these methods and overlaps with a lot of what Michele outlines in her book. Both aim past compliance, at whether the thing is actually usable.
Inclusion is a mindset
Accessibility is not a set of rules you satisfy to keep a validator quiet. It is about people. Michele’s book covers disability etiquette and how to run sessions that work for the people sitting in them. If you lead a team, push them to read it. It changes how you plan features, how you recruit for betas, and whether you ship something that quietly excludes a large part of your market.
- Plan the research with disabled participants in it from day one.
- Learn to drive the assistive technologies yourself. Familiarity comes before empathy.
- Don’t lean on automated tools; they catch about 30% of the actual barriers.
- Make accessibility a core requirement rather than a “nice to have,” and your team starts trusting the process.
This gets complicated fast, especially on big WooCommerce setups or custom SaaS dashboards. If you are tired of debugging someone else’s mess and you want a site that is genuinely inclusive and functional, drop me a line. I have probably seen your version of it and fixed it properly.
So, are you still checking boxes, or are you actually talking to your users?
