[00:00:19] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case a debate about whether or not there’s a place for accessibility in a canonical plugin.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today, we have Joe Dolson and Jonathan Desrosiers. As you’ll hear in their podcast introductions, both Joe and Jonathan are veterans of WordPress, committing to Core in different ways. They’re deeply committed towards making the platform more useful for all users.

This episode is all about exploration rather than answers. Joe and Jonathan discuss the world of canonical plugins, a special category of plugins maintained by the Core team. They’re designed to be as reliable and secure as features found in WordPress Core itself.

The discussion unpacks exactly what defines a canonical plugin, how these plugins have evolved out of the traditional feature plugin model, and what it means for users and contributors alike.

At the center of this episode is accessibility, should accessibility enhancements remain a primary concern within WordPress Core, or is it time to start developing them as canonical plugins? Joe and Jonathan discussed the pros and the cons of both options, referencing technical challenges, project philosophies, and the ever-changing legislative environment, especially with tough new regulations in Europe.

They consider the discoverability of canonical plugins for non-technical users, potential overlaps and division of labour between plugins and Core, and the moral imperative of making websites accessible to all.

We also touch upon practical examples, from the WordPress video block to the Performance Lab plugin, and weigh up how cadence, stability, and focus can differ outside the Core.

The conversation also goes beyond theory, delving into the real life impact accessible technology has, from legal requirements, to personal stories and the broader mission of democratizing publishing.

Whether you’re a developer, a site owner, or someone interested in the ethical questions at the heart of open source software, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Joe Dolson and Jonathan Desrosiers.

I am joined on the podcast by Joe Dolson and Jonathan Desrosiers. Hello both.

[00:03:35] Joe Dolson: Hello. I’m so glad to be here again.

[00:03:37] Jonathan Desrosiers: Likewise.

[00:03:38] Nathan Wrigley: We’ve had quite a preamble chat prior to recording this. This is going to be an exploration podcast. I don’t think we’re going to arrive at the destination. This is, I think about the journey.

But it’s going to be a conversation about something called canonical plugins. Dear listener, if you don’t know what that means, hold on. But also about accessibility. Prior to that, probably a good idea to get both of your biographies so that we know a little bit about you, and your credentials in the areas under discussion. So should we start with you, Jonathan, just a little bio. Tell us who you are.

[00:04:08] Jonathan Desrosiers: My name is Jonathan Desrosiers. I am a full-time sponsored Core contributor to the WordPress project from Bluehost. And I spend a lot of my time on the day to day, the work that keeps the project moving. That may be lesser seen, like our processes, our testing frameworks, helping the release squad with the resources, make sure they have the resources they need to do their jobs well, and ultimately produce good releases of WordPress every time.

[00:04:35] Nathan Wrigley: Nice. Thank you so much. And Joe.

[00:04:37] Joe Dolson: So I’m a part-time Core contributor to WordPress. I’m also a Core committer and I’m sponsored by GoDaddy and Kinsta. I mostly work on accessibility, so I help make all aspects of the project more accessible, including Core, Gutenberg, wordpress.org itself and all of those related bits and pieces.

[00:04:56] Nathan Wrigley: Okay, so we’ve established your credentials. The topic under discussion, I’m going to try and find the post in the Slack channel, which kind of promoted this whole thing, but it goes back a few months now. And the topic under discussion today is about whether or not it would be a good idea, I’m going to say, let’s go with that, an interesting idea, a good experiment, who knows, to put accessibility work into a plugin of a special type called a canonical plugin. So we’re used to hearing about plugins, perhaps not so much canonical plugins. So let’s make that the first port of call. What is a canonical plugin?

[00:05:34] Joe Dolson: I mean, I think we can kick this off with the idea that we don’t really know. But there is a long history in the project of essentially Core sponsored plugin projects that are used for specific features or provide various functionality. And then sometimes they get merged into Core and sometimes they don’t. It’s highly variable.

So there is a deep reality that this particular proposal, we don’t have any clear idea of what it’s actually proposing. But I think it’s good to talk about some of the historical canonical plugins that have already been used.

One great example I think is the WordPress Importer. It’s a plugin. It’s installed on demand into your dashboard when you decide to go to import something. And it’s an extremely standard tool. And it’s kind of the classic idea of something that isn’t needed in Core permanently, but is heavily used and really needs to be something that is maintained by the project.

[00:06:29] Jonathan Desrosiers: Yeah, I think it goes back, like Joe said, pretty far in that in the past we’ve had this concept called feature plugins. And so the initial idea behind those was to begin work on a feature that would span many releases and to get it into a refined state where it was ready for primetime to be included, you know, and shipped to the world.

So some good examples of this are the MP6 plugin which, re-skinned the dashboard in the modern way that we know today.

The REST API started as a feature plugin project. There’s many more to that effect. Simple XML Sitemaps, I believe started as a plugin as well.

I think of this in the way that canonical plugins are always feature plugins, but feature plugins are not always canonical. And so what I mean by that is a feature plugin can always become a canonical, but that may not be the case. It may end up in Core and we don’t need it long term. Or we could decide that it’s just not a good fit and it could become a canonical, and we maintain it long term as that add-on type plugin that you would use, that’s officially supported and maintained.

And so even before the suggestion to put accessibility into a canonical plugin, there were a few posts from Matt that suggested that we revisit this concept of feature plugin. And I think it’s just, canonical is just in some ways a new name for it in the sense that, you know, an SEO, canonical is you put the canonical tag and it points to the one true page on the internet that represents that content, right?

And so it’s similar to that, in that we want to have these canonical plugins that are the one true place you should be able to rely on for functionality that adheres to the project philosophies in the same way as if it were in Core itself.

[00:08:07] Nathan Wrigley: I suppose my supposition about canonical plugins are that they encapsulate important things that could be in Core. You know, if the universe was slightly different, they could easily be rolled into Core. But also importantly, they receive security updates and the same kind of inspection that Core might have. So it’s not like they’re just sort of left to fester.

On a regular basis, they would be inspected, updated in much the same way that Core would be. So it’s almost like Core, but kind of install it yourself. But the importance being that you can utterly rely on it, if you install it to be dependable, to be updated, to be secure. Have I misremembered, that or is that a part of the definition of a canonical plugin?

[00:08:53] Jonathan Desrosiers: No, that’s accurate. We give you that same commitment to backwards compatibility. The project philosophies, as I mentioned, the plugins that are maintained that are released as community plugins are covered by the Bounty Program and our Hacker One program as well. So there’s incentive for people to find security vulnerabilities and responsibly report them and work with the security team to fix these for the community.

That’s right in that you are getting kind of like that badge of honor, like we promise, guarantee type thing, that we’re going to do our best to give you the best plugin for this particular feature.

And the importer I think is a great example of that, right? They’re not all great, in good shape, and part of that is because some of them are importing from software that’s also, that’s really old and outdated, right? And the concepts that they have and the data structures.

But we have almost a dozen importer plugins that are, in a sense, canonical, and they are the go-to plugins to import your content into WordPress. I’m hopeful the Data Liberation Project will help make those more refined and make them easier to use and less prone to issues, yeah. But, yes, in theory we do give you that guarantee and that backing.

[00:09:58] Joe Dolson: I mean, one of the reasons I did bring up the importers is because I think they’re actually a really good example of something that isn’t getting the care that it really needs. I mean, they’re stable and they’re functional, but there are certain things that they really don’t do very well.

And one of them is, like if you’ve got a site with say, 10,000 users, you just can’t use the importer plugin. Because it generates these select dropdowns to assign your posts to a particular user, and the performance on those is ludicrous when you’ve got a page that has 100 dropdowns with 10,000 items in them.

This is the sort of thing that I think everybody would like to see worked on more in the world of canonical plugins. And that’s, I think one of the fears that maybe some people have about moving more stuff into canonical plugins, is this idea that they might not get the care that we theoretically promise.

Because I do think, the idea of canonical plugins, we absolutely do promise those security updates and making sure all of these things are solid, but I’m not sure we’ve always carried out on that as well as we could.

[00:11:03] Jonathan Desrosiers: You said something that resonated too in that. So one of the Core philosophies is the 80 20 rule. And so we want to make sure that the things we merge into Core work for the majority of our users that use our software. And so the same kind of holds true for canonical plugins in some ways. Not that we want to plug in that 80% of people will use, because then it would belong in Core, but 80% of the people that want that feature, the plugin should be relevant to them, right?

And so in the sense of imports being too large, the canonical plugin is a great tool and it’s the defacto recommended way, but it’s may not be the right tool for your instance. And so in that instance of a large import, WPCLI is probably more something that you would want to use in that case, because it’s not subject to timeouts and there’s just different technical boundaries that it works within.

So we want these canonical plugins to be the defacto, but they’re not the end all be all, and they don’t cover every situation. But we want to cover the majority of situations for as many WordPress users as we can.

[00:12:00] Nathan Wrigley: Okay. So I think we’ve established what a canonical plugin is, and I’m going to summarise it as follows, basically something that you can depend upon. I would summarise it just that.

[00:12:08] Jonathan Desrosiers: Something that tackles a specific, or group of features.

[00:12:10] Nathan Wrigley: Right. It’s got a specific feature. It could have gone into Core, but it was decided not to go into Core, but you can hopefully rely on it. Although, Joe made a very good point that, you know, reliance is an objective thing.

However, what we’re talking about today is accessibility. We’re in the year 2025. It’s June, 2025. We’re at WordCamp Europe. And it feels like the train over the last few years has really pushed accessibility to the front. I think any web designer, developer, in the year 2025 who doesn’t have accessibility right at the front of their mind is kind of missing the point.

The legislation in Europe is coming thick and fast, I imagine in other jurisdictions and other parts of the world, the same will be true. So I guess the question, and I’m going to ask this to Joe first, given his background of committing to Core in the accessibility arena. What do you make of this? The idea of pushing something to this canonical plugin that previously was the domain of Core.

Does it feel a bit like it’s, I don’t know, that the importance of it is being relegated in some way? Do you feel it’s like undermining? Because we should all have an accessible approach to WordPress development, website development, but in this way, well, it’s not important enough, if you like, to be in Core?

[00:13:30] Joe Dolson: So I think there’s a lot to unpack here. One of the first things I need to say is, first I’m going to, I have just a very slight quibble with your definition of a canonical plugin because there are kind of two different paths. There is the whole canonical plugin, which is intended to always stay outside of Core, but there’s also the canonical plugin, which is used for experimental progress.

And that’s something like the Performance Lab plugin, where it’s a whole bunch of different pieces, and they’re targeted for probably being merged into Core, and this is an experiment ground where we can figure out, is this really working? Is this the best way to do it? Is this suitable for Core? Maybe it should be different in the plugin than it is in Core. Like, for example, what was it that was just shipped? Speculative loading.

They used different rules in the plugin than they ultimately added to Core. It was just a less aggressive version of speculative loading. And I think that can be a very reasonable thing. And that can apply to accessibility too, as accessibility is a spectrum. We’re not talking necessarily about all accessibility is just, this is accessibility, it’s all required. Accessibility covers a gamut from, this is absolutely mandatory, basic level stuff, to this is pie in the sky. To even, basically there are some accessibility features that are literally contradictory to each other. In order to make something optimal for this population, you have to implement something that is actually not what this other population needs.

So there’s a lot of complexity there. The idea of putting accessibility into a plugin can lead to some very negative consequences. It is not necessarily inevitable. So there’s a lot of difficulty in just determining what is an accessibility plugin? What is it supposed to do? Is this something that’s supposed to change the front end? Is it supposed to change the back end? Is it implementing editor tools? Is it implementing new features? Is it fixing things that already exist? And I think all of those are complicated unanswered questions.

So kind of figuring out that path and, what is actually intended in this idea of an accessibility plugin? What are the problems it’s trying to solve? Is the first question mark. And we don’t really have that. That hasn’t been worked out in any way.

[00:15:44] Nathan Wrigley: So the complexity, and thank you for the clarification, the complexity there, the devil is in the detail. I guess Core in a sense is, if it’s going to ship in Core, it’s there. There’s a menu for this and a toggle for that, and a switch for this, and what have you. What you are saying is the landscape of accessibility is much more complicated than that. And so maybe, in a way, if it was pushed over to a canonical plugin, you could have a more a la carte approach to it. I don’t know if that’s where you were going.

[00:16:14] Joe Dolson: That’s conceivable. So, many years ago, Matt proposed the idea of an accessibility, it wasn’t a plugin at the time, but it was the concept of an alternate admin that would be a simplified admin. And, you know, I pushed back on that, and I still would if it was being marketed as an accessibility feature. There is a value to a simplified admin. It’s just that it can’t be considered accessibility focused unless it actually does achieve all goals. But simplification is in itself a goal. Making something easier to use, and having an option where somebody can do something in a simplified way, is extremely valuable.

[00:16:52] Jonathan Desrosiers: Yeah, just some thoughts to that. So I’m a Core committer and I make changes to the software that everybody uses and needs to be compliant, right? I’m not an accessibility expert by any means, but I’m versed in the concepts.

So one of the differences that could be in a canonical plugin for accessibility, Core, our coding standards for accessibility, we adhere to the web content accessibility guidelines, version 2.2 at Level AA, right?

But there’s different levels, there’s different versions of that. And so with different levels come different requirements, and different strictness to how you approach different interfaces. And so maybe a canonical plugin could allow you to adhere to different levels that perhaps your organisation needs to adhere to, that the 80% of users don’t necessarily need to.

Another thing that, I wanted to mention this because I always think of this. We, by default, think of accessibility as someone in a wheelchair or someone that’s blind, but you could break your hand, you could fall down the stairs, you could get eye surgery and have to wear a patch for a month. And so it’s not just permanent, it’s temporary disability as well. And I like to try to remind myself of that because you don’t need accessibility until you do, and then you’re glad it’s there when it’s there, right?

My grandfather was legally blind and he was a veteran. So he went to school and he learned how to use a computer. And he had a computer with like JAWS on it, and it would read it to him, and we’d send each other emails and stuff. I always like to think of him too, because if you know someone in your life that has accessibility needs, it also raises that importance to you as well. So, if I don’t do this in the right way, my grandfather won’t be able to use this website, or communicate with the world in the same way that I can.

And so finding those, I think that when you talk about accessibility, and this isn’t directly related to what you said, Joe, but I wanted to mention it. But if you can humanise it in some ways, in a way that’s in your life that you can relate to, it helps you find the reasoning in why it’s important, why these discussions are important, right? That we approach these problems in the right way, and that we meet the acceptable standard.

[00:18:57] Nathan Wrigley: In the end, this will be a binary decision. It either will be a canonical thing at some point in the future or it won’t, I guess maybe.

[00:19:05] Jonathan Desrosiers: Will it? I mean, we might merge some of it into Core or we might choose, it doesn’t fit in a plugin, right? And that’s kind of where that gray area is. And in some ways, canonical plugins take up a little more time because we are having these discussions. Like, we feel strongly this should go in, someone else may not. We have to work to get a consensus, and once we reach that consensus, we have to, I talk about this in my talk about how we make decisions, but we disagree and commit. And so you can state your disagreement, but then it’s important that we move forward together. Building that consensus and deciding on the right path, even if you disagree.

[00:19:39] Nathan Wrigley: Does the canonical option then, does that allow for more flexibility? So as an example, you could release, I don’t know, every two weeks, or every month or something like that. Whereas at the moment, we’re recording it in June, we don’t need to get into it, but we’ve got a different, a very different cadence for how often Core is being updated. Maybe that will change in the future, maybe not.

But with a canonical option, it would be possible to do any cadence you liked. And also, I suppose you could be a little bit more a la carte because you could have a variety of canonical plugins wrapped around the theme of accessibility. So, yeah, I guess what I’m asking there is really, does the cadence of a canonical plugin allow more flexibility?

[00:20:21] Jonathan Desrosiers: Absolutely. Whether we’re releasing once a month, or we’re releasing once a year, you can release a canonical plugin as often as you want, whereas Core has a much more predictable, well, not that the canonical plugin releases won’t be predictable, but it has a much more standardised schedule, I guess.

And so you could release once a week for your canonical plugin, and then if we have a Core release every three months, that’s 12 weeks, you have 12 releases of that canonical plugin that you could potentially refine issues. Whereas if you released it in the one Core release, you’d get all that feedback at once instead of dividing it up and making adjustments and going from there.

[00:21:00] Joe Dolson: So just to pose an example of something that I think actually is extremely suitable for an accessible plugin, and this is because, you know, I actually have written this. So let’s take for an example, the WordPress video block. It is extremely basic. It produces a video element and it gives you options to upload various tracks that are used in that video element. It is just the raw HTML 5. That’s what WordPress produces in the block editor.

Now, is it appropriate for WordPress Core to make a decision about how that video block is actually going to be rendered as it is with this raw HTML 5 element? It’s rendered differently by every browser. They have their own rules, their own way of doing it. That’s what it’s going to do. You can make it much more accessible, because there are a lot of things that those native blocks don’t support, the native video element doesn’t support.

In the past, WordPress did use MediaElement.js to render videos. And I actually think getting rid of that, and just using the raw video element was a good thing. But it’s not the most accessible way of viewing video. So is it something that we should do in Core? Should we dictate a player interface, or should we leave that raw in Core? Core just produces a video element, and then a plugin can enhance that to make it more accessible.

I’m also the lead developer for an accessible media player called Able Player. That’s a completely separate JavaScript project that has nothing to do with WordPress, but I have got a WordPress plugin for it, which basically just says, hey, here’s a video block, I’m going to re-render it using Able Player.

[00:22:37] Jonathan Desrosiers: I think if you want another good example of what a canonical plugin can be in the framework it can operate within, look at the Performance Lab plugin. The Performance Team has this plugin, and initially it had all these different features in it, and then we were trying to merge in support for the WebP image format in Core, and we realised it needed a little bit more time. And Matt suggested that we break them out into more finite plugins.

So the Performance Lab feature plugin has, or canonical plugin, has a framework and then there are sub plugins that you can install for modern image formats. Pre-loading the images, there’s an accessibility feature where it shows you the color, the dominant color of the image, and it’s there until the image loads. And so that way it’s visually represented. And so that’s another good example of that.

And one example that I’m wondering may be a good use of canonical plugins is the new AI Team. And so we’re at a point where we need to do some research and figure out what, in the context of WordPress, is needed for AI to flourish, and WordPress to be AI friendly. And I think that in some way, that will end up being a base foundation, some classes and some ways to interact with your content and your site, that can communicate with different models.

So perhaps some canonical plugins could be one for each of the popular models. And so you have this data transport layer that passes your site’s information to these plugins, and then it connects with ChatGPT, or whichever your preferred model is. And so within that you could have settings. The reason why I brought up the Performance Plugin is there’s settings within it. So for the modern image format, you could say, I only want WebP, or I only want JPEG XL or AVIF. You can decide which ones you want. But if that were to get into Core, that’s not the right thing to say like, I do or I don’t want this.

Another philosophy is decisions not options. We don’t want to overwhelm users with this. And a good example of this is, should this site be indexed by search engines? And if you disable that, it also disables your sitemap. And so making those intuitive decisions on behalf of the user and what they’ve done, the actions they’ve taken, we don’t want to overload them with options.

And so in canonical plugins, you can be more, you don’t have to follow that as strictly, because the point is that it’s a plugin that’s configurable, that we’re testing different things in different ways, and finding out what works for which groups of people, and in what ways, and gathering feedback around that.

Back to the point about, one other thing I wanted to mention too, is that one complaint I’ve always had with canonical plugins is that it’s very difficult to know about the experiences of the people using them. So for example, we had a plugin for a while that they want to, thankfully they want to rekindle it, is the Design Experiments plugin.

And you would install that, and there were, you know, at any given time, a couple of 2, 3, 4 different design experiments in the plugin. But we never knew who had which experiments active, which ones they disabled. Did they have bad experiences? And that’s why they turned it off. Did they like it? Did they prefer it?

We almost need to have some type of either AB testing within the plugins themselves, or a way to gather that feedback from the people that are using these canonical plugins. This is especially true when it’s a feature plugin that we may want to emerge into Core.

And so I did bring up to Matt in one of our recent meetings with the Core committers, and he was open to exploring the idea of better ways in canonical plugins to gather that feedback, because they’re now of a renewed importance in our community and how we foresee maintaining things.

We’re quite large, and we need to start saying no to more things in some ways. And so this is a great way to push it to a canonical plugin. Like, we don’t think that’s a right fit in Core, it’s too much, we can’t handle it. But create a community maintain plugin and we’re happy to stand behind it with you.

[00:26:32] Nathan Wrigley: I’m going to try and get this out. I’m not sure I’m going to encapsulate it right. I’m going to offer this one to Joe first. And that is the legislation in the landscape of 2025. And we know that in Europe in particular, a lot of this stuff is mandated. Obviously there’s degrees to that, but there’s a lot of mandatory stuff coming down very, very soon.

Given that, putting things into a canonical plugin where you can pick and choose, I have not installed that, I have installed that, what are your feelings about that? Is there some, I’m going to use the word core, set of features around accessibility that really where we’re at now, there’s just no choice, it just has to be in Core?

Because the concern that I have perhaps is, how will you discover this canonical plugin? How will it surface itself? The three of us will find it, because this is what we do. But the regular user who’s just got a brick and mortar store, they want to put a WooCommerce site out there, just something quick and easy, where are they going to even find out about these canonical plugins?

[00:27:32] Joe Dolson: And I do think this is a big part of what comes down to that question of, what does the accessibility plugin, what does it do? Because that is where things can really go kind of horribly wrong.

When we’re talking about the accessibility of existing WordPress interfaces, how you actually interact with the admin, I don’t think there’s anything there that should ever be in a plugin because the Core code has to be accessible.

You know, Jonathan mentioned that we’ve got this commitment to WCAG 2.2 at Level AA. I would say that we haven’t quite achieved that. It’s a goal, but I mean, the reality is there’s still a lot of legacy interfaces that our, I find new things every day. It’s just the reality. But those need to be fixed in Core. They should not be part of a plugin.

So, a plugin should be something that enhances something in a meaningful way that perhaps doesn’t apply to all situations. That’s one of the reasons I brought up the video element, because one of the interesting exceptions in WCAG is that you are not responsible for the accessibility of browser defaults. The browser is responsible for that.

And so if you are using a video block, and it’s just the video element, that is actually something that should pass. It’s not necessarily accessible, that’s up to the browser, but it’s not the responsibility of your site. And that’s a really fuzzy area from the law because, yes, you should still fix it.

[00:29:00] Nathan Wrigley: Imagine a scenario where we have a canonical plugin for accessibility. So we have WordPress Core, and then a canonical plugin for accessibility. WordPress Core is evolving all the time. No doubt missteps will be made. People like you, Joe, will be going in and saying, okay, this needs to be adapted, this needs to be amended.

And then on top of that, we’ve also got this complete other path of developing the canonical plugin side of things. There’s two strains of work happening now. So that’s just interesting. I don’t know whether that’s good or bad.

[00:29:30] Joe Dolson: So one thing I will say is, you know, the bulk of the new development in WordPress is in Gutenberg. There’s no need for a canonical plugin to handle accessibility things in Gutenberg because honestly, that should just go into the plugin Gutenberg. If there’s something in Core that needs to be fixed, you should be able to install Gutenberg and be able to move forward. I think that would be reasonable. I don’t think that’s a practical path to have a separate accessibility canonical plugin that fixes issues in Gutenberg problems for Core. I mean, I can’t see that as making any sense.

[00:30:04] Jonathan Desrosiers: In some ways we have to just weigh the benefits with the effectiveness and the time and the resources available. Some other ways that you can find canonical plugins, when you click add plugin on your site, there’s different tabs at the top, like featured, popular. One of them is featured, and so that is one that when we have canonical plugins, we want people to adopt or use, we add plugins to that tab.

So the performance plugin is there, Gutenberg is there because we want people to be testing those up and coming changes. To the point of the, we’re not being fully compliant with that standard, it’s, we have to remember that this constant churn going on with a code, right? There’s new code coming in, there’s old code being removed. And so in a way the goal line is still the same, but we’re getting peaks and valleys that we have to, they suddenly appear and we have to tackle them as we go.

I think for discoverability, it depends on the ecosystem in some ways. For example, as an American, you know, I’m not always, sometimes I hear of new legislations from EU and I say, oh, what are they up to now, right? It’s more things I have to do to follow the rules. But I think about maybe an American business owner, or American site owner, and sometimes it’s not clear. What happens if I’m in Europe and then I visit my site when I’m traveling, right? Does that open me up for legal action. If someone happens, if I make a very specific or rare type of trinket, and people in the EU find it, does that open me up to legal problems?

And so these are things that the normal site owner, I just want a website, I just write on it, right? They don’t think about this stuff. And so, in addition to being compliant with these guidelines that we strive to achieve, we need to think about those decisions, not options type things.

Another philosophy is to be simple, strive for simplicity. Most people don’t know what an XML sitemap specification is, or how to implement it, or what should go in it. And so we just make the decision to handle that stuff on their behalf. And if they need to, they can install a plugin to customise it, right?

So the same is kind of true in this sense. And if the world is susceptible to, or responsible for adhering to certain things, and we can reasonably help them without them having to find certain things to install or configure, then maybe it’s the right thing to put that thing into Core, right?

Perhaps it falls on the shoulders of hosts, where if the customer has an EU address, they install the accessibility canonical plugin, depending on what’s in it and what’s not. It’s likely not. We should be deliberate about what goes in Core and what goes into the accessibility plugin and for what reasons. But we also should be conscious that, as a community, we have to also help these non-technical users by making decisions for them when we know that it’s a problem.

Like, our legal team says, yep, any site that potentially gets EU traffic, they have to have this, or they have to block EU or whatever it is. We can outline these situations and make the best decisions for our customers and our users, given those criteria that we are aware of.

[00:33:07] Joe Dolson: It’s interesting you say that because one of the things you particularly dove into there is the idea of an accessibility plugin being something for the front end. And that is something that is actually fundamentally challenging. Because when it comes right down to it, we don’t know what’s on the front end. And accessibility is an incredibly difficult problem to solve when you’re kind of just trying to do automation on something that you don’t know.

You know, there’s a lot of accessibility plugins out there that are already doing that sort of thing. Overlay plugins. They are famously iffy, because they really don’t solve most of the problems. And some of them actually introduce more. And that is the thing that I most want to avoid, is that we create our canonical plugin and it’s just screwing up people’s websites.

[00:33:59] Jonathan Desrosiers: We’ve all installed a plugin that has way too many options, way too many features, and it doesn’t do any of them well, right? That’s not what a canonical plugin should be. In instances where there are many features, like the Performance Lab, there’s a framework perhaps, and then there’s sub plugins that do it, right? We don’t have an importer plugin that has every importer in the same plugin. They’re in specific plugins so that it can be more targeted, more focused on that specific outlined goal or focus area.

And so that, yeah, that speaks to me, because we definitely don’t want to mimic some of the plugins that are out there where they try to adhere to cookie laws, and then they also try to adhere to popups and, you know, Consent API and all that type of stuff. And so we want to make sure that we’re dividing those problems up into meaningful chunks, but chunks that we can manage reasonably and not be a runaway train in some ways.

[00:34:47] Nathan Wrigley: I was thinking about this last night and I was thinking, why does this conversation matter to me so much? And it came down to the fact that if we were having this conversation about a canonical plugin for, let’s say, performance or SEO, it would be intriguing, but there’s no moral component to it. You’re just serving a bunch of people who would like a more performant website. Well, that’s great. That will increase your SEO. No doubt, more traffic will come to your website.

But there is a moral component here, and there are people whose lives will be immeasurably better if WordPress is, and I’m doing air quotes, accessible. And so that just makes this whole thing so much more important and impactful. So there’s no question there, it’s just an observation.

There’s a different wrinkle here. There’s just some other thing. You know, you can imagine the panoply of different people trying to use websites. The frustration, the endless frustration that’s being caused by things because they’re not configured in a way that they can use them. And it would be a shame to miss this opportunity. And I don’t know what the right answer is here. I just know that there’s this moral component that makes this much more of a hot button topic than anything else. So that’s my piece, but if you want to respond to that.

[00:36:03] Jonathan Desrosiers: I just left the keynote this morning by Noel Tock, and he spoke a lot about the impact. I try to illustrate this often, and he did a much better job than I’ve done before. He’s involved with a lot of organisations in the war affected Ukraine. And so he covered a half dozen organisations that are saving lives, rescuing animals, providing humanitarian relief, and they run on WordPress. And so accessibility lends to that in some ways, because you don’t know where a group is that has a need, and the free software could help them with that need, and in what ways and what impact that could have on them.

Sometimes I think about how certain things overlap. And so I picture two circles, one for accessibility, and if you were to make a diagram of how it overlaps with democratising publishing. In many ways, it almost completely overlaps that circle. There’s something democratising with being accessible. I mean, it’s in the name, it’s accessible to as many people as possible. And so I think that, whether you know it or not, that probably in some ways is eliciting that feeling, right, of we all believe in this project where we all want to do good in the world. We want our software, and our community, to have an impact. And in many ways, accessibility leads to that mission that we all have.

[00:37:26] Joe Dolson: And I do want to say that, as it stands right now, when we’re talking about the admin of WordPress, it’s already one of the most accessible content management systems out there. We have done very good work there.

The front end is kind of a completely different story, and that ultimately is the fact that Core doesn’t control very much of front end, which is both one of the incredible powers of WordPress. It’s got this amazing degree of flexibility, and you can do almost anything with it. And it’s also one of the curses, because if we want to globally make the front end of everybody’s website better, there is very little we can do.

That’s where I kind of feel like our accessibility efforts most are needed right now is just kind of getting plugin developers, getting theme developers, to be better. Make better choices and provide better options in their tools.

[00:38:18] Jonathan Desrosiers: It is true that we don’t control the front end, but one of the features I love in Gutenberg is when you’re selecting the text colour and the background colour of a block. If you select light blue and dark blue, it says, hey, this is not accessible, it doesn’t meet the guidelines. People are going to have a hard time reading this.

I often think about ways that maybe, one I had suggested before which hasn’t been implemented yet, some issues take many years to flesh out and be adopted, if at all. But one of them is perhaps we do another notice like that when someone is entering an alternate text for their image. You know, maybe they just put jpeg 123, right? That’s not what alt text is meant for. It’s meant to describe what’s in the picture in case someone can’t see it, or it’s not visible.

And so it should be, Nathan Wrigley holding his microphone, sitting at a table, talking to Jonathan and Joe, who also have a microphone. Stuff like that. He’s got a red shirt. Things that illustrate what’s in the image. And so what are opportunities that we can take to guide our users to produce better content on the front ends?

And I think there’s a particularly large opportunity for that in block themes, because the nature of block themes is very structured. It starts with a theme.json file, and it’s gobbledegook for a lot of people. They don’t understand what the JSON is, how to read it. But it’s structured data that’s extrapolated into the editor to apply the default margin for your blocks. To apply the default labels, the colours, all those different things that are configurable in a block theme.

And so like, what’s missing from that that we can add that will lend to better visual representations of your content? There’s the HTML API behind the scenes that manipulates HTML strings in the context of WordPress. So how can we make sure that we’re generating accessible markup, those building blocks?

A lot of times we run into issues where there’s no good solution for a specific accessibility problem because the foundational elements, were not taking that into consideration when it was built. And so oftentimes it’s hard to get backing for those changes, because it’s such a big undertaking because it wasn’t a part of the the initial discussion and consideration.

And so how can we replace these over time, but also as we build new things, take those things into consideration so that the things that get expanded into the user experience and exposed in the site editor, result in better front end experiences for everyone, that are more accessible?

[00:40:50] Joe Dolson: Yeah, I think that’s a really great thing to call out is those places in the authoring process where we provide accessibility feedback. There’s a whole set of guidelines that are specific to that. That’s the Authoring Tool Accessibility Guidelines. And I love everything we do to try and implement those.

I will say that the colour contrast one, it was implemented very, very early on. There are a number of things that are in Core now that it actually just isn’t able to handle. Some layering things that it’s just like, oh, I don’t know what’s going on here. So that needs work. But that’s just kind of the constant process. At least it does exist and it can cover a lot of the most common use cases.

But, yeah, that alt text one, that’s also a really valuable thing to be able to have some checks on. It’s a hard thing, and I think one precursor change we actually need to be able to make that possible is we need to make some revisions to how alt text is stored in the database.

Because the reality is, right now WordPress stores alt text as a meta field that’s tied to the attachment, tied to the image. But alt text actually is context sensitive. And so really there shouldn’t be one canonical alt text for an image. There could be a canonical description of that image, but the alt text itself should always be context sensitive.

On the other hand, if we just removed that field and didn’t save it, which is something that the block editor has kind of taken that path, when you change it in the block editor, it does not save to the media library, that’s also flawed, because sometimes you do actually want to use that, or at least want to use it as the basis for the next version of that alt text you write. So what I’d like to see is that we could actually save multiple alt text fields and have that managed.

[00:42:33] Jonathan Desrosiers: There’s all these great ideas, and great things, but we also need to strive for simplicity. We don’t want them overwhelmed with a hundred different accessibility notices of how they could improve to the point where they say, I’m going to somewhere else, this website’s too confusing.

This is potentially also another opportunity for AI. Perhaps AI could be used to suggest what accessible alt text should be in the context of the article you’re writing, or the page you’re authoring. You know, maybe AI can be trained in a way to audit your page for accessibility and make suggestions.

AI is really exciting. I often sit back and watch and just observe because there’s so many models and you never know which ones to use. And unless you’re really deeply involved, it’s hard to know the best model for certain tasks.

But I definitely like to think about, it’s helped me be more organised for sure. I have a hard time sometimes when I am creating a talk, getting my thoughts into an organised deck. And so by putting all my thoughts into AI, I’m able to better organise it and then I can drop my notes and my thoughts in the structured outline that it kind of organises for me, right?

But, in what ways can that be applied in the editing process within WordPress under the lens of accessibility? And we could have SEO, we could have, Yoast has a lot of SEO tools that makes SEO recommendations. And we could have our canonical plugin perhaps has an AI interface and we go from there.

So, yeah, there’s many different ways we can tackle these accessibility issues. It’s exciting to have these types of discussions and consider what could be.

[00:44:05] Nathan Wrigley: Sadly, I think time is going to get the better of us. But I would like to say thank you, both of you, for your intelligent commentary on this. I don’t know which way it’ll go.

[00:44:15] Jonathan Desrosiers: And there’s no right way necessarily.

[00:44:16] Nathan Wrigley: That’s right. And it seems like there’s benefits in both possibilities. I’m not going to put you on the spot and ask you which your preferred one is. I have suspicions. Let’s keep this debate going I suppose. Let’s see which way it falls out. And, yeah, Joe and Jonathan, thank you so much for chatting to me today.

[00:44:33] Jonathan Desrosiers: Of course. Perhaps we could do like a six month check-in on the state of canonical plugins.

[00:44:38] Joe Dolson: Yeah, it’ll be interesting to see what happens next. Thanks so much.

[00:44:40] Nathan Wrigley: I honestly think that we could have gone in a hundred different directions here. I think there’s bits of this podcast, which we could have opened up and probably spoken for many, many more hours. But, yeah, thank you both.