Why Your WordPress Plugin Might Be Excluding Millions of Users
This week, the WordPress accessibility community gathered virtually for WordPress Accessibility Day 2024, the most important yearly conference dedicated to making WordPress accessible to everyone. The Insi team attended to learn from accessibility experts and share insights with our community.
One session stood out as particularly relevant for WordPress developers, agencies, and site owners: “Auditing WordPress Plugin Accessibility: A Practical Journey from Code to Compliance” presented by Osdeibi Acurero, a full-stack developer and content creator with over 10 years of WordPress experience.
The Plugin Problem Nobody Talks About
Here’s something most people don’t realize: plugins are the backbone of WordPress. If your plugins aren’t accessible, it doesn’t matter how well-designed your theme is—you’re still excluding a significant portion of your potential audience.
Osdeibi opened with a sobering truth from his own experience: “For a long time, I overlooked accessibility. But once I understood its importance, I saw how it improved my projects and my overall skill set.”
His session walked through practical, immediately actionable steps that any developer can implement, regardless of their accessibility expertise level.
The Most Eye-Opening Insights
1. Accessibility Starts Before You Write Code
The first accessibility consideration isn’t color contrast or screen readers—it’s internationalization. When you hard-code your plugin in English, you’re building barriers for non-English speakers. WordPress makes this easy with built-in internationalization functions, and the community has volunteer translators ready to help. Making your plugin translatable is accessibility in action.
2. Semantic HTML Isn’t Optional
Osdeibi demonstrated a common mistake: forms with labels that only work visually. He showed how developers often create labels without properly linking them to inputs using the for attribute and matching id. The result? The form looks fine to sighted users, but screen readers can’t tell users what each field is for.
Even worse, some developers skip labels entirely and rely only on placeholder text. This might look clean, but it’s completely inaccessible. If you must hide visual labels, you need to add aria–label attributes so screen readers can still announce what each field does.
3. Your Browser Already Has Accessibility Testing Tools Built In
One of the most practical parts of the session was Osdeibi’s walkthrough of Chrome DevTools’ accessibility features. Most developers don’t know these exist:
- Accessibility Tree View: Press Ctrl+Shift+P, type “show accessibility,” and see exactly how screen readers interpret your page
- Color Contrast Checker: The color picker in DevTools shows visual guides for WCAG AA and AAA compliance—no guessing required
- Vision Deficiency Simulator: Emulate how users with various visual impairments see your site, including color blindness, blurred vision, and reduced contrast
Osdeibi demonstrated how someone with protanopia (red-green color blindness) can’t distinguish between “OK” and “Cancel” buttons if you only use color to differentiate them. This simple insight can prevent countless usability issues.
4. Keyboard Navigation Is Non-Negotiable
Many users navigate websites exclusively with keyboards—people with motor disabilities, visual impairments, or those using assistive technology. Every interactive element in your plugin must be reachable with the Tab key and operable with Enter or Escape.
The most common mistake? Removing focus indicators for aesthetic reasons. That visible outline when you tab through a page isn’t a design flaw—it’s essential for keyboard users to know where they are.
For modals and popups, Osdeibi emphasized the importance of “focus trapping”—keeping keyboard focus inside the modal while it’s open, automatically focusing the first interactive element when opened, and returning focus to the trigger element when closed.
5. The Three-Layer Testing Process
Osdeibi outlined a straightforward testing approach that doesn’t require specialized knowledge:
Layer 1 – Keyboard Testing: Navigate your entire plugin interface using only your keyboard. If you can’t reach every interactive element or lose visible focus, you have accessibility issues.
Layer 2 – Screen Reader Check: Use free tools like NVDA (Windows), VoiceOver (Mac), or Orca (Linux). You don’t need to be an expert—just listen. If you hear “button, label” with no description, your code is missing semantic HTML or proper attributes.
Layer 3 – Automated Analysis: Run Lighthouse in Chrome DevTools or similar browser extensions. These won’t catch everything, but they’ll identify the most common issues and tell you where to start looking.
Why This Matters for the WordPress Ecosystem
As Osdeibi pointed out in his closing, WordPress powers a massive portion of the internet. When a plugin fails accessibility standards, that problem gets multiplied across thousands or millions of sites. The responsibility isn’t just about compliance—it’s about genuinely serving all users.
His final message resonated with Insi’s mission: “Accessibility is a continuous journey, and every line of accessible code makes the WordPress ecosystem stronger.”
The Bottom Line
You don’t need to be an accessibility expert to make your plugins more inclusive. Start with the basics:
- Use semantic HTML properly
- Link labels to inputs correctly
- Test with your keyboard
- Check color contrast using DevTools
- Run automated scans before releasing
Each of these steps takes minutes to implement but can transform your plugin from functional to genuinely inclusive.
Want to stay updated on practical accessibility insights for WordPress? Follow Insi for regular posts on making WordPress accessibility achievable, not overwhelming. We’re committed to genuine solutions that work for real websites—no compliance theater, just results.
