Page Builder Accessibility Report: 2025 Update: Amber Hinds

>> PAOLA GONZALEZ: Welcome, everyone, to WordPress Accessibility Meetup Page Builder Accessibility Report: 2025 Update with Amber Hinds. We have a few announcements today. Our Facebook group is the best place to connect between meetups. You can find it on facebook.com/groups/wordpress.accessibility. We talk about anything and everything web accessibility, most times related to WordPress. You can find upcoming events and past recordings in one place. Yes, this meetup is being recorded, and you can find it in about two weeks at equalizedigital.com/meetup, and you can also find all our past recordings over there as well. You can join our email list to get news and event announcements at equalizedigital.com/focus-state. We send a weekly newsletter and event announcements over there. You can tune in to our podcast, where every other week we release the audio version of meetups. Also, we have talks about anything related to accessibility. You can find that at accessibilitycraft.com. We are seeking additional sponsors for the meetup, so if this is something that you’re interested in sponsoring for captions or ASL, you can contact us at meetup@equalizedigital.com. That email goes to both me and Amber, and that also works if you have any suggestions for the meetup or need any additional accommodations.

Who are we? We are the organizers of Meetup Equalize Digital. We are a mission-driven organization and a corporate member of the IAAP, focused on WordPress Accessibility. We are the proud owners of the WordPress plugin, Accessibility Checker, that helps you find and fix problems on your site. We also have online courses for NVDA and VoiceOver screen reader testing. We also have accessibility audits, remediation, and consulting. You can find us at equalizedigital.com.

We would like to thank our live captioning sponsor for today, GoDaddy. GoDaddy’s mission is to empower a worldwide community of entrepreneurs by giving them all the help and tools they need to grow online, including a simpler, safer WordPress experience. GoDaddy provides a managed WordPress experience that is as easy as it is effective. The latest version of WordPress comes pre-installed with exclusive themes, plugins, and tools to get you up and running quickly with automated backups, updates, and malware removal, so our pros can spend less time on monotonous maintenance and more time building their business. You can find them at godaddy.com.

We always encourage attendees to go on the social medias and find GoDaddy and just thank them for sponsoring Meetup. A few announcements for our upcoming events. First of all, we’re going to be canceling the evening meetups for the remainder of the year. This is based on the form that we sent out recently, and the feedback just pretty much pointed to very low attendance for those meetups. At the beginning of next year in 2026, we’re going to be looking in to see what other place, what other time we can use for our second meetup.

In the meantime, we do have a few meetups coming up. We have We Need to Talk About Captions with Piccia Neri. That’s going to be on Thursday, September 4th at 10:00 AM. U.S. Central. We also have Convince Your Clients for Accessibility: Arguments and Business Cases. That’s going to be on Thursday, October 2nd at 10:00 AM U.S. Central as well. Without further ado, I would like to introduce today’s speaker, Amber Hinds. She is the CEO of Equalize Digital, and through her work at Equalize Digital, Amber is striving to create a world where all people have equal access to information and tools on the internet, regardless of ability. Amber, take it away.

I’m going to stop sharing. I’ll let everyone know that if you have any questions during the presentation, please pop them in the Q&A box. Makes it easier for us to monitor them. With that, Amber, take it away.

>> AMBER HINDS: Great. Thank you. Hopefully, you can see this presentation. I’m going to tell you all I am notoriously bad for paying attention to the chat while I am presenting or talking. Oh gosh, and also I like to scroll my slides. Please do use the Q&A. We’ll definitely get questions at the end, but I probably won’t be very good at seeing them along the way. I am really excited to be presenting this updated report and publishing it tomorrow, publicly for everyone. It has been a labor of love for myself and our content specialist, Maria, who you may have met during a meetup earlier in June, I think, when she presented on ARIA for Beginners. She and I have spent a lot of time testing a lot of different builders for accessibility.

Let’s talk a little bit about why we did that. Our goal with this report, when I first created it and continues to today, is twofold. First, we want to help website owners and developers identify tools that provide the best starting point for accessibility. As I will emphasize later on, it is true that you can make anything accessible, but it is definitely easier to build accessible websites if you start from a good starting point. Our hope is that it will help to highlight tools and builders that are doing a good job and make it easier, especially for maybe non-technical people, to do that.

Now, what if you’re already using one of these builders? Then our second goal for this is we’re hoping that this will alert you to problems that may exist in your current theme or plugin setup on your existing website. This doesn’t necessarily mean, depending on what the problems are, that you have to scratch the entire site or start over. We’re hoping that you can take this information if you find out, “Oh, I am using that builder, and oh, its accordions are not accessible, and I have a lot of them.” Go take that and test your own. Determine if that same problem exists on your site, and then come up with a plan for fixing it. We’re really hoping that this will provide useful information for you both in long-range planning, but also in short-term assessment of your own website.

What’s different this year? If you’ve seen last year’s reports, you know, of course, that we only tested 10 builders. This year, because I had Maria helping me, we were able to test a total of 19 builders, which was a huge task, but one that I’m really excited to do because we had a lot of questions and a lot of feedback from people saying, “Hey, we really wish XYZ had been included.” We went and were able to include more. We couldn’t quite get everything in because I had thoughts about others that I also wanted to test, and time became a reality, but I’m really proud that we have tested nine additional builders this year.

The other big change is that, to our list of components, we also added forms. Last year, when I gave this report, I said we did not test forms because I feel strongly that you should use a form plugin and not whatever form builder is built into your page builder. I still feel that way. I think form plugins are going to give you a lot more control over what you can build. They’re going to have more types of fields. They’re going to have more options for how data is stored or where it’s sent, and allow you to do lots of really cool complex things, like have someone submit a form and it create a draft post on your website, for example.

The reality is that when page builders include forms in their demo content or their theme starter kits or whatever individual builders might call it, a lot of website owners are going to use that form particularly on small local business websites where maybe they don’t need that complex functionality, like I was talking about and all they need is a basic contact form. I realized that because that is the reality of how websites are built, we can’t ignore how accessible forms are in these individual builders. As a result, we added that component to this year’s test.

We also did a lot more thorough accessibility-ready testing. These are based on the new-ish accessibility-ready requirements. I say new-ish because they haven’t been totally publicly published yet. If you’ve been at some WordCamps, particularly WordCamp Europe, a lot of people there helped us test and gave feedback on it. It should be coming to the accessibility blog on Make WordPress this week or next week. I’ll post more about them and getting public feedback, and then they will be published. We were being future-looking and we tested to all of those requirements.

This also means that we did a lot more testing of things that are theme-oriented versus just a block or a widget. We looked at what does the blog archive look like, what is a search results page, what does the 404 page look like, so doing a lot more tests related to themes as well. Of course, as I mentioned, things were tested by two people instead of one, which I think is a strength of this, because it’s not just my opinion, it’s multiple people looking at it. Also, I will say, on Friday, my friend Alex Stein and I got on with my partner Steve, and he tried out a couple of them with his screen reader as well. We’ve had more people looking at these.

Then, on that note, we also have public testing sites that will be made available to you this evening. I’ll show you more about them. Last year, I did all of the testing on my own computer, just on a local install, and I swapped out. I didn’t maintain the sites, which was very smart if you think about time investment to create them, but I just used one and then I overwrote it and tested another one. This time, we have a whole setup with a WordPress multi-site with subsites for every builder, so that anyone can go see what we were seeing that resulted in the score or the test. This is, I think, important for helping it to verify that what we’re saying is truthful.

I will fully admit that this was driven by one of the builders having a community, who got really mad about their ranking. Now, the builder itself did not get mad, they said, “Oh yes, these are problems.” They fixed them, which is amazing, but their community got really mad, and they’re like, “No, this is wrong, it’s a lie.” In order to help people understand, I was like, “I’m going to provide you with the actual sites where we did the testing, so that you can then go vet what we’re saying if that is important to you.”

I also just think it’s really interesting to look at what base installs of each of these different builders look like with the same content, which I’ll talk more about in just a minute. Then we have a lot more detailed reporting, which I’ll show. I did include, after some thought and consideration, a WordPress core baseline that can be compared against, which is, how does WordPress core, with just the default theme, stack up on all of these tests?

What builders did we test? Just to make sure I get this in the audio and for anyone who can’t see the slides, we tested Avada, Beaver Builder, Breakdance, Bricks, Brizy, Divi, Elementor, GeneratePress theme with the Generate Blocks plugin, Greenshift, Greyd, Kadence, Live Composer, Oxygen, and this was Oxygen Classic, because that’s what I had access to, SeedProd, SiteOrigin Page Builder, the Spectra block collection inside the Astra theme, Themify, Thrive Architect, and WPBakery.

One of the things when I was getting ready to set this up was I really wanted to make sure that we had as much of an apples-to-apples comparison. I spent a lot of time thinking about what the baseline content can be and ensuring that every single sub-site on the multi-site had identical posts and pages and identical navigation across all of the sites. If I had spun up, like Elementor, for example, they have these really great theme kits that you can just instantly install, and it’ll build out your header and footer. Some of these builders, I think Elementor does this too, will create fake blog posts and things like that, and fake homepages.

Well, the problem with that is that content is not identical across all of them, and a lot of times, those demo content includes accessibility problems. I wanted to make sure that we were starting with a baseline of no accessibility problems in the content. Everything that was added, I had ChatGPT help me generate a bunch of content I could use for blog posts, so that I would have those available when I tested a blog, like latest post block, for example. Then I made a bunch of placeholder pages so I’d have pages to link to in the navigation, but they have no content on them.

Really, I made sure that everything that was added followed all the best practices. I used headings correctly. All of the images had accurate, meaningful, quality alternative text on it. Everything was inserted in that way so that I knew that the content I was starting with wouldn’t flag any automated accessibility issues. All of the sites were running Accessibility Checker on them. We actually have it filtered in a way that, without even logging in, you can view on any page the Accessibility Checker reports. All of them scored 100% in Accessibility Checker before we installed the builder.

Then the next decision I had to make for some of these builders was what theme to use them with. Some of them, like Divi, Divi is a theme, and you don’t need a separate plugin necessarily. Some of them are plugins only and so, then you have to choose what theme to do with them. The way we approached this was if there is a theme that is intended to be used with that builder or comes from the developer of the builder, then that was the theme we used.

The examples I have written here are with Elementor, we tested it in Hello Elementor. Kadence Blocks was tested in the Kadence theme, one I mentioned before. Spectre was tested in Astra because they both come from the same company, Brainstorm Force. There were a couple of builders that did not have companion themes with them. WPBakery is one example. They are actually a builder team that reached out to me and said, “Hey, would you include my thing?” Which I love because I love when plugin developers are interested in learning and making their work better.

I said to them, “Yes, but what theme should I test it in?” They said, “Well, you can use it in anything.” That’s what makes WPBakery so great. You don’t have to go use a WPBakery theme. I spent a lot of time thinking about this. What I ended up deciding was, for the builders that don’t have a specific theme they’re intended to be used with, I was just going to test them within the Twenty Twenty-Five, which is the default theme when you install WordPress right now. It also has the accessibility-ready tag and should, in theory, not add any problems to the builder. The idea then is that we are really only, again, seeing things that come from the builder itself.

Once I had it all installed and I had the theme, of course, I had to set it up and build it. I will show you some of these in just a little bit. One of the decision points that I had to make for some of them was what theme might I use? A couple of them had a few options, or what templates could I start with for the headers and footers? I tried as much as possible when selecting those to not choose ones where it was clear it was going to have contrast issues.

I will say I got surprised by one of them. It looked like it was all yellow and black, with either yellow on black or black on yellow. Then I installed it, and surprise, the links were yellow too. Sometimes that happens, but I did try to not choose something that looked like it would have accessibility problems. Because I’m trying to give them the benefit of the doubt, and let’s test the best-case scenario.

I went through the headers and footers on anything that I had to start with, and I made sure that all images had alt text. A couple of them had a logo in the footer that obviously would have been replaced if you’re using this website. It was linked to the home page. They didn’t bother to put alt text because they know you’re going to replace it. Well, if I do that, then it’s going to scan and it’s going to say, “Linked image missing alt text.”

I went through to remove any false positives there. I updated any filler links or social links to have real URLs, so nothing is linking to just a hashtag. They’re either real URLs or I straight up removed extra footer menus that I’m like, “I don’t need to spend time figuring out how to link these to fake pages.” That they won’t flag accessibility text. I removed obvious things that were just going to create noise in reports and in our own manual testing.

I did not change some other things. Things that I did not change were the default colors and the link styles. The reason for this is that when we’re testing accessibility-ready requirements, the default colors are what gets checked and the default link styles. Some builders have an option in a settings panel in the customizer or somewhere else, where you can say, “Underline my links.” If by default, that was not the option when the builder is installed, I did not turn it on. They would get a fail for that because again, what we’re trying to do is set people up for success with a default that is accessible.

Now, when we’re talking about the reports in a while and looking at the data, I think this is just something that you have to keep in mind because some accessibility problems are easier to fix than others. That is one that is very easy to fix, even if there’s no setting. It’s great if there’s a setting, but if there’s no setting, you can use very simple CSS. If you don’t know how to do that, you can usually ask some AI or chat GPT, like, “How do I add underlines to links and remove them on hover with CSS?” They’ll give you a little code snippet and go paste it in somewhere on your site.

Obviously, if that’s there, color failings, contrast is again easy to fix, and also something you might not care about when you’re selecting a builder, because you know that you’re going to change those anyway to match the branding of the site. The reason why I left them is because if they were going to try and go for an accessibility-ready tag on WordPress.org, that is a requirement in order to get that tag.

My hope is that they will fix these things and try to be accessible out of the box by default. Obviously, you have to assess your own skill set, whether or not these specific issues matter to you when reviewing a builder. All of the components are on a components page. I just have a heading two above it. If no component exists, there’s just a sentence saying, “No slider is available in this plugin.”

Then any content that was entered in them is identical as much as was literally possible. What does that mean? It means that every accordion group that I looked at has three accordions. They have accordion one for the title, accordion two, accordion three. They have identical content in accordion one, identical content in accordion two, identical content in accordion three. Because again, I’m trying to create an apples-to-apples comparison, so that we don’t have any weird distractions by the content being different, and it really just shows you what the builder or theme can do.

Then none of these have third-party add-ons or components. This was something someone asked me last year about Divi. Well, but there’s a Divi accessibility plugin. Why don’t you test it with that turned on? The reason why I don’t test it with that is because I feel very strongly that people should not have to buy third-party add-ons to fix crappy code in their page builder. I’m literally saying that, crappy code, because it’s crappy code. The page builder should be accessible by default. They should not make you pay extra or go search the internet and find something on GitHub that you’re not sure if it’s going to work or not, to fix their failures.

Yes, there may be tools or extensions that have way better components or fix accessibility problems in these builders. The point is that the builder itself has the problems. Let’s go look at these sites. You can look at these yourself if you want. All you have to do is go to pagebuilders.equalizedigital.com. When you go there, you’re going to see the main site, and it’s just going to have a list and different sites you can go to. I’m going to take a look at Avada just so you can see. That’s our first one alphabetically, so we’re going to look at it.

In reality, from what I was talking about, I’ll explain or highlight a few things. Avada’s default colors are this light green. There are contrast failures with the light green on white, either white text on it or it on a white background. I didn’t change that. I did go through and make sure that all of these links, like Facebook, GitHub, LinkedIn, X, YouTube, these are all real links that go somewhere.

All of the themes have the same three menus, if I could get two menus in the top. Sometimes I couldn’t get two menus in the top, and as a result, they only have two navigation menus. I did target trying to have three menus. One is our utility menu. It only has one item, My Account. The other one in the primary has drop-downs with it. Blog has a drop-down. About actually has a double-layer drop-down. Our History has a child page that is just the sample page that comes.

Then there’s a builder’s drop-down, which is really big, which is super interesting to see how this works. On this Avada one, for example, you’ll notice it goes off the bottom of the page, and you literally cannot scroll to get to the bottom. You can’t see the final items on that. Now, again, if you don’t have down menus that are that long, it might not be a problem, or it could be in certain zoom situations or something else like that. Obviously, that’s something you want to look at. You’ll see some builders have no problem with this long menu that has 19 or 20 different links in it, but this particular one has an issue.

Then we had search if a header search component was available. Then, down at the bottom, we tried to have this particular one. I guess I didn’t get it on, or I couldn’t figure out how, or something. I’m not sure what. Normally, they have an extra nav menu at the bottom that has three links to Equalize Digital, Accessibility Checker, and Meetup or something. I can’t remember what they were. This is how this looks. They’re all on the homepage for you.

I coded a couple of shortcodes that do a few things, so that you can see what is on the site and what was tested, if you want to find that. The first shortcode is going to show you the active themes. For example, this is Avada version 7.12.2. You can see exactly what version the theme is. Then I have a list of every plugin that is active on the site with their versions. You can see exactly what is active on the website.

Then, down below, I’ve got the tested pages where you can see the different pages that we looked at for each one. They’re going to be identical on every site, but of course, they’ll look different. You could go to, for example, the Post Single, if you want to look at what post did we specifically look at when we were testing and what that content looked like. You can access these on all of the different sites.

When we were testing this, this is what our process looked like. We started out by running bulk automated scans using our Accessibility Checker plugin, because anything I can get to tell me this site has 500 color contrast errors, it’s really nice than to have to go try count them myself, or empty buttons, empty links, things like that. We did manually go through all of those. You can see on the front end of these sites, we’ve made Accessibility Checker visible to logged-out users, which normally it’s not, but that’s something we did in this instance.

We went through and removed any false positives or any manual check items. For example, there’s a couple of those short strings in some blog posts that I wasn’t paying attention to that would be like, “Is this a heading?” It would say, “Possible heading.” Well, we’ve ignored all that. The only things that are left open are things that we actually think are real accessibility problems on that site. We went through and reviewed all of those so that any counts we had were going to be very accurate for the builder.

Then, after we did that, we would review heading structure using the HeadingsMap browser extension. We reviewed landmarks in the Landmark Navigation browser extension. Then we did manual keyboard testing. Maria does screen reader testing with NVDA on Windows. I did VoiceOver on Mac. We had coverage of both Windows and Mac screen readers. Then we tested reflow with browser zoom, text resizing and spacing, and screen magnifier magnification techniques, those sorts of things. We were doing a lot of manual testing.

We also turned on reduced motion settings in the operating system and tested it to make sure that things like carousels didn’t autoplay or animations that might exist in other things were significantly reduced or completely gone with that setting turned on. It is really important. I want to highlight that this was a huge manual testing process. The reason for that is that automated tools are fabulous and can do amazing things, but they can’t find everything. I’ll highlight this for you.

I have Accessibility Checker open in the multi-site network admin, where I can see every sub-site. I can see across this how many issues exist. I currently have this sorted by the percent passed tests. This table has the site name on the left, the percent passed test, number of errors, number of warnings, number of contrast errors, and how many things have been ignored on a specific site. Ignored things might be, like I mentioned, a possible heading or aria-hidden. Something that’s a manual check that’s like, “Hey, a human has to go look at this and see if this is a problem or not.”

One that I always find so interesting, as an emphasis on why manual testing is important, is DIVI. DIVI, if you remember, in 2024, they were at the bottom of the pile. I think they only passed 12% or 15% of what we were testing for. They failed almost everything. In our automated checker, we’re seeing that they passed about 88% of the automated scans. There’s 248 errors. Obviously, there’s a lot of problems in those 12% of rules that they failed. There’s a lot of errors. There’s color contrast issues and things like that.

The WebAIM Million, if you’re not familiar with this, WebAIM is a nonprofit organization. Every year, they do automated test reports on the top million websites by traffic and what their accessibility status is. I always find this so interesting because, at their report for the last several years, they have a content management system and site builder section. They say that of all of the content management systems and builders, DIVI is about 45.9% better than the baseline, and it is the best of everything that they have tested. Then we go and we do all this manual testing, and we’re like, “Okay, no, it is obviously one of the worst.” Last year, it was the worst. You’ll find out in a little bit if it is.

I think it is really important. Automated testing is fabulous. Obviously. I saw a plugin that does it, but it’s not everything. It’s really important to do these manual tests as well. Any sort of reports like this that don’t include manual testing, like this situation here with the WebAIM Million, which I think is a fabulous, interesting report, but it includes no manual testing, I always take it with a grain of salt. If DIVI were to start being like, “Hey, we’re the best, look at this report,” I would be like, “No.” I do think it’s really important to include that.

While we were doing the testing, basically what we did was we went through all the different elements. I’ll show you them in just a few minutes on our sheet, but I want to explain first how we scored. We would give them either a pass, which means it literally meets exactly what we were looking for, and the specific thing we want, it does, and it does right. A fail, which means either the element or attribute was missing, it was not coded correctly, it’s clearly not meeting the accessibility check, or a concern. A concern is like, if you were to create an accessibility conformance report, you might write partially supports.

I would say for us, we’re writing a concern as something that mostly passes, generally would be a pass, but there’s some small part of it, or there’s some option in the builder that we think might lead a content creator to adding accessibility problems, or there’s just something about it that seems a little bit off, but it’s not a total failure. We tried not to give a lot of concerns. We tried very much to be, it either passes or it doesn’t pass, but there were some situations that weren’t that.

Then you’re also going to see not applicable in the report, which we abbreviate as an N/A, both capitalized. This is only given when an element or component doesn’t exist in the builder, or literally isn’t controlled in the builder, and so we can’t score it because there was nothing to test.

Let’s go look at this report. Everyone is going to be like, “How do I look at this sheet?” Because I know you’re not going to be able to read it all now. Because I don’t want this data to leak, I will be giving you this sheet tomorrow. Everyone who is here, you’ll get an email from me with a link to the sheet so that you can access all of it tomorrow. This is your private preview, but I don’t want it to go out before the post publishes tomorrow morning. Just so you know, that is the scenario.

As I mentioned, this is a lot more detailed than last year. Last year, we had one sheet. You’ll notice when you get access to this that there are five tabs, or I guess tab sheets, in the spreadsheet. The three in the middle are the ones that you most care about. I’m going to explain a little bit about what these are and give you some background and some information. Basically, on our summary sheet, what we have is some of the same information that is on the homepage of those public test sites. They tell you what theme and what version, what plugins and what version.

I also went and got the stats I could find from either BuiltWith or WordPress.org to tell you how much this particular builder or block library, and theme collection is used and active. I think this is really important because a page builder that is used on hundreds of thousands or millions of sites, if they fix their accessibility, they can make lots of sites better. If they don’t care about accessibility and they don’t do anything, they make a lot of sites on the web really, really bad.

I think it’s important to note this, which ones are doing a good job and have not enough installs, maybe we need to get them more installs, and which ones are doing a really poor job, and maybe have a lot of installs, and we ought to pressure them to try and help the millions of people. If it’s millions of websites, maybe it’s billions of people that interact with their builders every day. Also, on the summary, you can see what components were available. Not every plugin has a carousel, not everyone has a testimonials block, different sorts of things. You can see what was tested.

Then we have the numbers that come from Accessibility Checker, and then from the component and the accessibility-ready tabs. Let me jump over there. When I said we did scoring, you can see this is what this looks like. I’m on the components tab right now. I can see navigation and all of the items that were checked down the left. Then, going across, there’s a column for every builder. We can see pass, fail, if there’s notes about what it is, not applicable, going across.

You all will have to forgive me for a second because I totally forgot the order. Let me talk about this in just a little bit more detail, what specific things we tested. Many of the items are the same as last year. If you read last year’s report or watched last year’s video, then you probably know a lot of this. I’m not going to go line by line everything because there are 500 rows of tests, but I’ll high-level and I’ll point out a few things that are different. I’ll explain a few things that I want to point out that I think are worth mentioning.

In the navigation, we’re looking for things like having a navigation tag. Is it labeled? We want to know if the user can define the navigation tab. Why is that, or can they define the aria-label for the navigation tag? The reason why is that in certain scenarios, particularly in a footer, if you have a bunch of different nav menus, it’s helpful to actually give them a name that means something, like Footer Navigation 1. It technically passes on having a unique name, but it doesn’t mean anything to a user on a screen reader who’s trying to decide which navigation to go to. We’re hoping that they’ll be able to support that.

We want dropdowns to be keyboard accessible, separate buttons for opening and closing them. This is one that everyone always asks me about. CTA buttons or styles achievable in the primary navigation without requiring custom CSS. Let me go show you this just on our baseline. I think is actually a good example, because not too long ago, WordPress added the ability to add a button block into a navigation.

Why is it so important that a builder support this? The reason why is many of us– I think my website has this. Probably almost all of you, your websites have this link that looks like a button for your most important page, your sales page, your get it now, your contact us page, whatever that is. If this is easy to do in the builder, then what we get is a navigation. Oh, well, this is a little– I was hoping, but it covers it. I’ll just show you. A navigation tag that includes that link. Then, if I am searching using my nav as a screen reader user, I hear all of the items that are actually in my navigation, including the most important one.

When a builder does not have an easy way for a user to do this, what do they do? Most commonly in WordPress, they make their navigation be the items that look like links. Then they add a widget area or another column, and they insert a button block or they insert it in some other way, adjacent. What happens is, this most important thing on your website is no longer in your nav tag. That’s why that is actually really important.

For that particular one, I tried a lot of things, like, did they have a way to do it, did they have styles for it? Then I just tried things like, can I add a button class, multiple button classes, to see what they do? A few of them actually did a fairly good job. They don’t necessarily have all of the styles. Oops, I missed the S. They don’t necessarily have all of the hover styles and things like that.

Again, I didn’t spend a bunch of time styling or tweaking them, but I’m on Bricks right now, for example. All I did was put a button class in the normal WordPress menu, and now it’s got a yellow square background on it and it’s all highlighted. Obviously, there’s some alignment. You’d tweak it before you launched it. To me, this is good enough it’s passed. It could probably be even better. That said, this is way better than we saw in Avada one. It has the button class, but it doesn’t look any different. I tried a whole bunch of ways, and I couldn’t figure it out. That’s what that is.

Let’s see. We tested the header search. Nothing on this really significantly changed from last year. Basically, we want everything that should be a button to be a button. We want them to all have meaningful names. We want the search field to be labeled. We want to make sure that everything for everything you’re going to hear that has a visible focus works on zoom. We checked everything in that way. If it was an overlay, we wanted to make sure that it had a focus lock and a screen reader lock, that sort of thing.

We looked at accordions. We want accordions to be buttons with headings because that helps from a navigation. You’ll notice there was one item where we flagged it does function, but it uses a disclosure block, but that is a concern. Why is that? It’s because screen readers, when they encounter disclosures, they say, “Disclosure triangle.” If you’re using it to create an FAQ page and you’ve got 25 FAQs, I don’t think you want somebody to hear the question and disclosure triangle, disclosure triangle, every single time. Disclosure patterns are really intended to be used as one-off, not a collection or a group. Even though technically it functions, that would get a concern on it.

You’ll notice on this one, WordPress core doesn’t have this block, so I don’t have anything to compare it to. We’re looking for things, like hidden content, not receiving focus. If we look at the components page for Bricks, for example, all of these– Now, Bricks is a little interesting because their default link styles have no colors, which is a little weird. This is a link. Oh, just maybe Equalize Digital is. Let me look at this on a different builder, actually. We’ll go back to Avada, because it makes it a little bit easier to see.

Nope, this one also doesn’t have– Well, that’s annoying. It has a hover style. Those are things. Out of the box, it should just do this. We put links in there to make sure that if it’s closed, it doesn’t receive focus and it’s read by a screen reader. Those are two separate items.

Then we looked at carousels and sliders, a lot of different things, but everything is exactly the same as last year, as far as the specific items that we’re asking of carousel sliders. Really, it’s about screen reader accessibility and also about motion. A lot of that. Having a pause button is a big one. That was something that frustrated me last year, and it continues to. Almost none of these builders have the ability, if you turn on autoplay, to also enable a pause button, which would be a failure.

Now, of course, if you don’t use a carousel or you use a carousel and you never turn on autoplay, it does not matter to you that your page builder doesn’t have a pause button. Again, if we want to set people up for success, and those of us that know clients or know typical users, a lot of people like to put carousels at the top of their homepage or other places. If they’re going to do that and there’s going to be an autoplay option, there should be an option to have a button to pause it.

For forms, I’ll talk about this a little bit more because this was our new edition this year. Let me see what is the best. Actually, we’ll look at this on Kadence. Not all of these builders had the ability to do the same kind of form, but I tried very hard to get a variety of fields. As much as I could, this is what I tried to do. I had a required name field, an optional company field, a required email field, an optional phone number field that actually expects a phone number format, a date picker field. The date picker field was optional. It’s labeled birthday. It also has a description that ought to be associated with it.

Some of the builders didn’t support adding this kind of helper text. You’ll see if you look at them, some of them don’t have this. A select field, a checkbox field, a text area, and a set of radios. There’s a combination here of required and not required intentionally, because we want to see what happens if we submit the form and nothing has been filled in. We wanted to cover a variety of different field types. Not all of the builders have all these field types. They’re not all totally apples to apples, but I tried as much as possible to get them all somewhat like this or as close as I could.

Then what we were looking at is all fields are keyboard operable, all fields are labeled visually. For screen readers, all field labels are aligned with the visual label, so there’s not one weird off somewhere in a weird place that it’s hard to tell what field it’s associated with. Field labels don’t rely on placeholder text. This is a note. I tried really hard to set these up and not just have placeholder text. If I could turn off placeholder text and choose a label instead, or just use a label but not turn off– I always did that. I was trying to follow accessibility best practices when I built these forms. I didn’t ever intentionally add problems to them. Any problem that is there is because I literally could not fix it when I was building them.

Required fields have a visual indicator. This one I didn’t intentionally add it. If the plugin doesn’t add it, then they just don’t have one, because I think this is something that ought to be handled the moment you toggle that box. I don’t think you should have to write required or add an asterisk manually when you’re writing your label. Required fields are programmatically required. Name field has an autocomplete attribute. Email field has an autocomplete attribute. Phone field has an autocomplete attribute. Then I checked to see if they had the ability to set custom autocomplete attributes on applicable fields. For example, could I add my own autocomplete attribute of organization to the company field?

All field descriptions are programmatically associated with the fields. You’ll note, as I mentioned, a lot of them didn’t actually have the ability to add those, or I missed it. I dug around in these a lot, but it seemed like a lot of them didn’t support that. Checkboxes were grouped in a field set and had a label. Radio inputs were also grouped in a field set and had a label. Errors were programmatically associated with fields. Errors were announced by screen readers. Error states didn’t rely on color alone. Error messages are persistent, meaning anything that–

Let me look at one of these. Breakdance. Let’s go take a look at Breakdance for just a second. Breakdance, I believe– We’ll just hit the submit here real quick. What this is using, and this is somewhat common in these builders, is it is using browser validation. When I hit the submit button without filling anything in, it just shows me an error message on the very first field, and none of the other required fields show me any sort of error. It does shift a screen reader user there, and you will hear that there’s an error there. What happens now is that I might not know that there’s any other errors until I submit the form again, and then it takes me to the next one.

Now, obviously, in this scenario, I would have probably not missed every field. If you imagine, particularly on a long field or something like that, if there are multiple errors, you want to get notified of multiple errors the first time, not every time. Browser validation is really easy to just say, “Do this,” when you’re building a form. It is not the best user experience, and it is not sufficient for accessibility. You really want to have a form plugin that actually creates its own error messages.

Kadence is a good example of this. They have a setting where you can turn off browser validation on their forms. Then what you get as a result is an error summary up at the top that’s read out by screen readers, links to jump to whatever fields were required, and then errors visually on every item that was missed. That is what that is, about error messages being persistent.

We want to know that success messages are announced by the screen reader. They’re actually read out. We want everything to have visible focus, everything working on zoom. Then, that appropriate focus management for errors and submission success. If you had one of those validation messages, do you shift focus to it, or is the user stuck somewhere else on a form? Like, after a message submits and they get a success message, but the form disappeared, have they been set there, or are they now lost and reset up at the header because the item they were focused on the submit button, has been removed from the page, and they weren’t sent anywhere else? That kind of thing.

That is forms. Icon list is the same as last year. It’s really just because everybody likes to put these in designs, so I test them. It’s pretty basic and easy, but I really just want it to be in a list. I want the icons to not be read by screen readers because they’re decorative. Loop and post blocks. I want to talk about this for a second because I use the latest post WordPress core block as my baseline. Because I’m going to go for the easy option, not the query loop block. You can do a lot more with the query loop block than you can with latest posts.

You’ll actually note that I gave WordPress core two fails on the latest posts block. One is that you literally, and I did not know this until I was testing this. I feel like I’m going to go open a GitHub issue for this in the Gutenberg repo. You literally can’t set the headings or the titles to any sort of heading. They’re just a P tag. There’s no option to do that. You have to use a query loop block if you want to control that, which is ridiculous to me.

The other thing that we looked at on these, last year, we called this a bonus, but really, I think it is most ideal, is whether there was any setting that would allow you to hide redundant links from screen readers. Some sort of card style linking, or maybe a link that’s after the post, so they can still access everything in the post, but then it’s positioned with CSS in a way that a sighted person could click anywhere, and it’s just one link. We looked at that as well. Whether or not the read more was ambiguous.

Then on tabs, this is exactly the same checks. It’s just making sure that they’re following the approved patterns for tabs using the appropriate roles and arias, and appropriate keyboard interaction. A thing I will note that is very interesting about some of these builders is that a lot of builders are either confusing and literally mixing up accordion and tab patterns, or they’re using tab patterns for their accordions as well.

Elementor did this, and it is incredibly irritating, I think, because the normal pattern for accordions is that you would be able to tab to every item. The normal pattern for tabs is that you use the arrow keys only. It’s really important to use the expected normal pattern for a component. We just gave these a concern. For example, on Beaver Builder, GeneratePress 2, you can see up here on the screen where they don’t use the arrow keys, they use the tabbing.

If it’s only one or two tabs, you might think, “What’s the big deal about having to tab through all these before you can get to the tab panel?” What if somebody puts a tab with 12 tabs on them? Now I have to tab 12 times before I can get to a link that I can see as a sighted-keyboard-only user in the tab panel that I really want to go to. It is technically keyboard-accessible, but it’s not the standard pattern.

If they’re doing the other way around, like what I was mentioning about Elementor with the accordions, I think on that one we actually straight up gave that a fail because it’s so unexpected that you can’t tab to those items. Some people won’t know, “Oh, the tabs don’t work. I should try arrow keys.” They’ll just be like, “These are broken.” It is really important to just feel like what is the expected keyboard interaction for an element, and to stick with that.

Then we looked at testimonials again. These are, as always, they’re the wild, wild rest. Some people, it’s a single testimonial block. Some people, it’s a group. Some people, it is a carousel, and it’s only a carousel. It’s very weird, and we have just a bunch of random tests to try and figure out, in whatever version of testimonial they provide to us, how accessible is it. That’s what we rated there. Then down at the bottom, we have our totals and our percent passing, which I’ll talk more about in just a minute. I want to show you the accessibility-ready sheet briefly and gloss over this. This is a modified version of what is going to be used for accessibility-ready reports.

People at WordCamp Europe have already tested this. The only thing that is different is that in the meaningful landmark rows, in that report, we have different pages go across the columns, but I couldn’t do that. I had to drop things down and make it extra long.. Basically, what we’re looking at is doing skip link testing. As I mentioned, we tested a lot of pages. We tested things like the Blog, the Post Single, the search results, the 404, which last year I didn’t look at those, or pay any attention. It was pretty much like, “What does the components page look like?” This year, we’re trying to make it a little bit more thorough.

We looked at landmark regions this year, which I don’t think we did last year. We checked those on all of the different pages. You can see different pages and pass, fails. Then we have high levels on keyboard navigation support. Now it is a note that there are some items that if they failed on the component, when we got to this, it might have been an automatic fail because if your dropdown didn’t work when we were testing the nav menu, well, then we know it’s also going to fail this item, dropdowns, modals and dialogues, receive focus when opened. That sort of thing.

Then we looked at whether controls with accessible names have accessible names and roles and states, the appropriate things. This is a big thing that was flagged. There were definitely builders that were using links instead of buttons or divs instead of buttons. That was something that flagged quite a bit on different ones. They might have gotten that dinged on one of their component tests or maybe on multiple of their component tests, and they would also get that dinged here in, would you be able to pass an accessibility-ready review? The answer is no. Then labeling form fields. This was not just related to the contact form. We also looked at any search form that existed in the builder or the theme, and also the comment form on the post that was linked in our list of pages that we tested. We looked at the comment forms as well. Then we looked at whether headings follow a meaningful structure. For the most part, I would hope and expect these to all pass because, like I said, I didn’t add any headings in the order. Even on the page that I built out, the components page, they were automatically– I put each block under an H2. I worked hard to try and create it right.

Where we saw some failures for that was sometimes on the blog pages or the 404 pages, there’s not an H1. You got to have an H1 on every page. The components page on some of these, so Elementor, for example, on the components page, this is one instance where I did intentionally choose something I knew had issues only because I wanted to highlight it, which is they have one of their page templates where it strips out benefits of the themes. The hello theme has skip links and it has a main, and it automatically puts the H1 in.

If you choose a specific page template, then none of that exists and you have to build it yourself. We don’t give that a fail, but I did give it a concern because people have to know to put an H1. Those of us who build websites, we’re like, of course, everyone would do that. Except I can’t tell you how many websites I’ve audited where the first heading on a page is an H2 or an H3 because someone liked the size of it better. They’re like, oh, I’ll just make the title of the page an H3 because I like how small this is, or it’s blue and the other ones are black and I want the blue one.

Again, we want to set people up for success, which means I would default to always having a heading or a title on the page in an H1 and then have a setting if someone needs to hide that, just toggle that off in the page settings and say hide heading, and then they can put in their own. Then if they do it wrong, they’re breaking it, not you. That sort of thing. This is one of the other things that I thought was super interesting. This came out of 2025 and I was like, I feel like this needs to be rethought. The default on 2025 is that on the blog archive pages, it shows all of the content. This is interesting, so I’ll show you this.

It’s like little details that maybe people don’t think about. I mistyped that. [silence] This is what this looks like. It puts the entire blog content. This is something that someone who was building this theme, when they opened up FSE, they made a choice to do this instead of showing excerpts and “read more” buttons. The interesting thing about this is when you do this, all of our headings are now in wrong order because we get the post title as a H2 and then the appropriate heading levels under the post title in the post scenario where the post title is an H1 are H2s, but now they’re not nested appropriately on this particular page.

It’s an interesting thing that when you’re building this stuff out, you have to think about how certain content can be pulled. I would argue there’s almost no reason to show entire blog posts on your blog archive page, and whoever made this the default for this theme, not a super great decision, but it is interesting. I put that as a concern. It’s only that one page. All of the rest were fine, so it wasn’t a total fail, but there’s definitely a note there on that.

I’ve talked a lot about links. Basically we want to see that they are underlined when they’re in content or somewhere near text where you wouldn’t be able to distinguish and that they don’t rely on color on hover. Either the underline goes away or the underline moves down, or they could have put an icon, a little arrow pointing to the right when you hover over it, whatever that is.

We looked at those in a variety of areas on the site, looking at all of the “read more” links, making sure that’s not ambiguous. Color contrast, what those default colors did, and then some checks related to alternative text and whether decorative elements or icons or font icons were treated decorative. Then accessible animations, parallax. Some of this stuff started to become not applicable because we didn’t add videos or things.

Then the support for reflow, resized text spacing, that was the stuff I talked about, and there’s specific lists here of each thing we checked. I did find a failure that I’m going to open for WordPress Core on that, which is that at 400% zoom, when you’ve got that header search up here and you open it, it actually cuts off the input and the text that is available there. Again, even WordPress Core occasionally has some problems. I think it’s still a decent baseline, but it’s not like it started at 100% and was totally perfect, free of problems.

No unexpected changes of context. No links opening new windows or tabs without warning. As a best practice, I don’t think any builders should be doing this at all, ever. If they want to provide a setting that allows users to open links in new tabs, they should do that, but even the social media links should not. We do allow themes to pass and get the “accessibility ready” tag if they open links in new tabs by default, as long as they have both a visual and an auditory announcement. Then we will allow the theme to have the tag. It is most easiest for theme developers and plugin developers to just not do it, and then you don’t have to build that functionality in. That’s what I would recommend.

The next set of checks was about content on hover and focus. Almost none of the builders had content on hover or focus. I think there were two. It was Avada and Grade. Yes, they used it in their forms for the helper or the description test. Avada failed all of them, and Grade did it right. If you want to see two different examples, those would be the two to look at. Then there’s an item related to the accessibility statement. This is a new requirement that will be coming. We gave it a not applicable for everyone because that’s not a published requirement, so no one should be expected to have done that.

We did check to see if they supported screen reader text, which you can see simply on the bottom of the components page. We basically have headings, and we have two different classes that we’ve associated with subtext to see does it hide, and then we listen to it with the screen reader to make sure that it’s hidden the right way and it still reads out with the screen reader. I think they all had screen reader text, and passed it. They all did. WPBakery, that was not applicable because that comes from the theme, not from their builder. That is all the things we looked at, which is a huge amount of things.

Let’s talk real quick about scoring and ranking. Something I want to highlight here is everything got a flat one count. This is not a weighted score. Obviously, there are some things that we put on there that are more annoying. For example, does the aria-label on your landmark regions include the name of the landmark, like having the word “navigation” in your aria-label for a navigation tag? That is annoying. That is not going to block anyone in the same way that an empty button would, or it did instead of a button. Not all of these are totally equal, but for our purposes, we were just looking at what is the quantity.

I think that is something that is important to keep in mind because it is possible with this number of builders and how close some of them are that if you went in and you looked at certain types of problems, you could very quickly see that something that looked a little better, builder A looked a little better than builder B, but actually builder B has more of just the annoying things and builder A fails some of the really bad things. They could rank a little differently than what we have.

Basically, what we do is we calculate the percentage of passed checks. We take the number passed, we divide it by the total of pass and fail, and concern, and then we multiply it times 100 to get a percentage. The example I have up here is if you pass 3, there were 0 concerns and 9 failures, then there would be a 25% percent pass rate. Really, I do it this way instead of saying total pass because I do not want to penalize a builder for not having a component.

Basically, we are trying to figure out when they do build something, how good are they at building it, not how many things do you have. I don’t care if some builder doesn’t include a slider. Probably that’s great for the internet. That’s what we’re thinking of. Then I had both on the summary tab, there’s an average for the component, an average for accessibility ready, and then those get averaged together and that gives us a total percent passing.

I’ve made you listen to me for an hour and 15 minutes. Who won? This is the ranking right now as it stands from best to worst. I will read it out, so don’t worry if you cannot see the screen. I’m going to start with number one. I’ll read the page builder name and their percentage. Kadence got 100% on their test. I will note on this that, full transparency, Stellar has been paying us to audit many of plugins and they are fixing problems very quickly. It might seem like an unfair advantage, except for the fact that any of these builders could hire an accessibility consultant, not just me, and fix all of their things.

Several of these builders had the same report from last year, so they had all of the information. some acted on it and some didn’t. I do think it’s fair saying part of why they have a 100% is because they have decided to invest in accessibility, to the degree that on Friday, Alex Stein, screen reader tested a couple things and told me, “I don’t think this is super great.” Then I told them, and then today they released an update that fixed all of those things. They clearly care about it, and I think that shows.

Anyway, so Kadence came in with 100%. Number two was GeneratePress/GenerateBlocks, 81.66%. Greyd, 77.28%. Elementor, 75.55%. Greenshift, 72.07%. Beaver Builder, 68.47%. Breakdance, 65.84%. Bricks, 63.57%. SiteOrigin Page Builder, 63.55%. Astra/Spectra, 63.01%. Avada, 59.68%. Themify Builder, 52.36%. WPBakery, 51.38%. Thrive Architect, 45.74%. Oxygen, classic, 41.95%. SeedProd, 39.05%. Divi, 36.24%. Live Composer, 32.22%. Brizy, 22.94%.

I’m going to say a few thoughts about this. One of the things that I immediately noticed is that many of the ones that scored at the top, not all, but many, are block editor-based, not building their own whole custom builder. I think that is an interesting thing. You’ll also notice that a lot of these are very, very close. Bricks, SiteOrigin, and Astra/Spectra all scored 63%-ish. They might have only been off by a few things. That’s where having that raw data is really important, because some of them might have bigger failures than others.

For example, in the Spectra builder, none of the labels are associated with form fields. If you’re building your forms with Spectra, all of your fields are completely unlabeled, even though they look like labels, and you’ve added labels in the editor. Hopefully, they’ll hear this and they’ll go fix that, and that will make it better. That is a thing to keep in mind. A lot of these are close, and as I said, you really got to go dig in and see what the specific issues were.

The other thing that I thought was really interesting, and this came up with two of them. Brizy and SeedProd are two that did not have themes with them, and I ended up testing them in 2025. if you dig into the numbers, you’ll see that you can start with an accessibility-ready theme that has landmark regions and has skip links, and a lot of the good things that you want to have on your website, and if you install an inaccessible page builder, all of that will be erased. You really got to be careful on that, because even if you choose an accessibility-ready theme, the page builder, if it’s taking over the header, taking over the footer, totally erasing everything the theme is doing, then you’re not going to get any benefit of that.

I will also call out, I think– oh, I should have thought about having– oh, I do, okay. Here, let me pull this up, because I do want to shout this out a little bit. Oh, wait, I got to escape from this. Pay attention here to this Beaver Builder number. Beaver Builder is at 68.47%. This is last year’s report. Last year, they were at 48%. Bricks is another one, 50% last year. I lost my slide. 63.57%. A lot of these companies, I think, or some of these companies are trying, and they are doing things to try and actively improve their accessibility, not just Kadence. There are other ones that are doing that, which I think is really awesome. They have gotten better. I think that is huge.

Accessibility is a journey. It is a process. It is something that work on over time. Obviously, there are large issues that need to be fixed for some of them, and I would hope they would do it as fast as they possibly could, but I see this as a positive that we are seeing some improvement in some of these builders. I think, as trends go, if we continue doing this, we might see some of these older ones. I think Avada actually scored higher relative last year. With more of the accessibility-ready checks and with forms added in, it has a lower percentage passing, and two of the builders that have been working harder have now gone surpassed it. It will be interesting to see how this goes over time.

An important note that I want to flag for all of you is, of course, this was not a complete accessibility audit of every page builder. It was a thorough audit of some, and I have that underlined and italicized, some selected components and key features. It is entirely possible that if you started testing a whole bunch of other things, one of these builders that looks really great might not look so good. Or if you tested a lot more on some of the ones that were lower, they might look a little better, maybe.

No page builder theme or plugin can guarantee full accessibility or legal compliance on its own. Even if you are using Kadence or one of the other ones that scored very high, it does not mean that your website will be accessible if you are not doing what you need to do when you make choices with that builder and when you enter content. Achieving and maintaining accessible websites requires proper content authoring practices, careful selection of additional plugins. Like I talked about, installing Brizy in 2025 will erase all the benefits of 2025.

That’s not just for your page builder. You could have the same thing happen if you install the wrong dark mode plugin, for example. I’m not saying that because I know there is one, I’m just trying to give you an example. Or if you pick an e-commerce plugin that’s not accessible to build out your site. You really have to be careful about what other plugins you add onto the site. Then, obviously, you need to do ongoing testing and remediation on a regular basis, especially as plugins get updated very regularly. They could be introducing problems even if you’re doing everything right with your content. That is really important to note.

Bottom line, what does all this mean for you? If you’re sitting here thinking I have one of the great ones or I have one of the bad ones, oh my gosh. Of course, laws around the world require websites to be accessible. If you’re building for clients, depending on what you saw here today or we’ll see tomorrow when I email you out all the data, it may be time to rethink your plugin and theme stack. I noted block-based builders tend to be better on the accessibility. I don’t know that they have to be, but they seem to be, which is really interesting. Elementor still does really well. It did well last year as well. It doesn’t mean that there can’t be good ones that aren’t block-based, but it is an interesting thing.

Most builders do need remediation in some areas. Whatever you’re using, if you saw this and you saw that there were issues related to a component, if you know you have that component on your website, I would go test it. I do want to highlight, though, that like I mentioned before, with the carousels and autoplay, it doesn’t matter to you if they don’t have a pause button if you never autoplay your carousels or you don’t use a carousel at all. Who cares that that component’s not accessible? You didn’t put it on your website.

If you are worried about accessibility either for yourself or your clients and there is a budget concern, the easiest way to improve accessibility on a budget is by simplifying your website. Remove. If you have accordions that don’t work, you don’t know how to custom build new ones, or you don’t want to, or you don’t want to pay a developer to do it, the easiest thing is to go on your FAQ page and instead of using accordions, just put a heading and have the answer to the question visible right there on the page. Who cares that they don’t function because you’re not using them anymore? You can remove more complex components and that will make your website better even without having to change your builder.

There are some things that have to be changed or have to have a plugin to remediate. That’s why we have some of the fixes that we have in accessibility checker. That’s why there’s plugins like the Divi accessibility plugin and different things like that. You can definitely do a lot just by simplifying and streamlining. Then I would say for everyone here and anyone watching this later, please start asking devs to fix accessibility issues in your product. They are going to listen a lot more to someone who pays them.

With the exception of one of these builders, I didn’t buy any of them. Or maybe I had bought it already because I have a client who’s using it. Mostly, they either gave them to me, which is awesome because I know they’re going to care about what I had to say. Some of them, I just like, they’re free and I just went and got them and I didn’t talk to them. Or I had a friend who had access to it give it to me for testing purposes. They’re not going to listen to me about fixing things. They’re way more likely to listen to someone who is their customer. Please, go say, these are things that you need to fix, please go fix them.

I will say tomorrow when the report is published, I would please ask you, don’t share the spreadsheet, please send them to our whole blog post and then they can opt in to get access to the spreadsheet and the example sites and everything. I also want to say, this is a little tease for WordPress Accessibility Day, which is coming up in October. If you haven’t heard of it, it is a phenomenal-free 24-hour online conference. One of the talks that we were going to have next year, or not next year, this year at WordPress Accessibility Day is about the Braille Institute’s website, which is generally accessible.

There’s one or two things that Alex and I were looking at it and we’re like, this needs to be improved. It is generally pretty good and usable for blind people. It is made for blind people and it is built with Divi. It doesn’t mean it was easy, it doesn’t mean it was cheap, but as it says here on the slide, anything can be made accessible depending upon your skill set or budget. You can do it no matter what builder you are using. It’s just some are easier than others.

That’s my info, which I think everybody has. I am going to stop sharing. I would be happy to answer any questions. I think we have our captioner for another 15 minutes. Maria is also here and can answer questions about things that she tested as well. Let me see. I might have to get you guys to turn your cameras back on. Paola and Maria. Do we have questions?

>> PAOLA: We do. Starting off, as a blind sole proprietor, I’m curious if you know which theme is the most accessible on the back end. Lately, I have been frustrated by how much effort it takes me to perform tasks I have been doing for years. Thanks, Max, the blind mower.

>> AMBER: I don’t, off the top of my head. I will say this is a gap. This is a thing that I have thought about testing because all we looked at is what creates the most accessible website, not what has the most accessible admin experience. Perhaps that is something that we can add in the or look into. I don’t know right now, Max, because I don’t have an honest answer and I don’t want to make it up.

I know you have my email. If you email me, I can try to see. Or the other thing is, if you post in the Facebook group, it’s possible that other people there might have suggestions. I believe Raga from DigitalA11Y uses Kadence. That might be an argument for that because he is also a blind screen reader user, but there might be others in that group that could share what they are using.

>> PAOLA: Perfect. Another question. Can we get that Google Sheets report? Being able to look over that would be super helpful.

>> AMBER: I am going to send everyone an email tomorrow with it directly to that sheet. I’m just not doing it tonight because, as I mentioned, I’m trying to keep all my secrets secret until the blog post goes live tomorrow morning. [chuckles]

>> PAOLA: Did you evaluate Core WordPress Full Site Editor 2025? I did not see this on the list.

>> AMBER: Yes, I did. That is our baseline. We use it as baseline, and in the report, I will compare a couple to it as either better or worse than baseline. The thing that is really difficult about Core WordPress– I will say, if you have opinions on this, there is a GitHub conversation happening right now. I think, actually, Ray wrote about it in the repository, which might be the fastest way to– wait. Sorry, I’m thinking too many things. I’m going to see if I can find that. No, I cannot find in the– if you message me later, I can find a few.

There is a conversation happening right now in Gutenberg GitHub about whether or not they should add extra blocks, things like accordions and tabs and all of the things that I talked about and that we tested because I’m like, realistically, you cannot build a good business or organizational website without these kinds of components. These literally don’t exist in Core, which is why last year I did not include it at all, and this year it’s my baseline, but if you look at it on the sheet and what components exist, literally the only one, when I showed you the page, the only one that was there was the latest post block. It doesn’t have any of the other things.

It’s hard to include it in the list as where it falls because it’s just not apples to apples, and I think when you build a website, you are going to have to choose one of these other tools because WordPress Core cannot meet all of your needs. You can decide that. I’m not trying to speak for people, but my assumption is it wouldn’t meet my needs, so I think I’m going to have to choose something else off this list.

>> PAOLA: That makes sense. Diane asks, to double check, if your site has several links that take a user to a different website, it is better for those using a screen reader to have that open in the same tab, not a new tab or window, correct?

>> AMBER: Yes, that is correct. The reason why is that when you open a link in a new tab, the way that you would return to the website that you came from is different because the back button doesn’t function. Instead, you have to go find the tab, close it, and then go find the other tab, which may or may not be the one to the left, the one that just opened, depending upon how your browser works. It could be many tabs away or different things. It’s less easy for them to return.

It’s not impossible, which is why we just say you need to have a warning so they know what to expect, and this is part of the no surprising change of context on interaction. They just need to have the warning so that they’ll know, oh, this is going to open a new tab, and if I want to come back, I’m going to have to do that differently. There is a fix in Accessibility Checker. It’s free in our free plugin. You can toggle that on, and that automatically adds it to every link on your website. If you are thinking, oh, my gosh, I have to go back and edit all these links, no, you do not. You can toggle that on, and it will magically do it for you.

>> PAOLA: We have another question. This is from Joseph. I’m sorry if you have covered this, but could you explain the distinction between the categories, concern, fail, and fail plus concern?

>> AMBER: Pass means it literally worked. The fail is it absolutely did not work or did not pass. Concern is it mostly worked, but there were one or two things about it that seemed not quite right or it wasn’t a literal failure, but it seemed like maybe it could people, or in a couple places, we put a concern when the way it was set up, a content editor was likely to make a mistake on it. The concern plus fail that I showed on that was just for math purposes. We were adding them together. I actually eliminated that in the sheet. Last year I had it in the sheet and I was like, I don’t actually need to do this in Google. I can just add multiple rows in a different way. That’s not a separate row in the reports this year.

>> PAOLA: We have another question here. I know it’s not applicable right now, but what do you know about the accessibility.txt requirement of the future?

>> AMBER: One second. I will hopefully be able to find that doc a little bit faster, because it’s in my Google Drive. I actually have what I can share. Lost my Zoom. I’m pasting a link in the chat to a doc. This is the work in progress for the new accessibility-ready tag requirements. Let me also share my screen real quick. What you are seeing on the first page, if you look at it, was from WordCamp EU Contributor Day. This document does use tabs, and there’s a few things. It’s all work in progress, but like I said, it should be done realistically probably early next week.

There is a tab for accessibility.txt. This is a file that we are going to be asking anyone who wants the accessibility-ready tag on WordPress.org to put in. It’s like a readme that comes in a theme or a plugin already. It’s going to be written in markdown like that, and it is going to have specific sections. Just some quick information, which this may change, because Joe and I have been talking about it a little bit. A place for them to say what testing tools and methodology they use. If they have a screen reader text class they support, then we’re going to ask them to just put it in here.

This could be a place where if you’re starting with a new theme and you are like, what class does it use? Because the one you tried did not work, you could just go look at this file. Any accessibility features in the theme, if there are any, how they can get accessibility help for the theme, and also where they can report issues if they find accessibility issues. There is an example of that in this doc. Then also detailed information about how it would be filled out. That’s what this doc is.

If you want a sneak peek at the accessibility-ready requirements and how they will be improving, that is the tab, accessibility-ready requirements A11Y handbook. This has the current ones with improvements to testing instructions, because there weren’t clear testing instructions, and then a few that we are adding as well.

>> PAOLA: Thank you for that. I do not see any other questions coming through. I think that we are ready to wrap up today’s meetup. Thank you so much, Amber, and thank you, Maria, for all the work with the audit and the report. We’ll see you guys on our next meetup on the first Thursday of the next month.

>> AMBER: Thank you so much, everybody. Bye.

>> [01:33:25] [END OF AUDIO]