This episode of Jukebox, WP Tavern’s podcast, features Nathan Wrigley in conversation with Joe Dolson and Jonathan Desrosiers about canonical plugins and whether accessibility belongs in WordPress Core or should live as a canonical plugin.
Who’s speaking
– Jonathan Desrosiers: a full-time sponsored Core contributor at Bluehost, working on processes, testing frameworks, and release support.
– Joe Dolson: a part-time Core contributor and committer sponsored by GoDaddy and Kinsta, focused on accessibility across Core, Gutenberg, and wordpress.org.
What a canonical plugin is
Canonical plugins are official, project-backed plugins that provide features related to Core responsibilities but live outside Core. They get Core-like support: security incentives, project attention, and commitments around maintenance and backwards compatibility. Historically, WordPress has used feature plugins to incubate work (examples include MP6, REST API, Simple XML Sitemaps). Canonical plugins can be long-term supported add-ons or experimental spaces (for example, Performance Lab) to refine ideas before deciding whether or how to merge them into Core.
Why canonical plugins exist
They provide a middle ground: a faster release cadence, more focused scope, and a place to test approaches without locking Core into a single implementation. This structure helps try new UI flows, experimental features, or alternate implementations while keeping Core stable and opinionated.
Examples and practical nuance
– Importers: Classic canonical tools installed on demand. Useful, but maintenance can lag, and edge cases (very large data sets) can expose UI or performance problems.
– Performance Lab: An experimental suite broken into sub-plugins for discrete features (modern images, speculative loading). It shows how breaking functionality into smaller pieces helps testing and iteration.
– Video and media: Core outputs a basic HTML5 video element. Replacing that with accessibility-focused players (e.g., Able Player) tends to work better as a plugin that renders blocks differently rather than making a single Core choice for every site.
Why accessibility is different
Accessibility spans a wide spectrum: from basic admin requirements to advanced, context-dependent front-end accommodations. It affects legal compliance in some jurisdictions and has direct human impact. Because the admin interface is a shared responsibility of Core, accessibility fixes for the dashboard and editor should live in Core. Conversely, front-end markup and presentation are largely controlled by themes and plugins, so improvements there are often better handled outside Core, or as guidance and tooling for theme/plugin authors.
Pros of an accessibility canonical plugin
– Faster iteration and experimentation: Plugins can ship more often and test different approaches without committing Core.
– Configurable levels: Organizations with strict compliance needs could enable stricter settings or add-ons beyond Core’s baseline.
– Modular testing: Features like alternative players, AI-assisted suggestions, or authoring checks can be developed as optional modules before considering Core inclusion.
Cons and risks
– Discoverability: End users may not find a canonical plugin when they need it. Hosts, featured listings, or setup recommendations can help, but gaps remain.
– Complacency risk: Relying on a plugin for accessibility could let Core regress or leave admin issues unaddressed. Plugins can also be under-maintained or introduce regressions.
– Legal and moral stakes: Accessibility carries regulatory and ethical obligations—treating it as optional can harm real users who rely on accessible interfaces.
Where to focus accessibility work
– Core admin: Prioritize fixing legacy accessibility issues in the dashboard and ensure Core meets standards such as WCAG 2.2 AA. The admin must be usable for everyone.
– Gutenberg and plugin workflows: Many new experiences are built inside Gutenberg. Accessibility improvements that are tightly coupled with editor features should be developed in the plugin, with a migration path into Core as editor APIs stabilize.
– Authoring guidance: Build in-editor tooling and checks (Authoring Tool Accessibility Guidelines): contrast warnings, alt text guidance, and content structure prompts to help authors create accessible content.
– Block themes and theme.json: Use the structured configuration in block themes to bake accessibility-friendly defaults and controls into theme output.
– Media & alt text model: Improve the data model for alt text (context-aware or multiple variants) instead of a single attachment meta field, so images can have purposeful, contextual descriptions.
Practical workflows and deployment
– Modular canonical sub-plugins: Rather than one monolithic accessibility plugin, use targeted modules (media accessibility, player accessibility, editor checks) that sites can adopt selectively.
– Discovery and adoption: Feature canonical modules in the plugin installer, recommend them during site setup, or have hosts pre-install them in regions with legal requirements.
– Feedback and telemetry: Establish respectful telemetry or opt-in feedback loops to understand usage and decide what experiments should graduate into Core. A/B-style testing and adoption metrics can guide decisions.
– Decision philosophy: Core prefers decisive, broadly useful features rather than many options. Canonical plugins let WordPress support edge cases and advanced needs without bloating Core.
Opportunities for AI
AI can offer practical accessibility assistance: suggesting alt text, auditing pages for issues, or giving in-editor recommendations for contrast and semantic structure. Initially, these services might live in canonical plugins (audit/suggestion tools) until patterns stabilize enough to consider more native integration.
Human and ethical context
Accessibility aligns with WordPress’s mission of democratizing publishing. Improvements enable people and organizations—charities, veterans, those with temporary or permanent disabilities—to access and share information. That moral imperative raises the stakes beyond technical considerations: accessibility work has real-world consequences.
Conclusions and next steps
There isn’t a single right answer. The most effective approach will be a mix: ship essential admin fixes in Core, use canonical plugins for modular experimentation and advanced features, improve authoring tools, and educate the ecosystem. Priority actions include defining the scope of any accessibility canonical plugin, ensuring Core’s admin remains accessible, modularizing solutions, improving discoverability, creating feedback loops to evaluate experiments, and leveraging spaces like Performance Lab or Gutenberg to iterate. The conversation should continue as legal regimes evolve and new technologies—such as AI—change what’s possible. A follow-up check-in in a few months could reassess progress and lessons learned.
Thanks to Joe Dolson and Jonathan Desrosiers for sharing their perspectives on balancing Core responsibility, canonical plugins, and the urgent human-centered importance of accessibility.