Welcome to Jukebox, WP Tavern’s podcast exploring WordPress topics. In this episode Nathan Wrigley speaks with Joe Dolson and Jonathan Desrosiers about canonical plugins and whether accessibility belongs in Core or as a canonical plugin.
Who they are
– Jonathan Desrosiers: Full-time sponsored Core contributor at Bluehost. He works on processes, testing frameworks, and release support.
– Joe Dolson: Part-time Core contributor and committer, sponsored by GoDaddy and Kinsta, focused on accessibility across Core, Gutenberg, and wordpress.org.
What is a canonical plugin?
– Canonical plugins are Core-sponsored plugins intended to provide reliable, secure features that might otherwise be in Core. They carry project support, security incentives (HackerOne, bounty program), and promises around backwards compatibility and maintenance.
– Historically, feature plugins (e.g., MP6, REST API, Simple XML Sitemaps) incubate features that may later be merged into Core. Canonical plugins can be either long-term external add-ons or experimental grounds (e.g., Performance Lab) to refine features before merging.
– They offer a middle ground: more focused, potentially more frequent releases, and a place to test different approaches without committing Core to a single path.
Examples and nuances
– Importer plugins: Classic canonical tools (e.g., WP Importer) installed on demand. They’re useful but sometimes lack needed maintenance for edge cases (huge user lists causing poor UI performance).
– Performance Lab: An experimental plugin with sub-plugins for specific features (modern image formats, speculative loading). It demonstrates breaking functionality into manageable, testable parts.
– Video block: Core outputs a basic HTML5 video element. Enhancements for accessibility (like using Able Player) currently live better as plugins that render the block differently, showing how some improvements may fit better outside Core.
Why accessibility is different
– Accessibility is broad and complex, spanning mandatory basics to advanced, sometimes conflicting, accommodations. It touches both the admin (back-end) and the front end, and legal obligations (e.g., EU regulations) are increasing the stakes.
– Admin accessibility should be in Core: interfaces must be accessible for all users; Core code must adhere to accessibility standards. Plugins shouldn’t be a band-aid to fix an inaccessible admin.
– Front-end accessibility is trickier: themes and plugins control far more front-end markup. Core has limited control, so improving front-end accessibility often requires better themes and plugins, guidance in authoring tools, or optional enhancements.
Pros and cons of an accessibility canonical plugin
Pros:
– Flexibility and cadence: Plugins can release more frequently and experiment with approaches (useful for iterative improvements).
– Configurability: Organizations with stricter legal obligations could enable stricter settings or levels beyond Core’s baseline.
– Experimentation: Plugins can trial UI enhancements, AI-assisted features, or different player implementations without locking Core into a choice.
Cons:
– Discoverability: Non-technical users may not find or install canonical plugins when they need them. Hosts or featured plugin tabs can help, but gaps remain.
– False sense of coverage: Relying on a plugin for accessibility could let Core regress or leave admin issues unaddressed. There’s risk of plugins being under-maintained or introducing regressions (e.g., overlay accessibility plugins that do more harm than good).
– Legal and moral stakes: Accessibility isn’t just a nicety; it has legal implications and a moral imperative—failure affects real people’s access to information and services.
Where accessibility work should focus
– Core admin: Fix legacy accessibility issues in Core. Core must adhere to standards (WCAG 2.2 AA) and ensure the admin is usable.
– Gutenberg/plugin development: Many new features are developed in Gutenberg. Accessibility fixes for editor experiences belong in the plugin when appropriate; as Gutenberg stabilizes, those changes can move toward Core.
– Authoring guidance: Implementing more in-editor checks (Authoring Tool Accessibility Guidelines) helps authors create accessible content—color contrast warnings exist, and alt text guidance or validation could be improved.
– Block themes and structured data: Block themes’ structured configuration (theme.json) provides an opportunity to bake accessibility considerations into defaults, controls, and markup generation.
– Media and alt text: Alt text is context-sensitive; current storage as a single attachment meta field is insufficient. Better data models—allowing context-aware alt text or multiple saved variants—would improve accessibility workflows.
Practical considerations and workflows
– Granularity and modularity: Instead of a single monolithic accessibility plugin, consider modular canonical sub-plugins targeting specific problems (e.g., media accessibility, image formats, player accessibility).
– Targeted adoption: Canonical plugins can be featured in the plugin installer, adopted by hosts, or recommended during setup for regions with legal requirements.
– Feedback and telemetry: To decide whether plugin features should move into Core, the project needs better ways to learn who uses which experiments, gather feedback, and run A/B-style testing.
– Decision philosophy: Core aims for “decisions, not options” and the 80/20 rule—features merged into Core should serve a broad majority without overwhelming the UI. Canonical plugins can allow advanced or narrow-use solutions without bloating Core.
Opportunities for AI
– AI could assist authors by suggesting accessible alt text, auditing pages, or providing in-editor recommendations for contrast and structure—similar to SEO tools that offer guidance.
– AI integration might be part of canonical plugin tooling (an audit/suggestion service) rather than baked into Core, at least initially, until stable approaches emerge.
Human and ethical context
– Accessibility directly supports the project’s mission of democratising publishing. It enables organisations and individuals—humanitarian groups, veterans, or people with temporary disabilities—to access and share information.
– The moral dimension raises the stakes beyond performance or SEO: accessibility improvements can have life-changing impacts.
Conclusions and next steps
– There’s no single right answer: accessibility improvements will likely require a mix of actions—Core fixes for admin, canonical plugins for modular enhancements and experimentation, better authoring tools, and ecosystem education.
– Key priorities include clarifying what an “accessibility canonical plugin” would do, ensuring Core remains accessible, improving discoverability for plugins, modularizing solutions, improving feedback mechanisms, and leveraging experimental spaces like Performance Lab or Gutenberg for iteration.
– The conversation will continue as the community explores canonical plugin roles, legal developments evolve, and new technologies (like AI) offer assistance. A follow-up check-in in months could reassess progress and lessons learned.
Thanks to Joe Dolson and Jonathan Desrosiers for their perspectives on balancing Core responsibility, canonical plugins, and the urgent, human-centered importance of accessibility.
