[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.

[00:00:00] 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 the challenges of creating accessible websites with WordPress.

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 Elena Brescacin. Elena is an accessibility consultant from Italy who has been blind since birth, and working online since 2000 with Tangity Design a part of NTT Data Company.

Her journey with WordPress began in 2021, but she has been aware of it since 2003. A computer geek, Elena enjoys finding solutions to everyday challenges through technology.

Elena is here to discuss the significant accessibility advancements and challenges within WordPress, especially with the transition from the Classic Editor to the Block Editor. She shares how full site editing has empowered her to manage most of her site content and structure without needing constant visual assistance, despite some areas needing further improvement.

We talk about her experiences navigating the internet using screen reader software, the importance of adhering to HTML semantics for accessibility, and her involvement in the WordPress community, including her contributions to the Italian Polyglots, and speaking at WordPress events.

Elena also reflects on the evolution of the internet, personal experiences with various web accessibility tools, and her advocacy work in digital spaces. We get into real world challenges, such as inaccessible event venues, and the advantages of online events for better accessibility.

Elena shares her frustrations and triumphs in web accessibility, her insights on the impact of proper semantic web design, and her continued efforts to raise awareness and support a more inclusive internet.

If you’re curious about web accessibility, particularly how WordPress is used to create content, 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 Elena Brescacin.

I am joined on the podcast today by Elena Brescacin. Hello, Elena.

[00:03:28] Elena Brescacin: Hello. Thank you for having me as a guest.

[00:03:32] Nathan Wrigley: You are so welcome. I have to say, massive apologies to Elena, and we’ll get onto this in a moment. Elena has been more gracious than you can imagine.

We have tried multiple times to get this podcast recorded. And apart from this one time, more or less everything that we’ve tried has failed. And as I said, we’ll discover why that is in a moment. But firstly, my sincere thanks for sticking with me, despite the frustrating nature of it, seemingly being happy to carry on the endeavor. So I’m very grateful. Thank you so much.

Okay, so the endeavor today is to talk about your journey with WordPress, we’re going to land there in the end. But before we get into that, would you just give us a little bit of your potted bio, and hopefully that’ll paint a picture of what we’re going to talk about today. But just tell us a little bit about yourself, what you have done in the past. Maybe go back right to the beginning of all that. And then, yeah, just let us know what it is that you’re doing currently.

[00:04:29] Elena Brescacin: I am an accessibility consultant. I am blind, I have been blind since birth. I’m from Italy. I work online since 2000. 2002 I started working officially, and I work for the same company. It has changed names many times, but now it’s called Tangity Design. It’s part of NTT Data Company. It’s a Japanese multi-country company.

Currently I am working so much time with AI and with accessibility of websites and mobile apps. And of course, I’m involved into the Fediverse because I find that it’s the future of communication right now. I have no WordPress in 2003, but I started using it in 2021.

[00:05:26] Nathan Wrigley: Thank you very much. So earlier in your bio just then, you said that you had been blind from birth. Now I’m not entirely sure what the spectrum of that word means, but my understanding is that the word blind can be different things to different people. But in your case, is it fair to say that you are entirely blind, you have no sight at all, or do you have impaired vision?

[00:05:49] Elena Brescacin: No, no, no, I am totally blind. I don’t see anything.

[00:05:53] Nathan Wrigley: And clearly on a podcast like this, where we’re talking about WordPress, this is going to play into the conversation a lot. Is it the sort of blind nature of things that you are doing your accessibility work in? Are you helping people online, particularly WordPress website builders and app builders and things like that? Do they come to you with a requirement to understand how their interface, how their website is working, and you give them kind of an appraisal of, this works, this doesn’t work, you need to look at this and so on?

[00:06:22] Elena Brescacin: Yes, it happens. This is part of my job. I also teach to some customers when they have no idea of what accessibility is.

I have had many speeches for accessibility. I participated to TEDx in 2015. I did not use WordPress then. And I had the WordPress Accessibility Day in 2024. I have spoken in two WordCamps. Italy, WordCamp 2021, and Verona WordCamp 2023. Unfortunately, the speeches are in Italian. Accessibility is in English, WordPress Accessibility Day is in English. The speech is called the Same Editor, Same Language. It talks about Gutenberg. And I also participated to Core Days, WordPress Core Days in 2024, last November in Rome. And I presented my experience with multilingual website based on Gutenberg.

[00:07:29] Nathan Wrigley: Thank you very much. Now, it feels to me that if you’ve been working online, and I think you mentioned 2003 possibly as one of the earlier dates that you mentioned in your biography. Would it be true to say that at the beginning of the internet, so when we were all just getting online, and it was dial up modems and what have you. I was using the internet from a fairly early date, and it feels to me as if the internet might have been a more hospitable place for somebody who is blind back then.

Because my recollection of the internet back then was that really it was just text. There was text and there were underlying text links. There was very little in the way of imagery, but it was primarily text. We certainly didn’t have video, we didn’t have complicated platforms to publish things online.

Has the internet basically become more challenging over the previous two decades for somebody like you to navigate around? I’m not talking there about the ability to create content, I’m just talking about the ability to consume content. Is the internet more noisy, more difficult to navigate around now than it used to be, let’s say 20 years ago?

[00:08:42] Elena Brescacin: Oh, well, it depends on what you want to see, because you had much text-based content then, it’s true. But obstacles began into 1999 with the first visual captcha, the anti-spam, anti-bot control based on visual text. Copy this text into a box. If you are a human you can see, otherwise you are cut off.

[00:09:15] Nathan Wrigley: I know exactly what you mean. So it was those early captchas where you had to be able to see a particular thing. And if you could see it, it was fairly straightforward to carry on. And we all know what captchas are. We see them still, often it’s click on pictures of, I don’t know, cars or something like that. And without that pass, if you like, you are stifled, aren’t you? You can’t then go on to do whatever it is. It may be log into a platform, what have you. So that was your first experience, was it? Captchas was the first time the internet became something which you could no longer do. Suddenly there was a barrier which hadn’t existed before.

[00:09:49] Elena Brescacin: It has started to become common after 1999. The first to implement was Yahoo, Yahoo Groups. Then it came on Google, it came everywhere.

Now I have also another platform that concerns money. Some benefits of a service I have joined, they give a benefit, yearly benefit. And they have a captcha, a visual captcha on login, a visual captcha to change the password, a visual captcha for if you forget the password. I must ask for help every time I have to access that service.

[00:10:29] Nathan Wrigley: So the internet in that regard is an entirely frustrating experience. I’m sure that we’ll get into slightly more positive things.

But I want to spend a moment just discussing what it is that you do when you browse the internet. I mean, clearly it’s obvious to you what you do, but it may be that the listeners to this podcast, because we have a very wide listenership, and some of them are very experienced, they no doubt think about accessibility for their websites all the time. But there’s bound to be other people who really don’t know what it is that somebody like you is doing on a day-to-day basis to navigate the internet.

So can we just describe what it is that you are doing. When you are sat at your computer now, and we could talk about different devices like phones or whatever as well, but let’s just begin with a computer, a desktop computer. How is it that you are able to navigate the internet without being able to see what’s on a screen, how does it work?

[00:11:25] Elena Brescacin: So I do not have a mouse, I do not use a mouse. I have a keyboard, standard keyboard every person has at home. I used the computer since 1989. I was less than 10 years old, and I was nine, almost 10 years old. And I learned to use the keyboard to get confident with the keyboard. But computers now have some software. Some are expensive, some are free. They are called the screen readers. I currently use the paid one. It’s called Jaws for Windows, acronym for Job Access With Speech.

[00:12:06] Nathan Wrigley: We will add that into the show notes so that everybody can find that, thank you. Yeah, sorry, keep going, I interrupted.

[00:12:11] Elena Brescacin: It’s a software that renders by voice, or by braille device. There is a hardware device called Braille Display, which is for braillists like me, otherwise they use speech. I use, of course, I use a Windows machine.

Another open source software is called NVDA. It’s for Windows, Non-visual Desktop Access. I use those softwares on the computer, on Windows.

On Macintosh, I have also a Macintosh, but I use it rarely because it’s old, it’s about 10 years old. The screen reader there is called Voiceover, the same that is in my main mobile device, my iPhone.

And unfortunately the open source field, I’ve talked about Linux, it’s less careful to accessibility. There are some users, brave users that use that kind of system, but I find it less immediate, less straight forward. Let’s say I have to work, I have to have smooth work, not to go and check if everything works before working. Do you understand me?

[00:13:27] Nathan Wrigley: I fully understand. I think most people who have had experience with Windows, Mac, and Linux, I think there’s a certain level of dedication, shall we say, which is required to keep going with Linux. Some people have it, and other people don’t. But it sounds like it’s the same for you as it would be for somebody who has sight, only a different set of problems no doubt.

Now, when I go to a website, let’s say for example I visit, I don’t know, in my case the BBC website, which is a news organisation in the UK. And they present lots of written content, and lots of video content, and lots of images and so on. When I’m looking at that, I navigate my way around by capturing what comes into my eyes, and I decide what I want to look at based upon the prompts, text or what have you. And then I find the link and what have you.

It would occur to me that many people would imagine that you, as a screen reader user, are browsing the same way that I am. In other words, you are looking somehow at the same screen that I am.

But that’s not true, is it? Because you are kind of in a way navigating the HTML. And the way that the website has been constructed on the backend is much more important than it would be for me.

So for example, a font size of something enormous screams title just because it’s big. But in your case, the bigness of the text doesn’t say anything about its titleness if you like. And this same thing maps out in every single part of the website.

So can you just give us an idea of what it is that you have to go through, let’s say when you end up at a website like the BBC. What are you actually doing with the keyboard, and how are you getting information about what it is that you want to get to? Or how are you not getting information about what it is that you want to get to? So the frustrations as well as how it ought to be done.

[00:15:21] Elena Brescacin: Oh, well, you said about the big text saying title. I look for, if I have to read a piece of news, not the list of news, but the single article of news to search for the news. I look for the heading level one. It’s an HTML code called heading.

There are six levels of headings. Heading level one is the most important, the most evident, it’s the title. If I have to search for a new site, a brand new site, I usually search for the main menu, a navigation menu. HTML has a semantic, it’s called semantic. The layout is associated to specific code.

You know that if it has four legs, a tail, it can be an animal. The website, the concept is very, very restricted because navigation menu is a type of code. And often developers and designers create visually with graphics what should be created by code. So screen readers do not detect information correctly.

So with the example of before, the animal, it has four legs, a tail, but it’s a cylindrical chair. Sighted people always protest when I say your product is not tested for accessibility, and a website rather than mobile app, or a physical product and so on.

Then if I create some content, an article, a text, a word document, whatever else, they always protest. Sighted people protest because I have not checked the formatting, the text is too small, or too big, or I have no color, and I say, why should you protest? If I have no sighted person testing my product before I deploy it publicly, why should you protest if a sighted people have not tested my product, and why should I not protest being blind if your product is not tested by blind? It’s the same, the same frustration, but they don’t understand.

[00:17:59] Nathan Wrigley: Yeah, so with your screen reader you are going through and you are hoping to find cues inside the code of the website, for want of a better word. Let’s just say it like that. You’re hoping to find the H1s, which will indicate, this is a title, you’re hoping to find the H2s, which indicate this is a subheading if you like. And then, you know, H3 is under that, and H4 is under that, and all of that working out in a logical structure. So this semantic nature of everything.

[00:18:24] Elena Brescacin: Sequential.

[00:18:25] Nathan Wrigley: Yeah, sequential. And my guess is that when you are browsing the web, this is very rarely the case. I’m going to ask you a question, it’s putting you on the spot a little bit. But if you had to put a percentage, so one through to a hundred, a percentage on how frequently you encounter a website which you can completely use without a great deal of effort. So it’s built exactly how you would expect it to be, how you would wish it to be. As a percentage, how often does that happen? If you were to visit a hundred websites, how many of them would satisfy you from an accessibility point of view?

[00:19:02] Elena Brescacin: Oh my god. Could I say 20, 30%? But the percentage would increase if, for example, some news websites, many of them are even based on WordPress, but the problem itself is not WordPress or the CMS, it’s the many, many, many advertising that they put inside. Moving advertising, moving sliders. Images without labels, or buttons without labels.

I had a very, very high frustration last week because Nathan was trying to interview me with a platform called SquadCast, but it did not give me the control for the microphone, the speakers, the headphones. It was labeled related to chat, help leave the call and so on, but not the setting of microphone. So no one could hear each other.

[00:20:03] Nathan Wrigley: It was a profoundly moving experience actually. And I say that in all of the wrong senses of the word, moving for all the wrong reasons. Because I have interviewed hundreds, possibly thousands of people at this point, but I don’t believe that I’ve ever interviewed anybody who has no sight. And so you are a first. And so honestly the guilt I’m feeling is fairly profound.

I sent you the link in order to open up the platform in the same way that I do every single time, and then there was just this wave of one frustration after another. And it never stopped, did it? It was just one problem, then another, then another.

There’s things that we were trying to set up like selecting the headphones to use, which is typically a one second exercise, and selecting the microphone that you wish to use. Again, it’s another fairly straightforward exercise if you use it in the way that I do. But we must have spent, what, half an hour, something like that, just hitting obstacle after obstacle. And it really did give me a profound sense of, well, this is just wrong.

Here we are trying to carry out a normal thing, I’m eating up your time, and you are eating into my time, and so there’s this sense of guilt in both directions that, well, we’re wasting each other’s time and what have you.

All the while the frustration is building for you because literally nothing that you were hoping to achieve was possible. And so that was the sort of apology at the beginning. We are recording it on another platform today, which thankfully has proven to be an awful lot easier. I’m sure in many respects it’s not perfect as well, but we seem to be having a little bit more luck but, again, describe that, this isn’t perfect either.

[00:21:41] Elena Brescacin: Yeah, not to speak about the calendar. When I talk about semantic, another good example should be table. The calendar Nathan has to book the podcasts has no table structure and no keyboard commands to select the dates. Overall you have no semantic, it’s just a visual. The time zone, which date can be selected. So for example, I was trying the 16th of December for the new reschedule of the interview, and it just gave me, sent me a calendar, the calendar invitation on 11th of December.

[00:22:27] Nathan Wrigley: The thing that I’m getting out of it is that the internet for me basically is a, how to describe this? The internet for me has usually been a place of joy. I go to it and everything, given the nature of what I have available to me, you know, my eyes function, my ears function, my arms and legs are all functioning, and I have a screen which is just at the right height for me and everything. Essentially everything in my scenario is working in the way that I would hope. And so the internet is this thing of joy. I go there and I can consume film, I can consume audio, I can write blog posts, I can take part in podcast interviews. It’s wonderful.

But I’m getting the impression that for somebody such as you, the internet is possibly anything other than joyful. I mean, maybe it is in some regards joyful, and that there’s no doubt moments where you’re profoundly moved by it, and it is wonderful. But I’m guessing also that it is also seriously annoying. It’s almost like you have to go the extra mile again, and again, and again, and again to do basic things.

And as we move more of ordinary life online, banking goes online. Booking things that you want to be delivered to your house goes online. The government, paying tax goes online. If it’s not set up for you, you are really being penalised for the way that the world is moving. And that must be frustrating and let all of that out if you want to, you know, is it a frustrating experience, the internet for you?

[00:23:55] Elena Brescacin: I think that internet was given the wrong dimension, make it more utopia than it really is. Because let’s remember that internet is made by humans. So if humans do not pay attention to other humans, the issue is the same you can find in the street outside. It’s not something worse than real world.

It can be amplified if you have, for example, social networks hate speech. I sometimes ask people to describe photos for me because they don’t. They publish a screenshot on their posts on social networks, a screenshot regarding conversation, regarding even politics and so on. But then I do not read the line because it’s a screenshot.

And if I asked, can you describe the photo for me? They just say something to me. What, are you stupid? Did you not understand? People like you should not come to the social network. If you are blind, how can you read, and can you write? They doubt my identity. And so not to talk about voting, voting elections. I have a person helping me. They come to the cabin with me, the room where we have to vote. They take a pencil and trace the sign to the right politician or whatever I say, but I have no proof. I have no proof if they have actually voted what I asked for.

[00:25:39] Nathan Wrigley: Gosh.

[00:25:40] Elena Brescacin: Yes, this is the reality.

[00:25:42] Nathan Wrigley: You sound much more buoyant about it. I was maybe anticipating the wrong thing in a sense there, but it sounds like you, rather than being, I don’t know, miserable about the failings of the internet for people who are blind, but it feels like you’ve gone in the other direction. That you’ve gone more in the, I want to make people aware that this is going on. So you are advising people when they don’t put alt tags on their social media posts. You’ve done that to me, which was really helpful, because I then know that that’s a requirement. And also, you’ve got yourself in the WordPress space and are educating people.

So I’m just keen to know what your posture is there. Is it going to be your mission in the future basically to be helpful and to fight the good fight about accessibility?

[00:26:28] Elena Brescacin: I try to help people and to help myself because just the frustration brings nowhere. If you just go on with frustration, it’s over. Online services give me a lot, for example, digital books, e-commerce and so on, online banking and so on. But if you do nothing for accessibility, you cannot expect others to do anything.

[00:26:57] Nathan Wrigley: Yeah, good point.

[00:26:58] Elena Brescacin: Overall, you cannot expect politician to do anything.

[00:27:03] Nathan Wrigley: In terms of WordPress, let’s just shift the conversation to WordPress now. We have the new, well, it’s not new anymore, we have the Block Editor, the Site Editor and what have you. And I’m going to link to a few bits and pieces in the show notes. So if you go to wptavern.com and you search for this episode, and it will be on the page there, we’ll add the links to all of the bits and pieces we’re about to discuss. You’ve written a few articles where you say that WordPress has basically made leaps and bounds, and it’s become an interface which is much better for you to use.

Now, let’s just rewind the clock like 10 years or more, when we had what is now the classic editor. What was it like as a content writer, a story writer, a blogger who was blind? What was it like back then, and how has it improved with the block editor?

[00:27:55] Elena Brescacin: So I have worked into the WordPress system. I knew it in 2003. My profile on wordpress.org is from 2005. And my activity in WordPress was very frustrating at the beginning, because I didn’t find very easily the controls on the classic editor. Strange, because many blind users I know are happy with the classic editor. For me, it’s different. Maybe it’s me, I don’t know. But when classic editor was the only one to use, I was using it in code mode. So I wrote HTML by hand. And in the end I abandoned the WordPress because it wasn’t so good.

But at that time, I was talking to the first Italian community manager, let’s say. He was called Paolo Valenti. And this guy was the first translator of WordPress. And he just said, remember you cannot leave WordPress totally, sooner or later you’ll come back. And he was right. This man, unfortunately, is no longer here. He died by cancer in 2022.

[00:29:19] Nathan Wrigley: So in the day when you were using the Classic Editor, and for many people listening to this podcast, that will be entirely familiar. But for those people who’ve joined in the last five, six years or so, it may be something that you haven’t dabbled with.

Yeah, you really did have to, in order to make the full use of it and to add things onto the page, it was possible to write some text and then highlight it, and then potentially, I don’t know, select that you wanted it to be a paragraph or what have you. In many ways it was more straightforward to write the HTML itself, wasn’t it? So you would write the P tag and what have you.

And this became an incredibly frustrating experience, which probably that kind of experience was the thing which promoted the idea of using a block-based approach where you drop the block in and you begin writing, and you can do the forward slash and select the kind of block that you want, and you’re off to the races.

So how is the block editor better than the classic editor? And obviously we know that some of your friends would disagree with that sentiment, but for you, why do you find it better? What does it do differently and better in your experience?

[00:30:23] Elena Brescacin: Because the block is an interface, basically it’s an interface, and it’s from the rules from WordPress Core, they say it’s accessible, second level accessibility guidelines. I do not enter into technical details now. But my opinion on Block Editor is because you can rapidly move blocks up and down with a key combination. You can even check the style, the colours and so on. That’s not my task.

But having to select a single block and work on that block without harming the other content. The possibility to add a block manually with the add block function or by markdown. I use markdown syntax for titles, for headings. Not links, but many other functions because I do not take my hands away from the keyboard, the letters.

[00:31:26] Nathan Wrigley: It hadn’t really occurred to me that the Block Editor kind of locks you into the block that you are currently working on in a way, doesn’t it? So you just said that you can’t kind of interfere with the other bits and pieces on a page unless you are editing within the confines of that block.

So if I’m in a paragraph block and I am writing, I’m in that paragraph. Whereas with the old Classic Editor, I was in all of the content, unless there was some plugin or something like that, that was going to inject something.

So an accidental keystroke could delete tons of content, including the markup that would’ve given that portion of the content some context. So, you know, it might have been the H1 tag. You could accidentally interfere with that, delete that somehow. Whereas all of that is then abstracted away inside the Block Editor, and it’s a selection you make, not a heading that you type. Although I suppose you could choose to do it that way. So that’s interesting. I hadn’t really thought about it like that. So it creates less mistakes, it’s easier to get started. And if you were to drop into somebody else’s piece of content, you’d be able to navigate your way around it more easily, right?

[00:32:31] Elena Brescacin: And even the templating system, the Full Site Editing has changed my point of view on templating, because before I had to hire someone for coding and so on.

Now, I have also hired a person for helping me with the styling, with graphics and so on. But this woman who has helped me, who spoke to the WordPress Accessibility Day with me, she has helped me with the styles, but was just teaching me the interface for what’s about the content and the structure of the site. It’s mine. Gloria just did the colours, and the size, and what visual, and what I cannot verify in person.

[00:33:20] Nathan Wrigley: Okay, so you were able to do the lion’s share as we describe it, the lion’s share of the work. And really the bit that, I think you said Gloria was doing there, Gloria was helping you just to have that appeal for somebody with sight. So she was sizing the text so that it looked appropriate on the page, but the majority of it you were able to do inside the Site Editor. Interacting with, what is what you get templates, as opposed to having to employ somebody to fiddle with template.php files and things like that.

[00:33:46] Elena Brescacin: Yes, she just helped me because she is a freelance web designer and WordPress trainer, and she has trained me on Full Site Editing. The good thing is that she has believed in me from the beginning.

When I supported another person in a Facebook group, she contacted me, and then we started the journey to WordCamps. I have spoken to a couple of WordCamps in Verona, and one is online. Those ones are in Italian. And I have also participated with Gloria in the WordPress Accessibility Day 2024.

[00:34:29] Nathan Wrigley: What does WordPress still have to get right? So although it sounds like you personally are very happy with the Block Editor and it’s brought a lot of benefits that you can make use of. I’m guessing that there’s an awful lot frustration still. What would be the things for the year 2025 that you would hope would be addressed? What are still some of the things which are frustrating about being, well, not just the Block Editor, being inside a WordPress site in general? But maybe the Block Editor is a good target to begin.

[00:35:00] Elena Brescacin: Oh, for example, a more targeted search block. Because now the search block, you have just the search field and button, it could be like that. But when you place that block in a navigation or somewhere, you should be able to choose where it can search. Because if you are, for example, I have my site talking about a real world and a fantasy world, I should be able to say, search for content just in the real world and just in the fantasy world.

So when they click in the menu, in the search box on the main fantasy world page, they just got content from that category or from that post type. In fact, I have created a multilingual, experimental, and very basic site by using just Gutenberg and template.

They should also give the possibility to duplicate a template. Because now, Gutenberg, you can duplicate post, duplicate page. But if you have, for example, I have Italian header and English header, I would like to be able to clone the Italian header and then translate the content inside.

[00:36:26] Nathan Wrigley: There’s always going to be things, isn’t there? Edge cases. It really hadn’t occurred to me that search being a front end thing was something that needed addressing. But it sounds like it does. But what about the sort of backend of things, if you like?

[00:36:36] Elena Brescacin: The search block I mean is a backend thing that you can set up from the template. You can set up the block, the interface of the block in the block settings. That I mean.

[00:36:49] Nathan Wrigley: How do you feel about the importance that’s given to the direction the project in terms of accessibility? Do you feel it gets the attention it deserves?

In an ideal world it would obviously, every single thing about the WordPress project, the community, the code, everything would have accessibility front and centre. But we don’t live in that perfect world. We live in the world where we have the constraints on time, and the project has to move in certain directions, and maybe accessibility falls off for one of the releases and what have you.

But how do you feel, as a whole, WordPress does? Do you feel it is at the forefront? Do you think it’s lagging behind other platforms that you may have played with?

[00:37:28] Elena Brescacin: WordPress for now is the best CMS for accessibility in backend with its Full Site Editing. But I think it has to become more consistent. Accessibility team should get more people inside I think for testing, for coders, skilled coders. Because I feel that it’s, not being neglected willingly, but because few people are working in that. This is my feeling.

[00:38:02] Nathan Wrigley: Do you involve yourself in those communities? And if you do, are you able to tell us where you might go if having listened to this podcast, you think, actually, do you know what, that would be something I’d like to spend some of my time on.

So just drop some of the names of the, I don’t know, Slack channels or other places online that you go when you want to discuss WordPress accessibility.

[00:38:25] Elena Brescacin: I mostly go to the GitHub platform of specific project. Let’s talk about ActivityPub, let’s talk about single plugins accessibility.

There is the Slack channel in Make WordPress Slack. But I do not participate often into Slack because unfortunately at work I have not that time. So it happens that I miss discussions. Sometimes I have helped the Polyglots in the Italian community, Polyglot, to translate WordPress.

[00:39:04] Nathan Wrigley: It also sounds like you’ve been involved in real world events, plus some online events as well. I think you mentioned WordCamps that you’d attended as well, and I was wondering from an accessibility point how they have been.

But also you mentioned the WP Accessibility Day as well. Do you just want to mention your participation in those? Let’s start with WordPress events. How have they been from your perspective?

[00:39:27] Elena Brescacin: Accessibility, unfortunately it’s very difficult. Real world events are very difficult for accessibility because I need a person helping me to move through location, the WordCamp locations. It’s quite difficult without help.

There are many information that are conveyed by colours. The black signal is the track one, the white is track two, for example, and so on, or you have the locations. There are no, not many explanation. I must ask for help to move across tables on the contributor days. Now I am trying to apply to WordCamp Europe 2025. I don’t know how it goes.

I went to the WordCamp 2023 and to WordPress Core Day 2024. I got help from people there, but I had a person assisting me because otherwise I could not manage to go to the WordCamp alone. But the WordPress Accessibility Day was online.

[00:40:38] Nathan Wrigley: So that was a more straightforward undertaking.

[00:40:40] Elena Brescacin: Yes. But let me say that in-person events are more useful for networking. You get to know people, you get to talk to people, you get to confront. In few words, you get to exist, because otherwise you are a voice, you’re a face, you’re nothing else.

[00:40:59] Nathan Wrigley: Who are some of the people online in the WordPress space that you hang out with, who you communicate with? Do you want to just name drop a few people that it might be interesting for me to add into the show notes, so that people can follow them as well as you on maybe social media or something.

[00:41:14] Elena Brescacin: I think you know Michelle Frechette. Matthias Pfefferle from ActivityPub. Yes, you know him because you just interviewed him. I knew about your event because I was following him and I got you to the Mastodon network.

[00:41:31] Nathan Wrigley: Excellent. I’ll put some of those links into the show notes so people can follow them as well. But more importantly, Elena, where would people, if people have been listening to this and thought that they’d like to communicate with you and get your thoughts on the state of WordPress in terms of accessibility, where would we find you? Where’s the place where you hang out most frequently? I think you said Mastodon.

[00:41:50] Elena Brescacin: On Mastodon and on LinkedIn.

[00:41:53] Nathan Wrigley: Perfect. I will find the links for both of those and I will add them to the show notes. Anything else that we have mentioned today will also be in the show notes. Head to wptavern.com. Search for the podcast section, and within that search for Elena’s podcast. And from there you’ll be able to delve inside the show notes, and get a faithful transcription of everything that we said today as well, I hope.

So all that it remains for me to do is to say, Elena Brescacin, thank you so much for chatting to me today. I really appreciate it.

[00:42:23] Elena Brescacin: Okay.