Talk about the intersection of open source software and business, rapid security response amid AI advancements, the importance of fundamentals in AI implementation, and concise content creation for engaging media.
#226 – Jessica Lyschik on Why Accessibility in WordPress Themes Is Easier Than You Think
Transcript
[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, why accessibility in WordPress themes is easier than you think.
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 Jessica Lyschik. Jessica is a longtime member of the WordPress community who’s been working in the ecosystem since 2015. She’s spent years learning and advocating for web accessibility, both as a developer and as an active community participant, joining agencies, working on theme reviews, and helping improve standards.
Many theme creators assume that making themes accessible is an intimidating task, but Jessica’s here to show you that achieving an accessibility ready WordPress theme is more straightforward than you might imagine.
Her WordCamp Europe 2026 presentation, accessibility in themes, easier than you think, aimed to demystify the requirements for accessible themes. Explaining what the WordPress guidelines mean in practise, where the low hanging fruit is, and how both block and classic themes can reach accessibility ready status with manageable efforts.
We talk about the personal and moral journey that brings developers to accessibility. The technical hurdles and documentation challenges, and the ways in which things like AI agents are putting accessibility in the spotlight for everyone.
Jessica talks about practical steps that quickly improve accessibility, like using correct HTML tags, adding alternative text to images, and configuring skip to content links, and shares why building accessibility in from the start saves time and effort down the road.
We also explore the differences, and possible advantages, of block themes when it comes to accessibility, and why theme guidelines work the way they do, and the importance of interdisciplinary awareness across SEO, design, and content teams.
Jessica mentions helpful resources, influential leaders in accessibility, and the ongoing need for documentation improvements to help everyone level up.
If you’ve ever felt overwhelmed by accessibility requirements, or wonder why they matter, and how you can build better WordPress sites that work for everyone, 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 Jessica Lyschik.
I am joined on the podcast by Jessica Lyschik. Hello, Jessica.
[00:03:39] Jessica Lyschik: Hi Nathan.
[00:03:41] Nathan Wrigley: Nice to have you with us. This is my second interview at WordCamp Europe 2026. We’re in a beautiful, big media room. I’ve got to say, this is one of the nicest spaces I’ve ever had for these kind of interviews, so that’s really nice.
Jessica has already done, I want to say presentation but maybe it was a workshop. I’m not sure.
[00:03:57] Jessica Lyschik: No, it was a regular talk actually, yeah.
[00:03:59] Nathan Wrigley: Okay. And how did it go?
[00:04:00] Jessica Lyschik: It went super well, except for my slides went missing in between. That wasn’t so great. But the audience was very respectful of that, and I made a bit fun of it, so they laughed for a second and I tried, the media guys tried to fix that. We got it fixed in the end. I would’ve winged it anyway because I, like I knew what was coming up. But it’s always good to have your slides. It’s like seeing them, because for me it’s also visual reminder. It’s like, I need to see what I’m talking about, so I’m not losing track of it. But yeah, this was just a little technical hiccup. But overall I got very great feedback so far on my talk, and I’m very glad.
There were also quite a lot of people. I did not expect this many. And that makes me just super happy that people are actually interested in this topic, although it is sort of scary for some of them if they even like try to touch this topic. We can probably get into the details later. Yeah, just overall like, what does it do? Why do I need that? These unanswered questions that they have that they were like, ah, no, I’m not really interested into that.
[00:05:01] Nathan Wrigley: Oh, that’s nice a big reception.
[00:05:03] Jessica Lyschik: Yeah. And that’s just great to see because I think just as we all grow older, and I even noticed that, and I’ve said that in my talk, like I kind of get to appreciate when a website is accessible. I mean I’m still have a long time to go, hopefully in my life, but I start to appreciate the small things that make just browsing websites easier, to be honest.
[00:05:23] Nathan Wrigley: So I guess we should introduce the subject and then give you a chance to introduce yourself because it feels like in this context, the subject at hand, it’s important to know that you know what you are doing. It’s not, well, I suppose it’s a general skill in that it should be something most people know an awful lot about. But I fear that that’s not the case.
So the presentation that you’ve just given was called accessibility in themes, easier than you think. That’s nicely phrased. Let’s get them through the door.
And then the blurb that went with that, I’ll just read that into the record then everybody knows what we’re talking about. So it says, many theme developers assume accessibility ready requirements are hard to meet, but that’s rarely true. This session shares practical insights for real theme reviews, and shows how both block and classic themes can reach accessibility ready status with manageable effort.
So that’s the context of what we’re going to talk about today. However, as I just alluded to, could you just tell us a bit about you, how long you’ve been using WordPress, and then I guess if you want to focus a bit on your accessibility credentials and what you’ve been doing in that space.
[00:06:23] Jessica Lyschik: Yeah, of course. So yeah, I’ve been using WordPress, I think I started around 2005 or 6 already. So like dipped my toes into it, played with it around, just got a feel for it. But actually professionally, I started out in 2015 in the WordPress ecosystem.
Before that, I already joined the community. So I was working at another place that did not use WordPress before. And then in 2015 I joined a WordPress agency. Today they’re called Syde, for anyone who’s wondering. And ever since I’ve been into WordPress that long.
And accessibility in that case I have, I think it was a gradual process more of. It was not just like, I’m now doing accessibility. That just didn’t happen. It was, I learned it over time. And when I started learning about how to create a website accessibility was absolutely not a thing. No one cared about it. And it just became more and more aware for people, for developers, especially in the past couple years. I think we still have some way to go but like, as I said earlier, there were so many people interested in my talk. So I think we’re now at a pace where things get really interesting for many more people.
And yeah, I learned a lot along the way. Made a lot of mistakes along the way. But I’m glad I’m learning this. I’m still learning. So it’s always something that you continuously learn, because I think the hardest part to grasp for people is that, if you are abled, it’s like you can see, you can hear, you can navigate a device with your own hands, all stuff like that, you take it for granted.
And if you suddenly see or people tell you the perspective of like a blind person, a person who’s deaf, a person who may not be able to use a device like you do, maybe have a hand injury, or no hands anymore, that’s also happening. Then you start to wonder, okay, how do these people actually like use websites or use their phones or computers? And there are many different ways to do that. And I think if you have the chance to learn about this, it is absolutely eye-opening.
You can also then, there was a talk at WordCamp Leipzig this year, but also last year, I attended last year, by a blind person. And her brother was also blind. He was a developer. And they shared like how bad some websites are, and how they struggle to like get the information out of the website, and what crazy, crazy stuff people are doing to their websites that do not make it accessible for these people.
And then you are sitting there and wondering, oh my God. And sometimes I have to say, I even did this in the past and I didn’t know, but I’m glad today that I learned about this and make a better web essentially. Yeah, that’s why I’m here sharing my knowledge.
[00:09:11] Nathan Wrigley: It kind of sounds for me, so when I talk about accessibility, there’s always two strands to it. There’s like this legal bit where the governments are increasingly talking about things that will happen to you as a company that builds websites if you don’t follow guidelines. So that’s one side.
But there’s also this moral side. There’s the side of, we ought to do this despite what the law says. You know, it’s just a necessary thing. And it feels to me as if your journey in this was a moral one.
[00:09:38] Jessica Lyschik: More of, yes.
[00:09:39] Nathan Wrigley: Yeah, there was a definite need here. You know, in the real world when you see somebody, let’s say somebody who’s sitting in a wheelchair and they’re trying to get into a post office and there’s a step that they can’t get over, there’s no bit of you which doesn’t see that as unjust. Every bit of you says that character can’t get over that step. That’s wrong.
And yet, the bit of the world which is becoming increasingly the way that we interact, you know, we book flights, we file our taxes, we do our banking, we, all of these things, they’re completely invisible.
Most of the time we’re doing the internet by ourselves. You know, we might be sitting on a train, but nevertheless it’s a solitary activity, or we’re in our own home or whatever. And these pitfalls, the equivalent of the step in front of the post office is totally invisible.
And it also seems that the voice of the people whose lives are made more difficult is just drowned out. Somehow that anger that they must feel never seems to rise to the top quite enough that we all take the necessary steps.
I don’t know if any of that landed, and there was definitely no question there, but I’ll hand it back to you if any of that resonates.
[00:10:49] Jessica Lyschik: No, I think you, you’ve put it absolutely right. And the invisibility is the thing, because a step for us is visually, like we see it I mean. If you’re blind, you’re not seeing it. But let’s put it away for a second. But in the web, the invisibility is like the key thing. And I just talked to Anne-Mieke Bovelett about, who’s doing another accessibility talk this afternoon. She told me about like a company where they put effort into their website, making it more accessible. And their sales actually increased. So it can definitely help. This is just one example.
But there’s also a new player in the field that will probably even increase the interest in accessibility, and that is AI agents. Because AI agents, they do not see a website as we do visually. They rely on that the website is technically built correctly. Google actually just last month announced that they will focus on this. They will focus on the accessibility for the AI agent. I have put a link in my slides to that document. This is basically, I think something that will be easier to grasp for people for some weird reason. But it’s made more visible to them because if an AI agent cannot read your website, and I know we are probably still at the very beginning of this AI agent stuff, but I think this will increase over the next couple months or even years.
[00:12:14] Nathan Wrigley: That’s really interesting because when an individual, let’s go back 10 years, when an individual is creating a website, every single bit that you have to achieve is a minute of work or another minute or 20 minutes or an hour or what have you. And so there was this whole thing of just building the website, especially when page builders and things like that came along, just building the website to see what it looks like. And that whole accessibility layer just basically gets ignored.
However, that’s what you’ve just said is curious because the AI agent building the website, to the AI agent, that’s kind of no extra work to get it right, if you know what I mean? If it’s configured to do all of the bits correctly, I’m using air quotes around the word correctly, then in theory it should be quite a good custodian of accessibility when it’s building things. I guess only time will tell whether that actually happens.
[00:13:08] Jessica Lyschik: Yeah, but it’s also for like, not the agents itself building, but also the agents visiting your website. Especially if you do like, I think shopping will be the one thing that if you say, hey, I don’t know what the best coffee or what, this is like a good topic. Yeah, okay, here are three options. And then, okay, buy me option one, a kilo of these beans or whatever. The AI agent, if the shop is accessible, the AI agent could do the shopping for you. This is where things are going and progressing towards, that you are not actively anymore the person who actually goes to the online shop, puts it in the cart, goes to the checkout and does all that stuff for you. But if the agent knows all that, it can do it for you.
[00:13:50] Nathan Wrigley: Can I ask a question then? Because I may have, I think I’ve understood what you were just saying and curiously, I’ve never had that thought, the one that you’ve just expressed. I want to know if I’ve got it right. Are you saying that in a world in which we increasingly ask AI to achieve things on the web for us, if it’s built with accessibility in mind, it’s more likely to be able to achieve the result of, let’s say, buy me a kilo of coffee.
[00:14:14] Jessica Lyschik: Yep.
[00:14:15] Nathan Wrigley: That’s so interesting.
[00:14:16] Jessica Lyschik: Yeah because like, Anne-Mieke, whom I just talked about, shared a long document with me recently and I was just reading through it and was like, yeah, of course. Of course, if we technically do things right, we use the right elements, we do the right descriptions for everything that a computer, because AI agent is just a computer. Like assistive technology, like a screen reader who needs to read the right structure out of it and to fit the right content. But also is able to interact with stuff, like click on that button, put that in the cart, go to the checkout and so on. It’s basically the same. An AI agent is a screen reader.
[00:14:53] Nathan Wrigley: Yeah, that’s really interesting. I’m thinking of a map where I’m trying to get to a destination, but the map has no directions. Imagine a scenario where we set off from one place and our destination is here. What you are saying is all the instructions in between to get from the start to the end can be read if the HTML and all of the bits and pieces wrapped up in that are correct. I had never had that thought before. That’s so interesting.
[00:15:17] Jessica Lyschik: Yeah, that’s very interesting. And I did not focus too much on this topic in my talk, but I wanted to put it in there at least in one slide to give like the food for thought that people can actually think about it because this is like what’s hyped right now. I have not tried out this whole agent thing yet, but like from a developer perspective, I can totally see that this is something that will increasingly help AI agents to achieve stuff.
[00:15:41] Nathan Wrigley: Yeah. And presumably make it so that a whole tranche of people who struggle with the web as it is currently might be able to interact with their voice or whatever other technique they use. We’ve completely gone off the rails, but that was such an interesting aside, thank you.
[00:15:58] Jessica Lyschik: Yeah, I think this is something interesting to share. And as I said, I wanted to focus more on the technical details in my talk, so I left it kind of out. But I think it’s a great opportunity to share it here with you.
[00:16:08] Nathan Wrigley: Yeah. That was lovely. Thank you.
So let’s go back to the WordPress bits and pieces then, and I’ll just do the title again because hopefully that’ll refresh it in listeners’ minds. Accessibility in themes, easier than you think. Dear listener, if you’ve been using WordPress for any length of time, you’ll know that the themes still plays a giant part in the structure of your website and the way that people experience it.
So where are we at then in the year 2026? Does the theme still represent a huge part of accessibility? In your experience, is it easier than most people think to get an accessible website in the year 2026? We’ll get into block based themes and classic themes and all that in a minute. But essentially what I’m asking is, is it an easier thing to get right than most people imagine?
[00:16:51] Jessica Lyschik: Yes, because I think what scares people off from my own experience, there are requirements to get the accessibility ready tag in the wordpress.org theme repository. And these requirements, if you first read them, they’ll sound a bit cryptic and you do not really understand what they actually mean.
In my talk, I was trying to combine this, what the requirement says with what is actually meant by that. Because right now, and this is something I would like to improve for the future, I’ve already talked to people about this, and I will have another chat with Rian Rietveld about it later, or tomorrow. Let’s see when we can make that happen.
Because right now the requirements read like, okay, this must be achieved. This is what the website should do. Then there are some testing instructions, but you’re not told how to achieve it. What do you technically need to do in order to do that?
I noticed this while I was reworking. I found out about the requirements also just a month ago because the requirements got updated. I have a theme in the wordpress.org repository and I tried to apply these new rules and have another fresh look at it. I got the accessibility ready tag for this already when I first got the theme into the repository. But like it was a good refresher to like go over all the requirements because they have slightly changed a bit, they added new ones.
When I was there, I was like, okay, like I understand this now because I have learned about accessibility over the past couple years. For someone who is fresh to this topic and doesn’t know too much about it, it’s hard to understand. Because there are some descriptions of things like, basically what it means is that you need to use, for example, the right HTML tags, header, footer, the main tag. We have section and aside, which are available in HTML 5. But the requirements does not say this explicitly.
And I think this is where probably most people have gotten stuck in the past, because they did not understand like, what is actually required from me technically? Because the texts are not so much focused on that. And this is something I would like to contribute as well, to give back and to enhance. So it’s not there yet, but hopefully sooner than later we can add all this information so it gets even easier for people.
Because if you’ve done a website and you know about the HTML, you know about maybe a little bit of CSS, you know how to achieve this. You just need to connect the dots to what is relevant for accessibility and how do you do this in your HTML essentially.
[00:19:20] Nathan Wrigley: Yeah, I guess that’s a bit of a shame really, isn’t it? Is that the documentation is difficult to follow because I feel that accessibility is one of those things where if something is difficult it can get dropped basically.
[00:19:33] Jessica Lyschik: Yeah, people won’t do it.
[00:19:34] Nathan Wrigley: Yeah, because the majority of people browsing the internet can browse the internet despite your accessibility efforts, that will be the standard that they’re aiming for in most cases. So if it’s difficult to achieve these things and the documentation’s not really straightforward, every time somebody comes across a question and thinks, I don’t really know the answer to that, probably the quickest thing to do is just to, ah, push it to one side and not press through. But you obviously have and made it a bit of a goal.
So is there a particular accessibility requirement that developers in your estimation kind of overestimate the difficulty of? What I’m asking here really is about some low hanging fruit that you know about. In the scenario that we’ve just described where it’s easy to get put off and to sort of say to yourself, okay, I can’t do this. I’m wondering there are some sort of quick wins that you could describe that people could maybe achieve within the next half an hour, once they sat down at their machines?
[00:20:27] Jessica Lyschik: Yeah, I think there are definitely some. There is like underlining text in your main content, just underline the text. It’s one line of CSS, text declaration underline. For links, obviously, not for the entire text.
And there is like, as I said, the HTML tags. With block themes, it’s super easy. For example, you just need to configure that correctly in the editor, or use the correct template part and it’s basically done for you. Core does that. This is one advantage of block themes, but we can dive into this deeper later. Or the skip to content links also in block themes.
As an example, in block themes it is just like putting the content block in a group and assigning the main HTML tag to that group. And WordPress does the rest for you. It’s just like assigning this one little setting correctly and then you get automatically a skip a content link for block themes.
[00:21:18] Nathan Wrigley: Yeah, but curiously, if you didn’t know that small fact, that WordPress would handle that for you, if you don’t know, you don’t know. And you’d presumably go around the houses trying to figure that out for yourself and implement some custom version of that thing. Whereas in fact, what, three clicks, four seconds and you’re done.
[00:21:33] Jessica Lyschik: It’s super easy, yep.
[00:21:33] Nathan Wrigley: Yeah. Any more before we move on?
[00:21:35] Jessica Lyschik: I think these are like the most, absolutely the low hanging fruit is also if you use any images to add an alternative text. I think this is probably the most common one people already know. It is so easy. And even WordPress, even if you use classic themes, it’s already in the media library, the alternative text field. For block themes you have it directly at the image so it’s already in front of you. You just need to use it.
[00:21:57] Nathan Wrigley: Yeah, you just not ignore it basically. Yeah, that’s true.
So has this become kind of a habit for you then, over the last period of time since you’ve taken more and more interest in this? Have you got to the point now where this is just how it works? You know, in the same way that I drive a car and I use the gears and that’s all just second nature. Is it like that for you when you are building your themes? Because it’s now locked away in your head. Every time you do a thing that previously you would’ve omitted. You are now just in the habit. Has that been a difficult journey or fairly straightforward?
[00:22:28] Jessica Lyschik: I think it’s, like starting out with this, it would feel like a bumpy road. But for me it was, it’s a gradual process. But right now it’s really like, yeah, I just know that when I use a button in a context that is not like sending off a form to add an aria label to it, it’s like, it is baked into my brain essentially already because I know.
And I just had a very interesting example this week at work where there was a client reaching out saying, hey, we did an accessibility test on our website and it marked like two buttons that did not say what they’re doing. These were essentially missing the aria label because they had only icons on the buttons, not real text.
So if there’s just an icon, the screen reader cannot read, what is this button for, essentially, with just an icon? The win here was just to add the aria labels, because the fields were already there. This was also part of the Greyd.Suite, so from our product so I knew how to put it in there. And then it was like, oh no, like I have to do this 12 times, my colleague said. And I was like, yeah, okay, then you have to do it twice, 12 times. So 24 times. But be happy it’s not 200 times you have to do it.
So, and I said, do not take this personally. This is a great example of why putting accessibility at the very beginning of when you’re creating this makes life so much easier than rather when you just build a website and then you figure out you have to change 300 buttons. This is probably a crazy number, but just to give you an example, to change all the buttons manually again, going through every single page or whatever you have when you just could have taken the extra step, added the aria label, and then just be done with it.
[00:24:09] Nathan Wrigley: Right. That’s an interesting thought. And also the exasperation of your colleague there kind of perfectly sums up the problem. In that you see it as a problem. Does that mean I’ve got to do something 24 times? And there’s this sense of, ugh, I’ve got to do this work. And it feels like a chore. But then I suppose if you step back and look at what you’ll actually enable by doing those 24 things.
And I know that in the workday that’s hard to do. It’s hard to sort of step back and say, okay, if I do this thing 24 times, this will be the result, and lots more people will be able to, in this case, view the image.
[00:24:42] Jessica Lyschik: I mean this was like they started already working on. If you fix it now, you do not have to do it for the coming pages. So if you multiply that with how many pages more you need to do, once you get this one fixed, and ideally you need to change the aria label of the text changes obviously, but this was, I think for a header, in a header, where there was like, I think one sort of popover or popup. Fully accessible by the way, so don’t worry about that. And also a button to, I think for the phone numbers, like just a phone icon. And they could click on it and it would be something like that, along the lines. I don’t exactly remember what it was. But it was just like two icons in the header. And if you take that header, use it on, I don’t know, another 250 sites, you don’t need to do the work anymore.
[00:25:29] Nathan Wrigley: Okay. So you are painting a picture in which, get it right at the beginning, follow the guidelines, do the hard work once, then almost the career from then, from this moment forward, your life will be immeasurably easier if you build it into the theme or.
[00:25:45] Jessica Lyschik: And accessibility will not be taken as, ugh, and I now have to do this all. Because when you do it from the start, you have to make sure at the end of course that it still works. You may have to run into issues and redo stuff. That can happen. But I think you just have saved yourself so much work in the end if that requirement for some reason pops up later or so.
[00:26:10] Nathan Wrigley: I’m wondering, depending on the kind of nature of where you work, and how you do this. You know, if you’re a freelance, then this is on you. If you’re in an agency, then it may be that there’s somebody, you know, maybe there’s an SEO person, there’s a design person, maybe there’s an accessibility person. But it does feel like the moral argument states everybody should have some insight. Maybe you’re not right in the weeds of it, but you should have some knowledge of what the low hanging fruit is, at least.
[00:26:38] Jessica Lyschik: Yeah it’s, what’s the right word for it? Interdisciplinary. It is like not just the developer who needs to think of accessibility. It’s like, okay, we need to because like we provide a technical structure for it. But it also needs to be for the content people who write the blog posts, the pages, whatever, for SEO people to understand that.
And I think accessibility, if you want the entire website to be accessibility, everyone who works on a website needs to know about it. That an SEO person needs to know how to create a skip link, probably not. Or how to use, maybe to use the right text. But for them, the text would be just the, using the right heading structure, for example. This is also a requirement, that you do not use an H3 and then an H6 heading in your content, but you structure it correctly that you have the H1 on the top, and then every next level is H H2, and then every level under that is H3. So this way. They should know about this. But they do not need to know too much about the technical side. Because in the end, it all comes together and creates an accessible website.
[00:27:42] Nathan Wrigley: In your commentary a few minutes ago, you mentioned that there were some guidelines in order to put a theme on wordpress.org. Is that the nature of it? Is it a guideline, or are there some hard and fast rules, which will prevent a theme getting into the repo based upon a lack of accessibility? What I’m asking is, are there some things that you must do as of now, or is it very much, okay, if you do this, great, but if you don’t, we’ll let your theme pass anyway?
[00:28:09] Jessica Lyschik: Yeah. Let me explain this. So there’s this accessibility ready tag. So you have different tags for the themes in the repository. And in order to get the accessibility ready tag, you need to follow the requirements, the accessibility ready requirements, I think it’s completely called.
And these are as of now 18 requirements. I went through them all in my talk. We’ve already touched on some of these. Some are really low hanging fruit, some are, one of the newer ones are, a theme should not recommend or require a plugin that is not accessible. This is something else that the team came up with, which is an interesting one. There’s, I guess a lot of room for discussion.
But also another one is to have an accessibility.txt file in your theme. Which basically, it’s not a standard yet, but like close to a standard sort of, has information about what has been done in terms of accessibility. Are there any classes that you can, CSS classes that you can use to make use of texts for screen readers? So basically hide them visually, or hide these texts or items visually, but still have them read out by screen readers. So they’re not like discipline none where you just remove that basically from the accessibility tree, but make it still readable for screen readers. And just some more information about that.
Yeah, you need to meet all these requirements with your theme if you want this tag. But you can still like do not care about accessibility and still get your theme in the repo if you want.
[00:29:40] Nathan Wrigley: Would you like that to be flipped? Would you like that to be, because I mean we’re a very open ecosystem, aren’t we? And would you like to see though a day where you don’t meet these 18 guidelines, you don’t get the tag, you don’t get to play, you’re not allowed in the repo? Or is that a touch too far?
[00:29:56] Jessica Lyschik: Let me share some numbers, I think. So there are like 14,700 plus themes in the repository right now. All themes. At least that’s the number I can access. I don’t know if there’s maybe a bit more, I don’t know. But this is the public number you can access. And out of these themes, I think if I saw the correct number, it’s like just 270 have the accessibility ready tag. So then that is like 1.5% of all themes who have that tag.
So I think it will be extremely hard to force sort of, if you want to flip that, force that onto people. And I think we need to do a more gradual way. And that’s what I’m sharing my knowledge because I think it is not that hard. If you can improve the documentation for it, it will be even easier for people. And I think this is the way to go instead of forcing like, because we do not like to be forced to things we do not understand.
[00:30:50] Nathan Wrigley: That’s right. Yeah, that’s interesting. I wonder if there’s a future in which that slowly gets ramped up.
[00:30:56] Jessica Lyschik: I think with the AI agents, we will have an acceleration on this, I guess. So maybe not in WordPress themes, in the repository directly, but I think the attention will be put there and then like, oh, maybe we should make it more accessible. Let’s read into this. And I think these guidelines are also very interesting, maybe not just for WordPress themes. I mean, of course they’re for the repository, but you of course can apply them to your own custom theme, definitely. You do not have an absolute check like the team will do for you. But nothing stops you from using them even on a non WordPress site.
[00:31:30] Nathan Wrigley: Do the guidelines, do they feel like they’re kind of firmly fixed or is it always a movable feast?
[00:31:35] Jessica Lyschik: They’re relatively fixed.
[00:31:37] Nathan Wrigley: Okay, so if you were to swat up, for want of a better word, on what there is right now, there’s a good chance that the rug will not be pulled out from under you in six months, a year, two years time.
[00:31:46] Jessica Lyschik: No, I think the last time the requirements got updated was in 2012, 14. I would need to ask, Joe Dolson did the initial, or was working on the initial thing. And so it has been a while since this got updated and they just got updated last month. So I don’t think that they will be changing anything.
The one I talked about, not requiring or recommending plugins is the one, this is something, it kind of creates a grey area sort of. And I think this will be put to discussion. It’s like, I don’t mind, but I can see many people like really, not raging against it, but like raising questions about it. If this is something that should be a requirement.
But I think for like the actual technical stuff, I don’t think that there’s much that should change, because like they’re based on the WCAG requirements. These are like the standard requirements that also have, I’m not sure if they’re used on governmental things, like on the European Accessibility Act, but I think they’re a sort of base for that. And it’s not like completely this. So the theme requirements are not like the WCAG requirements 100%, but like a subset of it, sort of.
[00:32:57] Nathan Wrigley: Yeah, it’s a fairly slow moving ship in other words. If you acquire the knowledge today, you’ve got a good chance that in a year, two years, maybe even five years, the knowledge that you’ve got will need amending. But most of it will broadly work several years from now.
[00:33:11] Jessica Lyschik: It’s with like development in general. So like you always need to be constantly learning. And I think if you learn about accessibility today, I think you’re in a very good spot. Because like of course we have European Accessibility Act and governmental requirements, at least in Europe we do have them. But I think there’s already so much information out there, that it should be relatively easy to onboard you. And I think this is just beneficial if you learn, it’s basically about learning about how to use things correctly. And if you’ve got that, then you’re absolutely good to go.
[00:33:45] Nathan Wrigley: So not that long ago I suppose, we had block themes coming around, which is an entirely different way of creating themes in WordPress. So you’ve got classic themes, which is the way it always used to be. And now we’ve got block themes. Is there a striking fundamental difference in the way that you might approach accessibility if you were used to doing block themes? Is there a whole lot more to learn? Maybe it’s more straightforward if you’re using block themes. Just tell us about how those two things differ.
[00:34:08] Jessica Lyschik: Yeah. It is more straightforward actually. Core is handling stuff for you. So accessibility just got a tad bit easier if you use block themes actually. In classic themes, you have to do a lot of things manually. You have to make sure that the elements are right, that the skip link is there, for example, things that we touched on already. And in block themes, if you use the correct blocks on the correct structure, Core handles stuff for you.
For example, there’s a requirement labelled form fields. So when you use a form or the form fields should have a label to it. In themes you don’t really have that because usually you should not put like, something like a form in there. There are two forms that by default come with a theme that are the comments form, but that’s completely handled by Core. And there’s the search form on the search results page.
But in block themes, both of them are handled by Core. Both of them are accessible because Core handles it all for you. You just need to place them and actually not do anything to them. It is that straightforward.
And same for like template parts. If you want to use header and footer, just use the template parts and use them. You can assign them a header template part as header of course, and one as footer. And then the HTML text will be automatically added correctly for you. So there’s not too much that you need to do manually anymore, just get that right.
And as I say, I really love block themes for the much easier accessibility, or the way you can make a block theme accessible. This is so much easier than with a classic theme.
[00:35:38] Nathan Wrigley: So presumably though, it sounds like there’s meta knowledge, if you know what I mean. You’ve got to know which block to put in which spot, and which block wraps this other block, and the parents and the children. But if you learn that, and if you make that, we were talking about habits earlier, if you make that your habit, and then save that habit and save the theme and what have you, you are painting a picture where it’s significantly more straightforward because you don’t have to think about it in many cases. Well, that’s the wrong way of phrasing it. You don’t have to do that hard work.
[00:36:07] Jessica Lyschik: Exactly. If you have like a, sorry to interrupt you here, but if you have a theme that already gives you the correct examples, you can build off from that theme. For example, if you’re creating a new template, you can use an existing template and then just adjust it to what you need. If you need to change like colours or something but you have the structure already correct. You do not need to think about doing the structure again and maybe just have a check that it’s actually the right one. But if you just copy what’s already there, that is part of the theme, that’s actually super easy.
[00:36:38] Nathan Wrigley: I’m going to link to your presentation, which I know by the time that this goes out will be probably on wordpress.tv, I would’ve thought by that point. But I’ll link to your presentation and all of the different bits and pieces.
But I’m curious, who in the WordPress space, and maybe not the WordPress space, maybe outside of that, who do you follow or try to get guidance from? Maybe that’s a YouTube channel or a blog, or a, I don’t know, government based website. Maybe it’s just wordpress.org, I don’t know. Where do you go to swat up on all of this?
[00:37:06] Jessica Lyschik: Ooh, there are some very good resources out there. So I do follow like people within the WordPress community. I mentioned a few names already, like Joe Dolson, Rian Rietveld, Amber Hinds from Equalize Digital. They do a lot of stuff in that area. And then I also follow Sara Soueidan, she’s a developer from, I think Lebanon, if I remember correctly. She does great stuff on accessibility. There is a few more names. There are some good resources out there. I can probably research that for you because I cannot remember the names right now.
[00:37:39] Nathan Wrigley: I’m putting you on the spot. I’m sorry.
[00:37:40] Jessica Lyschik: Put me on the spot. That’s okay. I’ll share some links with you that you can then put in with the podcast information. There are some great resources both within the WordPress community but also outside of it that can give you a very good overview. And I think it’s just interesting to follow people who like can build the bridge between, okay, this is a requirement, this is how you technically do it, and this is why you do it.
[00:38:05] Nathan Wrigley: I have a friend who’s recently been on the journey of trying to go from zero to really quite proficient in this space. He’s found a bunch of YouTube channels and several of the names that you mentioned there, particularly the Lebanese lady that you mentioned.
And I think followed a course that they put together and found that structure profoundly helpful. The dry documentation, I think was the way it was described on the WCAG website can sometimes I think be a, you know, it’s hard to get into that in some way.
You know, if this all sounds like a lot of work, there’s definitely resources out there, which, fun is perhaps the wrong word, but make it more engaging. There’s videos to watch, and channels to follow and blogs to read and all of this. And so it turns this, I’m doing air quotes, dry subject into something a little bit more manageable and easy to take in.
[00:38:52] Jessica Lyschik: Yes. Yes, because like the WCAG requirements, like they’re hard to read. It’s like reading, the HTML 5 spec. This is also super hard to read.
[00:39:01] Nathan Wrigley: Yeah, it’s the cure for insomnia.
[00:39:03] Jessica Lyschik: Yeah, sort of. And it’s, yeah, I think if we have, not more content, but the right content available to people in the right spot, I think this will be beneficial for everyone.
[00:39:14] Nathan Wrigley: Yeah. I think unless there’s something else you want to cover off, I think, Jessica, I’ve asked everything I wish to. Is there anything you think we’ve omitted or are you happy to call it a day there?
[00:39:24] Jessica Lyschik: I think we’re, I mean we could go on probably for days. But I think for now it’s, we’ve covered every topic.
[00:39:32] Nathan Wrigley: Well in which case, what I’ll do, dear listener, if you go to the WP Tavern website and search for Jessica’s post, I’m not sure what number it will be as we’re recording it, go there and anything that we discussed, and any names that we discussed and those kind of things, I’ll put a link and obviously if Jessica supplies any other things she mentioned, we’ll add those in as well.
So Jessica, thank you so much for chatting to me today. And now that your presentation is done, you can relax and enjoy the rest of the spectacle.
[00:39:55] Jessica Lyschik: Yes. Thank you so much, and thanks for having me.
[00:39:57] Nathan Wrigley: You’re welcome.
On the podcast today we have Jessica Lyschik.
Jessica is a longtime member of the WordPress community who has been working in the ecosystem since 2015. She has spent years learning and advocating for web accessibility, both as a developer and as an active community participant, joining agencies, working on theme reviews, and helping to improve standards.
Many theme creators assume that making themes accessible is an intimidating task, but Jessica’s here to show you that achieving an accessibility-ready WordPress theme is more straightforward than you might imagine. Her WordCamp Europe 2026 presentation, “Accessibility in themes: easier than you think,” aimed to demystify the requirements for accessible themes, explaining what the WordPress guidelines mean in practice, where the low-hanging fruit is, and how both block and classic themes can reach accessibility-ready status with manageable effort.
We talk about the personal and moral journey that brings developers to accessibility, the technical hurdles and documentation challenges, and the ways in which things like AI agents are putting accessibility in the spotlight for everyone. Jessica talks about practical steps that quickly improve accessibility, like using correct HTML tags, adding alternative text to images, and configuring skip-to-content links, and shares why building accessibility in from the start saves time and effort down the road.
We also explore the differences, and possible advantages, of block themes when it comes to accessibility, why theme guidelines work the way they do, and the importance of interdisciplinary awareness across SEO, design, and content teams. Jessica mentions helpful resources, influential leaders in accessibility, and the ongoing need for documentation improvements to help everyone level up.
If you’ve ever felt overwhelmed by accessibility requirements, or wonder why they matter, and how you can build better WordPress sites that work for everyone, this episode is for you.
Useful links
Accessibility in themes: easier than you think – Jessica’s presentation at WordCamp Europe 2026
Accessibility Handbook – Theme section
Open Channels FM: We are Welcoming Automattic as our Newest Sponsor
Automattic is now a sponsor of Open Channels FM Podcast Network, supporting creators with tools for WordPress, WooCommerce, and more, promoting freedom online.
Open Channels FM: The Growth of Domain Names and the Future of AI in Internet Identity
This episode looks at the evolving online landscape, focusing on domain names, digital identity, and AI’s influence. Key insights include rising domain registrations, AI in managing abuse, and the importance of open source.
Open Channels FM: Open Source and the Open Source Initiative
People think Open Source is just about having access to the source code. Actually, there’s a much longer history behind it. Open Source existed before the term Open Source was even coined, back in the late 60s. Universities started giving away software like Unix for free under small licenses like BSD or MIT, coincidentally named […]
WordCamp Central: WordCamp Rajshahi 2026: Celebrating Community, Learning, and Open Source
WordCamp Rajshahi 2026, held on July 2nd-3rd, 2026, at the Rajshahi University of Engineering & Technology (RUET) Auditorium, brought together WordPress enthusiasts, developers, designers, business owners, students, and open-source contributors from across Bangladesh and beyond. As a non-profit, community-driven conference, the event demonstrated the strength of collaboration, knowledge sharing, and the spirit of open source.
More than just a technology conference, WordCamp Rajshahi became a place where people connected, exchanged ideas, and inspired one another to contribute to the future of WordPress.
Sharing Knowledge That Matters
The conference featured a diverse lineup of local and international speakers who shared practical experiences, real-world case studies, and emerging trends shaping the web today.
Artificial intelligence was one of the most discussed topics throughout the event. Sessions explored how AI is transforming the way developers and businesses work—from integrating AI into WordPress without writing code to building customer support agents, using modern Large Language Models (LLMs) for development, debugging applications, and improving everyday workflows.
Performance, architecture, and security also received significant attention. Speakers demonstrated advanced WordPress optimization techniques, object caching strategies, no-code animations using GSAP, methods for identifying system vulnerabilities, and practical approaches to cleaning malware-infected WordPress websites with AI.
Beyond technical sessions, the conference emphasized personal and professional growth. Attendees learned about building successful careers, transitioning from startups to multinational companies, product marketing, the realities of remote work, and maintaining mental well-being while working in the technology industry.
Contributor Day: Giving Back to WordPress
Contributor Day, held on July 2, served as one of the most meaningful parts of the event.
Participants worked alongside experienced WordPress contributors and Table Leads to improve the WordPress project itself. Whether they contributed to Core, Accessibility, Themes, Plugins, Polyglots (translations), Education, or Photos, attendees experienced firsthand how community collaboration built the global WordPress ecosystem.
For many first-time contributors, it was their first opportunity to make a direct contribution to one of the world’s largest open-source projects.
Campus Connect: Inspiring the Next Generation
One of the highlights of WordCamp Rajshahi 2026 was the Campus Connect initiative.
To encourage student participation in open source, 40 university students received complimentary tickets to attend the event. This initiative introduced young learners to the WordPress community, allowing them to interact with experienced professionals, attend technical sessions, and discover opportunities to contribute to open source.
By investing in students today, the community hopes to cultivate the next generation of developers, designers, and contributors who will help shape the future of WordPress.
Sponsors Who Made It Possible
WordCamp events are made possible through the generous support of organizations that believe in strengthening the open-source ecosystem. Rather than simply sponsoring an event, these companies invest in community growth and knowledge sharing.
This year, the sponsorship tiers celebrated Rajshahi’s famous mango heritage.
Fazli Majesty (Platinum Sponsors)
Himsagar Legacy (Gold Sponsor)
Amrapali Delight (Silver Sponsors)
Community Sponsors
- Crowd Zone,
- Exprovia,
- NT Tech Innovation,
- Padmazon Limited,
- ShapedPlugin,
- Sigmative,
- Timetics AI,
- WPBakery.
Official Partners
- FM Networks (Internet Partner)
- TNR Soft (Payment Gateway Partner)
Their support enabled the community to deliver a world-class experience while keeping the event affordable and accessible.
Thank You to Everyone Behind the Scenes
An event of this scale is never the work of a single person.
Our sincere appreciation goes to every speaker and Contributor Day table lead who generously shared their knowledge and experience with the community.
We are equally grateful to our organizers and volunteers. From sponsorship coordination, website management, registration, design, photography, audiovisual production, venue operations, food management, and attendee support, every team member played a vital role in ensuring the event ran smoothly.
Their dedication transformed months of planning into an unforgettable experience for every attendee.
Looking Ahead
WordCamp Rajshahi 2026 demonstrated what is possible when passionate volunteers, contributors, sponsors, and community members work toward a common goal.
The event was more than a conference—it was a celebration of learning, collaboration, and the open-source values that make WordPress one of the world’s most successful communities.
As the community continues to grow, the relationships built, ideas shared, and contributions made during WordCamp Rajshahi 2026 will inspire future events and encourage even more people to participate in the global WordPress ecosystem.
Here’s to many more WordCamps, more contributors, and a stronger open-source community in Bangladesh and beyond.
Gutenberg Times: #WCUS Schedule, iframed Post Editor, WooCommerce 11.0 and so much more — Weekend Edition 369
Hi there!
What a week! WordPress 7.1 Beta 1 (and Beta 2) arrived with a huge array of updates. We’ll unpack them together over the next four weeks, right up to the final release on August 19, 2026.
One thing shouldn’t wait, though: the security release WordPress 7.0.2. Go update your production sites now — this newsletter will still be here when you’re back. 
In this edition, you’ll also find the first speaker lineup for WordCamp US, a fourth page-builder migration story, WooCommerce 11.0 on the horizon, and plenty of block development goodness: from iframed editors to on-brand maintenance pages.
Grab your favorite Saturday beverage and dig in.
Yours, 
Birgit
WordCamp US 2026: Four Tracks, Three Workshops, 33 Speakers

The first wave of WCUS 2026 speakers is live — and it reads like a who’s-who of WordPress in practice.
WordCamp US just published its opening lineup for August 16–19 in Phoenix: 34 confirmed speakers so far, including K Adam White, Brian Coords, Jamie Marsland, Kathy Zant, Miriam Schwab, and Robert Abela, all experienced developers, educators, security specialists, community builders.
The program runs four tracks.
- AI in Action leads with sessions on agentic workflows, AI search, and guardrails for AI-assisted development.
- Honing Your Skills covers the practical side: maintenance, privacy compliance, creator commerce, security.
- Technical WordPress digs into block migrations at scale, WP-CLI automation, and plugin pipelines.
- Beginning WP101 is the on-ramp for newcomers — or for clients you’re bringing along.
- Three hands-on workshops round out the program, where you build something real in the room and leave with it.
The full session schedule isn’t out yet, but the speaker list alone is a useful signal. If someone on that page is a voice you follow, a tool you depend on, or a corner of WordPress you’re actively navigating, you now have a specific reason to be in the room.
us.wordcamp.org/2026/tickets — $100 General Admission · $750 Micro-Sponsor (includes listing on the sponsors page)
Full speaker list →
Developing Gutenberg and WordPress
WordPress 7.1 Beta 1 was release on July 15, 2026. is now available for testing. The release post offers instructions how to sent up a test side and shows an extensive list of new features.
The security team released WordPress 7.0.2 with the urgent appeal to update right away. The security fixes were also backported in 6.9.5 and 6.8.6.
The security fix was also included in WordPress 7.1 Beta 2, so testing sites are also protected during this release cycle.
Huzaifa Al Mesbah, from the Core Test team, published the accompanying Help Test WordPress 7.1 post.
A few WordPress 7.1 Dev Notes are already available:
- Consistent navigation in WordPress 7.1 with persistent toolbar
- The Classic block stays in the inserter for WordPress 7.1
Plugins, Themes, and Tools for #nocode site builders and owners
In about 10 days, WooCommerce 11.0 release is schedule. Brain Coords has the skinny for you in what’s coming for developers in WooCommerce. Performance leads the release with 28 PRs — product object caching becomes the default for new stores, speeding up variable products by 9–12%. You’ll also find email verification connecting guest orders to accounts, new phone validation hooks, video embeds in the block email editor, and the final removal of the Product Editor beta. The beta is ready for your testing now.
Jamie Marsland followed his instincts and build Jamie’s Front-End Editor for Content Teams, a plugin that lets your editors click any paragraph or heading on the live page and start typing — no block editor required. With the latest updates, you can now edit text, links, buttons and images right on the live page. No wp-admin, no block editor, just click and change it in place.
Built on the Interactivity API with no build step, it preserves block markup on save, records edits as native block notes for an audit trail, and lets you restrict chosen roles to front-end-only editing. Let Marsland what you think.
Last week, I shared three migration stories from page builders to the Core block editor and block themes. Here’s a fourth perspective: The team at WP Expert, an Ottawa agency founded by Frederic Sune, put together a comprehensive post on migrating agency sites from page builders to Gutenberg, should you go on that journey, too. You’ll find the strategic arguments (better Core Web Vitals, smaller attack surface, less technical debt) alongside a practical playbook covering backups, staging, block theme selection, pattern development, and SEO safeguards. The post also explores what block-based architectures mean for an agency’s business model, from premium modernization packages to fewer layout-related support tickets. An FAQ rounds it out.
Theme Development for Full Site Editing and Blocks
Brian Coords tackles a common WooCommerce pain point: custom product templates for block themes. He combines two core WordPress features — the plugin template registration API from 6.7 and the venerable single_template_hierarchy filter — to serve custom templates for product collections, like all products in a category. His example plugin falls back to your Single Product template unless you override it. Clone the repo and give it a try; custom Product fields are next on his list.
On the WordPress Developer Blog, Troy Chaplin shows you how to build an on-brand maintenance mode for block themes. You add one small hook to your theme’s functions.php once, then design and manage the maintenance page entirely in the Site Editor with full access to your Global Styles. Renaming or deleting the template toggles maintenance mode on and off, no code needed. An SEO-friendly variant adds 503 headers so crawlers know the downtime is temporary.

Building Blocks and Tools
On WP Mayor, Jean Galea untangles when to reach for WP-CLI, the REST API, or the Abilities API. His mental model: they’re layers, not rivals. WP-CLI lives on the server for bulk work, REST serves off-server callers like headless front ends, and the Abilities API tells AI agents what they’re allowed to do, complete with schemas and permission checks. Galea also shares how his own sites lean on all three at once.
Get up to speed how to make your custom blocks plugin work in the iframed post editor, if you haven’t yet. After five years of ruminating and communicating the switch is coming to WordPress 7.1. In his post, Ryan Welcher explains why the post editor is going full iframe in WordPress 7.1 and what that means for your custom blocks. You’ll find the fixes for the most common breakage — global window and document references, editor styles enqueued into the wrong document, stale admin-scoped CSS, and third-party libraries — plus a companion demo plugin with broken/fixed block pairs, Playground blueprints for testing both states, and a handy pre-flight checklist.
The video volunteers at WordCamp Portugal uploaded all recordings to WordPressTV and two of the talks caught my eye:
Imran Sayed walks you through the fastest way to build Gutenberg blocks with modern tools, scripts, and AI. If custom block development has felt complex or time-consuming, you’ll appreciate his focus on practical, real-world workflows you can adopt immediately — moving fast without over-engineering. The recording is available on WordPress.tv, and the presentation slides are linked below the video for easy reference.
Jorge Costa shows you how to use the AI building blocks already shipped in WordPress core (the WP AI Client, the Abilities API, and the MCP adapter) to bring AI-powered features into your own plugins, themes, and sites. He also tackles the bigger question: when agents can spin up entire projects on any stack, why is WordPress still the right bet? Slides are linked alongside the recording.
Check out the not so new any more Talk Devy to Me series on Ryan Welchers YouTube Channel! In the latest epsiode, Antonio Sejas demos Studio Code, the agentic AI assistant built into WordPress Studio’s desktop app and CLI. You can spin up sites, run performance audits, add content, and install plugins and themes through natural language conversation — all locally, so nothing you break goes public. Sejas explains how it works under the hood before building something live with the host. Studio Code is free while in beta, so now’s a good time to experiment.
If you rather want to read about the updates in WordPress Studio, Fredrik Rombach Ekelund shares three big updates to WordPress Studio: a new default Native PHP runtime makes your local sites load 30–50% faster while using a third of the memory, the Studio CLI now installs with one dependency-free command — no Node.js or npm required — and Claude Sonnet 5 is the new default model in Studio Code, improving multi-step work like tracing bugs across files. A Sandbox runtime remains available for testing untrusted code.
Questions? Suggestions? Ideas?
Don’t hesitate to send them via email or
send me a message on WordPress Slack or Twitter @bph.
For questions to be answered on the Gutenberg Changelog,
send them to changelog@gutenbergtimes.com
Matt: Important Security Update
WordPress 7.0.2 went out today with two important security updates. One is a type of pre-authorization RCE we (fortunately!) have only seen a few times in WordPress’ 23-year history; the last, I believe, in the PHPMailer class five years ago.
Major kudos to Adam Kues of Searchlight Cyber for finding the batch REST API RCE, to TF1T, dtro, and haongo on the facilitated SQL injection!
Thanks to responsible disclosure, the WordPress.org Security team was able to coordinate with hosts and CDNs to mitigate the attack at the network layer. Please upgrade anyway! But it’s a huge relief to know the vast majority of WordPress sites were protected by defense-in-depth even before the updates went out.
I really appreciate how people and organizations that otherwise might not be on the best of terms come together in times like this. (Full credits in the release post.) Everyone buries the hatchet to protect as many people as possible as quickly as possible.
I’ve said it before, I’ll say it again: security is going to be a big topic this year as the technology industry digests the incredible advances in AI models. It’s a good time to review your plans and processes, sweat the details, invest in maintenance, and hug a sysadmin. 
WordPress.org blog: WordPress 7.0.2 Release
WordPress 7.0.2 is now available.
The 7.0.2 security release addresses one critical and one high severity security issue.
Because this is a security release, it is recommended that you update your sites immediately. Due to the severity, the WordPress.org team have enabled forced updates via the auto-update system for sites running affected versions.
To manually update you can visit your WordPress Dashboard, click “Updates”, and then click “Update Now”, or you can download WordPress 7.0.2 from WordPress.org. On sites that support automatic background updates, the update process will begin automatically.
Security updates included in this release
The security team would like to thank the following people for responsibly reporting vulnerabilities and allowing them to be fixed in this release:
- A facilitated SQL injection issue reported as a team by TF1T, dtro, and haongo
- A REST API batch-route confusion and SQL injection issue leading to Remote Code Execution reported by Adam Kues at Assetnote / Searchlight Cyber
For more information on this release, please visit the HelpHub site.
Backports
- WordPress 6.9 is affected by both vulnerabilities. Version 6.9.5 has been released containing fixes for both.
- WordPress 6.8 is only affected by the first vulnerability. Version 6.8.6 has been released containing a fix.
- The beta release of WordPress 7.1 is affected by both vulnerabilities. Version 7.1 beta2 has been released containing fixes for both.
- Versions of WordPress prior to 6.8 are not affected.
CVE and GHSA references
Thank you to these WordPress contributors
This release was led by John Blackbourn and Barry Abrahamson. In addition to the security researchers mentioned above, WordPress 7.0.2 would not have been possible without the significant contributions of the following people: Aaron Jorbin, Alex Concha, annezazu, Barry, David Baumwald, Dominik Schilling, Ehtisham Siddiqui, Joe Dolson, Joe Hoyle, John Blackbourn, Jonathan Desrosiers, Marius L. J., Matt Mullenweg, Mohammad Jangda, Peter Wilson, Sergey Biryukov, vortfu, Weston Ruter, plus representatives from Altis, Automattic, Bluehost, Cloudflare, GoDaddy, Hostinger, and WP Engine.
Ultimate WordPress Spam Protection Guide – Step by Step (2026)
If you run a WordPress site, then you know that spam is a real annoying problem whether it comes to contact forms, WordPress comments, or user registrations.
The good news is that stopping spam in WordPress is a lot easier than you probably think, and you don’t need expensive tools either.
We have spent over 16 years testing anti-spam plugins, tools, and refining strategies to keep WPBeginner and our other business websites safe from daily spam attacks.
In this ultimate guide, we’ll walk you through how to block each type of WordPress spam, step by step from the basics to advanced modern automated spam protection. These are the exact methods we’re using to protect our own websites.

We’re covering a lot of ground in this ultimate guide, so use the quick links below to jump straight to the section you want to learn about first:
- 1. Free Built-In Settings to Turn On First
- 2. Set Up Modern AI-Powered Spam Bot Protection for WordPress
- 3. Power-User Tips for Stopping WordPress Comment Spam
- 4. Stopping WordPress Contact Form Spam (Best Practices)
- 5. Stopping Spam User Registrations in WordPress (Best Practices)
- 6. Add a Site-Wide WordPress Firewall
- 7. Cleanup WordPress Spam and Ongoing Monitoring
- Frequently Asked Questions About WordPress Spam Protection
1. Free Built-In Settings to Turn On First
WordPress comes with several anti-spam options that can protect your site against spam. These built-in options won’t stop every bot, but they will remove the easiest targets right away.
We always recommend turning these settings on first, because they cost nothing and take only a few minutes to set up.
Tighten Your WordPress Discussion Settings
To prevent comment spam, the built-in discussion settings in WordPress act as your first line of defense. They allow you to control who can post, what kind of links are permitted, and how much control you have over the conversation.
To configure these anti-spam controls, go to Settings » Discussion in your WordPress dashboard.

The most useful tool on this screen is the comment moderation queue. This tool acts as a holding area that keeps submissions hidden from the public until you have a chance to look them over.
Because nothing goes live automatically, spam never reaches your visitors, even if it manages to get past your other filters.
To turn this on, scroll down to the ‘Before a comment appears’ section and check the box next to ‘Comment must be manually approved.’

If you want, you can also enable ‘Comment author must have a previously approved comment.’ This lets returning commenters post without waiting for approval. However, be sure to review your published comments regularly since they won’t appear in your moderation queue.
After that, scroll to the ‘Comment Moderation’ box, where you’ll find a setting that limits links. Because spam comments almost always contain web addresses, WordPress can automatically hold any submission that includes too many links.
The field labeled ‘Hold a comment in the queue if it contains [X] or more links’ is set to 2 by default. Lowering that number to 1 will help you catch even more junk.

On the same screen, you can use the comment blocklist to automatically filter out unwanted content. This tool looks for specific words, names, email addresses, or web addresses and sends any matching comment straight to the trash.
In the ‘Disallowed Comment Keys’ box, you can paste your own trigger words, putting one on each line, and then save your changes.

Require a Name and Email, and Hold First-Time Commenters
Healthy discussions start with real people. Requiring commenters to enter a name and email encourages more thoughtful conversations and discourages anonymous drive-by comments.
Most genuine visitors won’t mind providing these details, and it helps create a more welcoming and trustworthy community around your website.
To enable this, scroll to the ‘Other comment settings’ section and check the box next to ‘Comment author must fill out name and email.’

If you want to master the review process and manage your queue efficiently, our beginner’s guide to moderating comments in WordPress covers the full workflow.
Disable Comments Where You Do Not Need Them
Depending on the type of website you have, you may not need a comment section at all. If that’s the case, then you can simply disable comments entirely and that’ll get rid of the WordPress comment spam problem once and for all.
The most thorough option is the code method, which disables comment support across your entire site at once. It’s safest to add the snippet with a free code snippets plugin like WPCode rather than editing your theme’s files directly, so a theme update can’t undo it.
add_action('admin_init', function () {
// Redirect any user trying to access comments page
global $pagenow;
if ($pagenow === 'edit-comments.php') {
wp_safe_redirect(admin_url());
exit;
}
// Remove comments metabox from dashboard
remove_meta_box('dashboard_recent_comments', 'dashboard', 'normal');
// Disable support for comments and trackbacks in post types
foreach (get_post_types() as $post_type) {
if (post_type_supports($post_type, 'comments')) {
remove_post_type_support($post_type, 'comments');
remove_post_type_support($post_type, 'trackbacks');
}
}
});
// Close comments on the front-end
add_filter('comments_open', '__return_false', 20, 2);
add_filter('pings_open', '__return_false', 20, 2);
// Hide existing comments
add_filter('comments_array', '__return_empty_array', 10, 2);
// Remove comments page in menu
add_action('admin_menu', function () {
remove_menu_page('edit-comments.php');
});
// Remove comments links from admin bar
add_action('init', function () {
if (is_admin_bar_showing()) {
remove_action('admin_bar_menu', 'wp_admin_bar_comments_menu', 60);
}
});
Our guide on how to completely disable comments in WordPress walks through that snippet along with the other options.
If you’d rather not go site-wide, you can also turn comments off on individual pages. This is handy when you only want them gone on specific pages, like your Contact or About pages, which rarely need a comment section.
To do this, open the page in the WordPress content editor. Then click the ‘Discussion’ option in the right-hand sidebar and select ‘Closed.’

You can also stop spam from piling up on older content without touching your newer posts. If you don’t expect comments on old posts, then WordPress can close them automatically after a set number of days.
This gives spam bots fewer chances to target your archived content.
To set this up, head to Settings » Discussion and find the ‘Other comment settings’ section. Check the box next to ‘Automatically close comments on posts older than [X] days’, then set a sensible limit such as 30 or 90 days.

Disable Trackbacks and Pingbacks
Trackbacks and pingbacks notify you when another website claims to have linked to one of your blog posts.
While they were originally designed to help bloggers connect conversations across different websites, they’re now commonly abused by spammers to send fake link notifications.
Turning this feature off completely removes a whole category of junk notifications from your dashboard.
To disable these notifications, go to the Settings » Discussion screen in your WordPress dashboard. Here, uncheck the box next to ‘Allow link notifications from other blogs (pingbacks and trackbacks) on new posts.’

Just be aware that changing this option only protects the posts you publish from this moment forward. If you want to clean up the content you’ve already published in the past, you can follow our step-by-step guide on how to disable trackbacks and pings on existing WordPress posts.
2. Set Up Modern AI-Powered Spam Bot Protection for WordPress
In the era of AI where automated spam is increasing, the best defense against it is a modern AI-powered spam protection for WordPress.
These spam filtering solutions automatically detect and block spam on your WordPress comments, contact forms, and user registrations without the use of CAPTCHA which can hurt conversions.
On WPBeginner, we use ActiveLayer for this. It is AI-powered and runs server-side, so it stops spam invisibly, without a CAPTCHA and it’s GDPR compliant.
In the last 30 days, it has blocked over 25,739 spam comments and contact form submissions on our website. It even shows you a confidence score, and the reason behind every submission it flags, not just a pass-or-fail verdict when you look at their logs.

The free plan includes 1,000 spam checks with no credit card, and paid plans start at around $4 per month billed yearly.
The two other popular spam filtering plugins for WordPress you could try are Akismet or CleanTalk.
Akismet is very popular and still is a good fit for personal blogs, where its “name your price” plan can be free for non-commercial sites. But they have raised their prices significantly for commercial sites which is quite expensive for smaller businesses. For a business site, we would point you to either ActiveLayer or CleanTalk.
Whichever tool you choose, stick to just one, because running two spam filters at once can conflict and block real visitors. The benefit of these spam protection plugins are that they integrate with all other popular contact form plugins by default.
3. Power-User Tips for Stopping WordPress Comment Spam
So far we’ve configured the built-in spam prevention settings in WordPress, and an automated spam filtering plugin for WordPress. The combination of these two should block most spam.
However if you are not able to set up modern AI spam protection due to costs or another reason, then you can use one of these tips below to combat comment spam in WordPress.
Add a Free CAPTCHA to Your Comment Form
CAPTCHA is a simple test that most human visitors pass without any effort, while automated scripts fail it. We recommend adding Cloudflare Turnstile CAPTCHA to your WordPress comments because it’s free and fairly straight forward to set up.
To set it up, install and activate the free Simple Cloudflare Turnstile plugin. You will be asked to create a free account on Cloudflare’s website and connect it with the plugin.
Once that’s done, you can scroll to the ‘Enable Turnstile on your forms’ section. Simply check the boxes to protect all your WordPress forms and click ‘Save Changes’.

Here’s our detailed guide on how to add Cloudflare Turnstile CAPTCHA in WordPress.
Google reCAPTCHA is another option, which you can add with the Advanced Google reCAPTCHA plugin. We no longer recommend it because Google has capped their free tier at 10,000 assessments per month for your entire organization whereas Cloudflare Turnstile stay free without limits.
Limit or Require Login to Comment
Another really effective way to stop comment spam in WordPress is to control who’s allowed to participate in comments.
If your comment section is open to everyone, then spammers can continuously flood your forms with automated links. Restricting comments to registered account holders ensures that only verified users can post. This forces a level of accountability that most bots will not bother trying to bypass.
Because it requires readers to go through the extra step of creating and logging into an account, this approach is best suited for membership sites, online forums, and private communities.
If you run an open, public blog, then we’d recommend using an automated filtering service or a reader challenge instead as those add less friction.
If you do decide to turn this restriction on, go to Settings » Discussion in your WordPress dashboard. Under the ‘Other comment settings’ section, check the box next to ‘Users must be registered and logged in to comment.’

As always, don’t forget to save your changes.
Use Antispam Bee for Free Keyword and Pattern Filtering
Some spam slips through basic checks by mimicking human writing. This is where a dedicated filtering plugin can help protect your site.
Antispam Bee is an excellent free, privacy-friendly anti-spam plugin that doesn’t require an API key or account registration. Installing Antispam Bee gives you a powerful set of local rules to analyze comment data before it even hits your database.
Once it’s activated, you can configure your rules by going to Settings » Antispam Bee.

We recommend enabling the options to:
- Trust approved commenters.
- Mark as spam.
- Do not delete.
- Use regular expressions (which allows the plugin to scan for known text and link patterns).
You should also check the box to ‘Look in the local spam database.’ This allows Antispam Bee to cross-reference new submissions against previous spam history on your site.

Under ‘Advanced,’ you can set Antispam Bee to delete existing spam after a set number of days, which keeps your database tidy without any manual effort.
We highly recommend leaving the email notifications for spam turned off in this section. A busy website can attract hundreds of automated submissions a day, and these alerts will quickly flood your inbox.
If you want to try one more free tweak, then you can remove the website address field from the comment form.
Our step-by-step guide on how to remove the website URL field from the comment form shows you how to do this in just a few quick steps.
4. Stopping WordPress Contact Form Spam (Best Practices)
Contact and lead forms are among the most attacked parts of any WordPress site. We know this firsthand because we once had to combat more than 18,000 spam entries flooding a single form.
We use WPForms to build forms on WPBeginner, and it’s a popular form builder plugin used by over 5 million websites. Their free version includes smart anti-spam protection, CAPTCHA integrations with Google / Cloudflare Turnstile, and the paid plans add the filtering options we cover below.
Other popular form builders like Gravity Forms and Fluent Forms have similar anti-spam settings, so check the options in whichever form builder plugin you use. We will show WPForms here because it’s what we use and consider the best fit for beginners.
Enable Default Anti-Spam Token (or Similar HoneyPot)
To combat lead form spam, WPForms silently attaches a unique, time-sensitive token to your form on every page load. The anti-spam token blocks automated scripts, which means spam entries are blocked before they reach your inbox.
It’s turned on by default for new forms, but it’s worth confirming.
Open your form, go to Settings » Spam Protection and Security, and make sure ‘Enable modern anti-spam protection’ is switched on.

This is a modern version of the Honeypot technology which most WordPress form plugins come with, so it may be labeled as Honeypot in another form tool that you might be using.
Enable a CAPTCHA on Your Contact Form
More aggressive bots mimic human browsing and slip past the invisible token. Adding a visible CAPTCHA field stops them by forcing a challenge they can’t read or solve.
WPForms has both Cloudflare Turnstile and Google reCAPTCHA built in, and we default to Turnstile here. It’s free for everyone and runs its checks in the background, so most real visitors pass without solving a puzzle.
To set it up, go to WPForms » Settings » CAPTCHA and choose ‘Cloudflare Turnstile’.

Then add the Site Key and Secret Key from your Cloudflare account, and save your settings.
Finally, add the CAPTCHA field to each form you want to protect.

For a full walkthrough, see our guide on how to add Cloudflare Turnstile CAPTCHA in WordPress.
Google reCAPTCHA is also selectable on that same WPForms » Settings » CAPTCHA screen. We default to Turnstile because it’s free without limits, but reCAPTCHA still works if you prefer it.
If you’d rather not send visitor data to Google or Cloudflare, then WPForms’ Custom Captcha field (available on any paid plan) builds the challenge on your own server instead.
Add the field, then set it to a random math problem or your own question and answer.

Use Time-Based Behavioral Checks to Stop Contact Form Spam
A real person needs several seconds to read a question and fill out a form, while a bot submits in a fraction of a second. Time-based checks flag those impossibly fast submissions without changing anything the visitor sees.
With WPForms, the ‘Enable minimum time to submit’ option is enabled by default with a minimum time to submit of 2 seconds. However, you can update the minimum time to any value you like.

Block Form Submission by Country, IP, Email Address, and More
Some spam form submissions still gets through unless you screen the content itself. In the Pro version, WPForms lets you block entries by specific email address, by keyword, and by country or IP address.
To block a sender, open your form, select the Email field, open the Advanced tab, choose Denylist, and enter the addresses or domains to ban. A wildcard like *@example.com blocks an entire domain.

To block spammy phrases, go to Settings » Spam Protection and Security.
Turn on ‘Enable keyword filter’, open ‘Edit keyword list’, and add each term on its own line.

And if you only serve certain regions, turn on ‘Enable country filter’ on the same screen to allow or deny locations.

Alternatively if your WordPress form solution doesn’t have this option, you can also block IP addresses in WordPress.
5. Stopping Spam User Registrations in WordPress (Best Practices)
On a membership site or WooCommerce store, spam registrations are more than a nuisance. Fake accounts clog your user database and skew your customer and email metrics.
Here’s what you can do to prevent spam user registrations in WordPress.
Turn Registration Off When You Do Not Need It
If you’re not running a membership site or an eCommerce store, then you likely don’t need to allow user registration. The easiest thing to prevent user registration spam there is to turn it off.
Simply go to Settings » General in your WordPress admin area, and uncheck the ‘Anyone can register’ box.

Require Email Confirmation Before an Account Activates
If you do need open registration, then the goal is to let only real people in while keeping spam bots out. The setting that stops the most fake signups is requiring a confirmed email address, or a manual review, before an account goes live.
Where that control lives depends on what plugin you’re using to manage user registration in WordPress. You will want to start with your platform’s default setting instead of bolting a general form plugin onto a system that already handles this.
If you run a WooCommerce store, then go to WooCommerce » Settings » Accounts & Privacy. This is where you decide whether shoppers can create an account at all, limit account creation to checkout, or keep guest checkout on so no account creation is needed.

WooCommerce core doesn’t add a separate email-confirmation step on its own. If you want one, then you’ll need a custom email verification extension or the custom signup form covered below.
Other membership and course platforms handle account verification in their own settings, so start there:
- MemberPress: WordPress creates the account on registration, so pair it with the free User Verification plugin to keep the account inactive until the person confirms their email. See MemberPress’ documentation for the full details.
- BuddyPress and BuddyBoss: email activation is built in, so new members stay inactive until they click the activation link. Enable registration under Settings » General (BuddyPress) or BuddyBoss » Settings » Login & Registration. See BuddyPress documentation and BuddyBoss documentation for more details.
- LearnDash: registration runs on WordPress’s own user system, so there’s no native email-confirmation step. An account goes live the moment someone signs up. To hold new accounts until the email is verified, add that check at the WordPress or form level, using a user verification plugin or the custom WPForms registration form covered below.
If you’re building a custom registration form rather than using one of the systems above, then you can use WPForms User Registration addon which lets you turn on email activation under the form’s User Registration settings, with either an email confirmation link or manual admin approval.

Similar options are available in Gravity Forms, WSForm, and other popular WordPress form plugins. For the full walkthrough, see our guide on how to moderate new user registrations.
Add CAPTCHA and Honeypot to WordPress Signup Form
The same tips that protect your WordPress contact forms also work on WordPress signup form. Since you already set up Cloudflare Turnstile earlier, you can switch it on for your registration form in a click.
For a dedicated walkthrough, see our guide on how to add a CAPTCHA to your login and registration forms.
If you’re using the default WordPress registration page, then you can add hidden honeypot fields to your registration form with the free WP Armour plugin. The plugin logs every bot it blocks under WP Armour » Statistics.

Use AI-Powered Tools for Blocking WordPress Registration Spam
Honeypots and CAPTCHAs stop obvious bots, but they can’t spot someone signing up with a throwaway email or from a known-bad IP address.
That’s where automated detection helps. It screens each new signup against live reputation data and blocks the ones that look fraudulent.
ActiveLayer and CleanTalk both offer this for WordPress registrations, and you can switch it on for your signup form the same way you did for your contact forms.
6. Add a Site-Wide WordPress Firewall
A Web Application Firewall (WAF) screens every visitor and blocks malicious requests before they reach your site. Since most form spam is automated, a good firewall can stop a lot of it at the perimeter.
We recommend a DNS-level firewall, which filters traffic on the provider’s network before it touches your server.
On WPBeginner, we use Cloudflare, which has a free plan with basic firewall protection (setup requires pointing your domain’s nameservers to Cloudflare).

Our guide on how to set up the free Cloudflare CDN and firewall walks through it.
Plus, our roundup of the best WordPress firewall plugins compares the other options if you want to weigh them up.
7. Cleanup WordPress Spam and Ongoing Monitoring
Stopping new spam is only half the job. If you’re like most websites, you already have a backlog of old junk that needs cleaning up.
A quick cleanup keeps your database tidy and helps your new tools run at their best.
🚨 Always create a complete WordPress backup before deleting anything in bulk. These actions permanently wipe data, with no undo button if you make a mistake.
Bulk-Delete Existing Spam Comments
WordPress spam filter flags junk comments but doesn’t delete them, so they can build up in your spam folder and take up database space until you clear them out.
In your dashboard, go to Comments, click the ‘Spam’ filter at the top, and hit ‘Empty Spam’ to permanently clear everything your filters caught.

If you have thousands of junk comments, the dashboard can freeze or time out. A free plugin like WP Bulk Delete is faster and more reliable for big backlogs.
For other methods, see our guide on how to bulk delete WordPress comments.
Clean Out Existing Fake User Accounts
Leaving bot profiles in your database is a security risk and skews your analytics. That’s why it’s important to clean out these fake accounts.
For a handful, go to Users » All Users, click the ‘Subscriber’ user role filter (the role almost all registration bots use), select the fake accounts, and choose Delete from the ‘Bulk actions’ menu.
⚠️ Be very careful to select only fake Subscriber accounts, and never an Administrator account.

For thousands of accounts, the free WP Bulk Delete plugin can remove users by role, inactivity, or registration date in one sweep.
For more information, see our guide on how to bulk delete WordPress users by role.
Handle False Positives
No filter is perfect, so never auto-delete your spam folder without a quick glance first.
In Comments » Spam, hover over a legitimate comment and click ‘Not Spam’. That also teaches your filter to recognize similar comments as safe in the future.

Set a Monthly Anti-Spam Review Routine
A few minutes each month keeps spam from piling back up. Add these three checks to your maintenance routine:
- Scan for false positives: skim your spam comment folder and form entries so no real messages were caught by accident.
- Empty your spam folders: once you’ve rescued anything real, clear them to keep your database lean.
- Check your user list: glance at new registrations for gibberish usernames or suspicious email domains that slipped through.
Key Takeaways
Here is a summary of the best practices we have covered to completely protect your WordPress website from spam:
- Start with free WordPress settings: turn on comment moderation, tighten your link limits, build a comment blocklist, and disable trackbacks. These cost nothing and clear out the easiest spam.
- Use automated, invisible filtering: a server-side tool like ActiveLayer, Akismet, or CleanTalk blocks bots in the background without making real visitors solve puzzles.
- Layer your contact form defenses: honeypots alone no longer stop modern bots, so combine them with timing checks, token validation, and an automated filter.
- Secure your registrations: require email confirmation for new accounts and screen every signup with an automated tool.
- Add a site-wide firewall: a DNS-level firewall like Cloudflare blocks a lot of automated spam at the perimeter, before it ever reaches your forms.
- Run regular cleanup: bulk-delete old spam comments and fake accounts, then spend a few minutes each month checking for false positives.
Frequently Asked Questions About WordPress Spam Protection
Is free Akismet-style filtering enough, or do I need
more?
For a small personal blog with only comment spam, a single free filter like Akismet is usually enough. Once you add contact forms, signup forms, or user registration, you’ll want a service that protects those too, like ActiveLayer or CleanTalk.
Will adding a CAPTCHA hurt my form conversions?
It can. The extra step causes some real visitors to give up on the form. This is why we prefer invisible, server-side detection that blocks bots without asking anyone to solve a puzzle.
Why am I still getting spam after installing an anti-spam
plugin?
Usually because the plugin only guards one entry point. If it protects your
comments but not your signup or contact forms, bots just move to those
instead, and older tricks like basic honeypots no longer stop modern bots. The
fix is a layered setup: your built-in WordPress settings, an automated
filter, and a firewall working together.
How do I stop fake user registrations without turning off signups
completely?
Turn on email confirmation so new accounts stay inactive until the person
clicks a link in their inbox, which bots can’t do. Pair it with a honeypot and
an automated filter, and real people can still sign up freely.
Can spam actually hurt my SEO or get my site
blacklisted?
It can, but it depends on where the spam is. Comment spam sitting in your moderation queue is never published, so search engines never see it and your SEO stays safe.
Published spam is the real risk, because it can slowly pull down your rankings. WordPress does tag comment links as nofollow, which limits the damage.
We hope this article helped you learn how to protect your WordPress website against spam. You may also want to check out our ultimate WordPress security guide to improve your website security.
If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.
The post Ultimate WordPress Spam Protection Guide – Step by Step (2026) first appeared on WPBeginner.

The latest episode is 