081: Which Page Builder is Best (or Worst) at Accessibility with Amber Hinds

This episode is a recording of a July 2024 WordPress Accessibility Meetup where Amber Hinds, CEO of Equalize Digital, compared the accessibility of popular page builders: Avada, Beaver Builder, Breakdance, Bricks, CoBlocks, Divi, Elementor, GeneratePress, Kadence, and Site Origin. Listen in to find out which provides the best (or worst) foundation for accessibility. WordPress Accessibility Meetups take place via Zoom webinars twice a month, and anyone can attend. If you want to watch a video recording from the meetup, you may do so on the Equalize Digital website: Which Page Builder is the Best (or Worst) at Accessibility: Amber Hinds.

Listen

Links Mentioned

Summarized Session Information

Amber Hinds presented a thorough analysis of the accessibility features of several popular page builders, including Avada, Beaver Builder, Breakdance, Bricks, CoBlocks, Divi, Elementor, GeneratePress, Kadence WP, and SiteOrigin.

Prior to the meetup, she had conducted structural and component-based testing, focusing on elements like skip links, navigation, and header search, as well as frequently used components such as accordions, sliders, icon lists, post/loop blocks, tabs, and testimonials.

Amber found that while some builders performed well in certain areas, others had significant accessibility issues. She concluded by ranking the builders based on the percentage of accessibility checks they passed, with Kadence WP achieving the highest score and Divi at the bottom with the lowest score.

Amber emphasized the importance of choosing accessible page builders and recommended simplifying website components to enhance accessibility. She encouraged users to advocate for better accessibility features from developers and to begin accessibility testing using available resources.

Session outline

Introduction
Methodology
Skip links
Navigation
Header search
WordPress accessibility-ready requirements
Component testing
Summary
Recommendations
Conclusion

Methodology

Amber’s testing focused on both structural elements and frequently used components on business websites. Structural elements included skip links, navigation, and header search functionalities. The components tested were accordions, sliders, icon lists, post/loop blocks, tabs, and testimonials. Amber clarified that the testing was not a comprehensive accessibility audit but focused on specific elements and their usability.

Skip links

Amber began with skip links, a crucial accessibility feature that allows users to bypass repetitive content and navigate directly to the main content. She checked if the skip link was present, correctly positioned as the first focusable element, had sufficient color contrast, and effectively moved the keyboard focus to the main content. She noted that most builders passed this test, with the exception of Breakdance and Divi, which lacked skip links altogether.

Navigation

For navigation, Amber examined the use of HTML nav tags, aria-labels, keyboard accessibility, visible keyboard focus, and the ability to add button styles. She highlighted that while most builders passed, Divi and Beaver Builder had significant issues, including non-functional menus and poor mobile menu accessibility.

Header search

Another critical area was the accessibility of the header search. Amber tested whether the search button was an actual button, whether the search form was focus-locked, and whether it had labeled form fields. She found widespread failures, particularly with Divi, which failed almost every test in this category. Other builders had mixed results, with common issues like incorrect aria usage and unlabeled buttons.

WordPress Accessibility Ready requirements

Amber also evaluated builders against WordPress accessibility-ready requirements, which are based on Web Content Accessibility Guidelines (WCAG). These requirements include visible keyboard focus, correct use of landmarks, and appropriate form controls. Many builders had a mix of passes and fails in this category, with Divi performing particularly poorly.

Component testing

Amber’s component testing included:

Accordions: she looked for proper use of headings, buttons, aria-expanded, and aria-controls. Most builders failed, especially when using correct heading structures.
Carousels/Sliders: Amber checked for correct wrapping in section tags, button usage, aria-current for dot navigation, and the presence of a pause button. Failures were common across all builders tested.
Icon lists: she ensured that icon lists were coded as unordered lists and that decorative icons had aria-hidden=”true”. Results were generally positive, with some builders missing list markup.
Post/Loop blocks: Amber tested for list grouping, heading level control, and meaningful link descriptions. Only GeneratePress provided the option to link an entire card, but there were still concerns about implementation.
Tabs: she checked for the correct use of tab list roles, aria-controls, and visible focus. Kadence and Breakdance excelled in this area, while Divi and Bricks failed.
Testimonials: Amber looked for the use of blockquote tags and correct heading usage. Carousel testimonials often failed due to accessibility issues.

Summary of Findings

Amber concluded by ranking the page builders based on the percentage of accessibility checks they passed.

Rank	Page Builder	Percent Passing
1	Kadence	75.95%
2	Elementor	70.13%
3	GeneratePress	67.80%
4	Avada	59.21%
5	Breakdance	54.67%
6	CoBlocks	52.38%
7	SiteOrigin	51.90%
8	Bricks Builder	50.00%
9	Beaver Builder	48.00%
10	Divi	16.22%

Kadence WP topped the list with 75.95% of checks passed, followed by Elementor, GeneratePress, and Avada. Divi ranked the lowest, with only 16.22% of checks passed.

Read a more detailed review in our full WordPress Page Builder Accessibility Comparison report.

Recommendations

Amber emphasized the importance of using accessible page builders and encouraged users to reach out to developers to improve accessibility. She advised simplifying websites by removing complex components and starting accessibility testing using available resources like the free Accessibility Checker plugin from Equalize Digital.

Transcript

>> CHRIS HINDS: Welcome to the Accessibility Craft Podcast, where we explore the art of creating accessible websites while trying out interesting craft beverages. This podcast is brought to you by the team at Equalize Digital, a WordPress accessibility company and the proud creators of the Accessibility Checker plugin.

And now, on to the show.

>> PAOLA GONZALEZ: Now, I’m going to introduce our speaker, Amber Hinds. She’s the CEO of Equalize Digital. You guys know her. She is the organizer of the meetups. I’ll let you take it away, Amber.

>> AMBER HINDS: Thank you so much. Let me share my screen. I’m going to go a little bit between a side deck and a Google sheet. In just a minute here, we’ll throw the link to the Google sheet. All the information in this side deck is just simplified information from the Google sheet, so you don’t really need the link to the sides as much as you need because it’s literal copy and paste of words that– I’m not going to go full screen because I’m going to go back and forth.

What I am going to talk about today is the accessibility of several popular page builders. The Avada Website Builder, Beaver Builder, Breakdance, Bricks, CoBlocks, Divi, Elementor, GeneratePress, Kadence WP, and SiteOrigin. Basically, what I did was I went through, and I did some accessibility testing of all of these different themes. It’s a combination. Some of them are only a theme that takes everything over, some of them are only a plugin that takes everything over, and then some of them have built a theme and a plugin, and so I would test them together.

I did not fully accessibility test the different builders. What I did was, I decided that there were some structural things related to the theme that I was going to test, and then some common components that you would frequently see on a business website. The things that I tested that were structural were skip links, whether or not they existed, and some other things that we’ll talk about in a minute. I tested the navigation. I tested the functionality of the header search, like if you had an icon in the header that you could click, and it would open a modal, or expand, or drop down, or something to do a submit a search query right from whatever page you happen to be on.

Then I looked at the WordPress accessibility-ready requirements. Those are the theme or more structural elements. The components that I decided to specifically look at that I think are very frequently used on business websites are accordions, sliders, icon lists, a post or a loop block, like if you just wanted to display three posts from your blog on your homepage, for example, tabs, and testimonials.

Obviously, I didn’t do a fully comprehensive accessibility audit of these different plugins. What I did instead was looking at specific components, and then comparing those.

You can get the data from these things. You get the actual spreadsheet. If you go to equalizedigital.com/page-builders. That will give you the full spreadsheet that we’re going to look at. You’ll have all that data to reference later just because there’s not going to be enough time today for me to read every cell on that sheet and that will redirect over to that Google sheet.

The first thing I want to talk about is skip links, what specifically I was looking for this. This is the format I’m going to follow. I’m going to have a list of and briefly talk about what I was looking for each one. Then I’ll go over to that spreadsheet and we can talk about what I saw for the different builders. I started with skip links because skip links are something that I expected pretty much every builder to have and do a good job at.

It’s also the first thing that you should find when you go to any website. You can basically test if they’re present by hitting the Tab key. Once the page loads, and you should see something that says, “Skip to content,” or “Skip to main content.”

What I did was I checked to see is the skip link present? Is the skip link the first focusable element? Sometimes, they can be present, but they’re in the wrong order, so I want to make sure they’re in the right order. I wanted to make sure that the skip link has at least AA color contrast, so it’s readable. It’s not a light gray text on a white background when it pops up. I wanted to make sure that the skip link shifts the keyboard focus to the content. Then I did decide that if anyone also had to skip to navigation, I would give them a bonus point.

What my spreadsheet looks like is it has, in the first row, I have my test dates. I’ve tested all of these plugins between May and July. Most recently, I tested one today. Some of them are far back as May, which means that some of these things may have changed. In fact, Elementor e-mailed me on Friday and said, “Two things on your spreadsheet, we fixed, and they’re going to come out in the release that comes out this week.” “Next week,” they said, “but sometime this week”.

Just have to keep them in mind. All of these plugins are reading tools for WordPress. What I have here was accurate at the time of my testing, but if you reference this a month from now, or two months from now, they may no longer be accurate. Across the top then I have alphabetically, the different builders that I tested. Avada, Beaver Builder, Breakdance, Bricks, CoBlocks.

CoBlocks is a plugin. It doesn’t have a CoBlocks theme that goes with it. While I was at work Camp Canada, I was chatting with my friends with GoDaddy, and I asked them, “Do you want me to test it in your go theme, or do you want me to test it in 2024?” They said, “Test it in 2024, so that is what I did. Divi, Elementor, GeneratePress, Kadence, and Page Builder by SiteOrigin, so those 10 builders. Then you can see that I gave each item either a pass, a fail, there’s concerns lower down, which we’ll talk about in just a minute, and/or they would get a not applicable. Again, I’m not going to talk through all of this today, but what I’ll do is I’ll highlight specific things.

I had hoped and thought that everything would apply, and everyone would get passes on skip links. For the most part, most builders did. The two that did not have skip links at all were Breakdance and Divi, so they got fails for the first two items that it’s present and it’s the first focusable. Then the rest of the things, obviously color contrast and stuff was not applicable because it’s not there, so I can’t grade them on color contrast.

CoBlocks is only a block library. It doesn’t have a theme that goes with it like the other ones. Therefore, they just got not applicable on all of it because that’s controlled by the theme and not something that I would expect a block library plugin to control. In that instance, they got not applicable. That’s why we see some not applicable across here.

Beaver Builder got a fail on color contrast, and there’s a note that I have in the cell, which is that the skip link doesn’t have background or padding set, and so what happens is that it’s fine on a light background, but if you have a dark-colored header background and it pops up, then it no longer passes color contrast. They could fix this by forcing specific styles on their skip link instead of not really styling them. Otherwise, everyone else did really well here, which is good.

Then the next thing that I looked at was the navigation. I tested for these both the primary navigation in the header, and then if they had the ability to add a secondary navigation, like a pre-navigation, where you might put your shop and your checkout link, or maybe just your social media or something, your my account login. I would also test those as well. I was looking to make sure that they were using an HTML nav tag, that the nav tag was labeled, which is typically and most recommended done with an aria-label. Then I wanted to see that users can define the nav tag aria-label.

For the primary navigation, if they hard-coded in the word primary, that’s probably okay, but for a header above that, you really want your navigation label for screen reader users to be something that describes the type of links that are contained in it. If you were putting your my account and your cart and your checkout links in the very top navigation, you might say something like–

You might name it User links so that a screen reader user would hear navigation user links, three items, or if you have links to your social media in that navigation above the header, then you might call it Social media, or there might be an instance where you call it Utility, so having a Hard-coded secondary or Above header as the label is really not good. I looked at a few different ways. They could get a pass on that if they just use the name of the menu from WordPress, so you could then change the name of your menu in WordPress, and that would be output. That would be a pass, or a few of them, not very many, but a few of them had an aria-label field, so that would also be a pass, so I looked at that.

I then checked to make sure that the dropdowns were keyboard accessible. I wanted to see that there are separate buttons for opening and closing dropdowns. Now, this is not a web content accessibility guideline requirement, but it is something that can have a significant impact on usability for any keyboard only users, whether they’re cited or blind. It is something that at least in the United States, we have seen with the Department of Education and the Office for Civil Rights, when a website needs to be remitted with them, they require this, so I did check to see that and gave a pass-fail.

Then I wanted to see our CTA or button styles achievable in the primary navigation. What this is referencing is there are frequently websites where you want to have the Contact Us link look like a button or stand out in some way. I would give this a pass if there’s some way to apply a class to it so that you could then style it with CSS. As long as you could do that, then that would get a pass. Why is this important? Because if you can’t do that, what I end up seeing happening is that users then put a widget area right there, and they put a a Contact Us and a button in a separate column, not in the navigation menu.

Then therefore that item, which is their actually most important thing, is not in their primary navigation. It’s outside of it. I really wanted to see that there’s some way anyway that would be easy for users to add extra styles in their primary navigation. I wanted to see that there was a visible keyboard focus on everything, and then also that the mobile menu was keyboard accessible.

Going back to our spreadsheets, we have the quick and easy of CoBlocks doesn’t control a theme. That’s why it has all of those not applicables. This is the section where I started to see some concerns. What concern means is that it technically failed, sorry, it technically passed. It seemed like it was maybe close enough or it might be good enough, or in some instances, I have for example, on GeneratePress in the nav tag is labeled. I noted the secondary navigation is unlabeled. The primary navigation had an aria-label, but the secondary navigation didn’t. That’s where it’s like some things passed, some things didn’t. I called that a concern. It wasn’t a 100% outright failure, but it also wasn’t a clear success.

Here, where we’re getting in, Divi failed everything. Divi’s menus are not operational. Beaver Builder also had quite a few issues when it came to separate buttons for opening, closing, easily being able to add button styles. Their mobile menu had a lot of issues, so they got a fail on the mobile menu, though the desktop worked a lot better for users. There was some other things like–

Elementor, I’ll note, and I do have the component names across for each of these, this is as close as I could get to explaining what component I chose because sometimes there were multiple. With Elementor, I did not check their new Mega Menu builder. I know that one is much more accessible. I’ve actually tested that. I wanted to test because I hadn’t really their original WordPress menu widget that they were using. The reason why is because that newer Mega Menu Builder unless you’ve gone back and rebuilt your nav menu, you’re not using that. You’re using this older version. The vast majority of the Elementor websites are probably using this older menu so that’s why I tested that.

I have a note there in the other section. I said they get an extra one point pass for the Mega Menu is way better, but most websites are not using that. Let’s see if there’s anything else I want to call out here. There were a few where like Breakdance, for example, would have been a perfect score except for it is possible to add aria-labels on their nav tags very easily in the Breakdance Builder, but I just used one of their starter website templates, like the Breakdance ones, not a third party one, to create mine because I was trying to save time, and none of their– I ended up looking at multiple templates because I was like, “Is it just this one? No, none of them are actually labeled.”

Anyone who started from their templates are not going to get this. It’d be possible to add, but you have to know to do that, and most users don’t, so they got to fail there, otherwise, they would’ve been perfect. Kadence was really good except for they hard-code all of their aria-labels. They’re there, but users of the website can’t define what they are. That’s the only thing that failed on Kadence. That’s a high level on the navigation menus.

>> STEVE JONES: This episode of Accessibility Craft is sponsored by Equalize Digital Accessibility Checker, the WordPress plugin that helps you find accessibility problems before you hit publish. 1000s of businesses, non-profits, universities, and government agencies around the world trust Accessibility Checker to help their teams find, fix, and prevent accessibility problems on an ongoing basis.

New to accessibility? Equalize Digital Accessibility Checker is here to teach you every step of the way. Whether you are a content creator or a developer, our detailed documentation guide you through fixing accessibility issues.

Never lose track of accessibility again with real-time scans each time you save, powerful reports inside the WordPress dashboard, and a front-end view to help you track down hard-to-find issues.

Scan unlimited posts and pages with Accessibility Checker free. Upgrade to Accessibility Checker Pro to scan your website in bulk, whether it has 10 pages or 10,000.

Download Accessibility Checker today at equalizedigital.com/accessibility-checker. Use coupon code accessibilitycraft to save 10% on any plan.

>>AMBER: Header search. What I’m looking at here was that the button or the control to open the search form is actually an HTML button. I didn’t want to see a link, not a div, not a span. It had to be an actual button. The search form that opened almost all of them that had this functionality opens like an overlay that was black typically, and not all of them, but most of them did, and then it would have a search field, or in one instance, I think it’s Kadence that it was more of it almost looked more an accordion where it just dropped down from that button. Basically making sure that there was a focus lock so you can’t tab past it or beyond it or outside of it without closing it and getting lost on the page. I wanted to see that the search form field is labeled. Now that just means it could be labeled for screen readers only. Then my next point is the search form label is visible when the field has data typed in it. You could fail this one, or a builder could fail this one, if they had a labeled field that was a screen reader label and they were using placeholder texts for cited people.

Under Web Content Accessibility Guidelines, you have to have Bizible labels on all fields and that includes your search. You could do the thing that we don’t love but we do to make designers happy, which is having a floating label that jumps up a little bit, or you just have a visible search label and you don’t make it screen reader only, but that’s what that was about.

Then I wanted to see that there’s an actual button to submit the search. Relying on all users to know that you can hit the return or the enter key to submit search is not acceptable. There should be a button there. It can look like an icon. It doesn’t have to be a text button. It can look like a submit, like an arrow, or the little search eyeglass is totally fine, but there should be a button that comes after the field in the Tab order. Then of course I want that button to be labeled for screen reader users. Then there should be a button to close the overlay and that needs to be an actual button, not a div, or a span, or a link. Then that button needs to be labeled.

Then I did put this as a checkpoint just in case. I don’t think it actually came up on any of them but I thought, “Oh, if there’s any search suggestions, those need to be keyboard and screen reader accessible,” so I put that on my sheet. Going back to my sheet on here, this is where we start to get into there’s a lot more reds, and you also might start to see a pattern in the Divi column, which is that Divi failed everything. There was one thing that wasn’t applicable, a button not being labeled would be not applicable if there isn’t actually a button there at all, so that sort of thing.

I’ll go from the left to the right on this one. Avada, they had a button that opened their search. It was a link that they remediated, they added a role equals button, but what they failed to do was add space bar controls in. For a user, a button should be able to be triggered by both the return or the inter key and the space bar. If you turn a non button into a button, you have to write JavaScript that allows it to be triggered with the space bar.

There’s also actually an interesting thing on even both of those about the timing of the key press and that some of them act like links trigger on key press down and buttons can trigger in a different way on up. This is something that you’ll see throughout. There were instances of my testing where I came across something that had been remediated into a button. It read as a button to a screen reader user, which is good except for they failed to add the space bar handler, which meant that if a screen reader user tried to use their space bar to trigger the button, they would think the button was broken. There were two different buttons in Avada that were links that they had remediated but failed to add that.

Beaver Builder failed everything in header search except for the search form field being labeled. It was labeled but otherwise everything else was a fail. Breakdance I had a note with a concern that they used. Aria expanded, even though it was a modal aria. Expanded is for accordions or content that becomes visible in the exact same context of where you are if you’re using a modal or bringing a user to something, that’s what aria-haspopup=”dialogue” is for.

They had some aria, they were trying but they used the wrong aria and that’s something that really can cause issues for users and confusion. You may have heard some of our other speakers here at meetups say things like, “No aria is better than bad aria,” or, “The first rule of aria is don’t use aria.” Of course that’s the extreme. You do have to have aria for some instances, but you really need to make sure you’re using the right aria.

They also had an issue where they had the button to submit the search but it was styled before the input, so it showed up on the left hand side because I think they were using it to denote like this is a visible label for people because it just looked like a search eye blasts. What happens if someone’s filling in a form, they typically will hit Tab expecting to go to the Submit button after the form. If it’s to the left, or before the input in the dom order, they’d have to hit Shift Tab, which is not intuitive and most people would not know to do that, so really this is an instance where it’s like, “Let’s not be fancy, let’s just put it on the right where it belongs.” Then they failed a lot of other things so that it was not super great.

Bricks had a lot of not applicable because there were things– They didn’t actually have a search popup. They just had a search bar that I could insert into the header but that also had some issues. Did I say Divi failed? I think I said Divi failed but Divi failed everything. Elementor had a few things that passed. It was a remediated divi but it did have a space bar handler so that was good, but then they also had some other things that failed.

Then GeneratePress was a mix but leaning a little bit more towards mostly passing. I think what did we not have, the search form label wasn’t visible. It was screen reader only and there was no close button on the overlay, so there was no easy way for a blind person to be able to close that. Then Kadence, the only thing that they failed was the visible label. It was screen reader only.

Then Page Builder by SiteOrigin had a fail on the focus lock so users could leave it, it would still be open and they’d be lost somewhere down on the page, not know how to get back to it or have to Tab a whole bunch to figure out how to get back to it. Then they had a form label that was screener only, and they had a heading above that wasn’t the same text, but they didn’t have a visible label for the field, but I gave that a concern. I think it might be sufficient. I’d probably want to user test that with someone if I was using this on my website.

I have a few pages here on accessibility requirement, ready requirements. If you’re not familiar with these, these are requirements for themes that want to be able to have the accessibility ready tag in the wordpress.org theme directory search. They are based off of Web Content Accessibility Guidelines and other accessibility best practices but they are not the same as Web Content Accessibility Guidelines. There’s specific guidance provided for theme authors by the theme review team and the accessibility team in collaboration.

What these are, are controls for adding HTML attributes. That’s something like, do you have the ability for someone to add an aria-label on something or a laying attribute for example? Basically, if the builder had a section where you can put any attributes in that you want, then they got a pass because that made that really easy. That one’s not really an accessibility ready requirement. That’s a requirement that I have because I’m like, “I want to see that it’s easy for users without having to go write a function or write JavaScript to add attributes if they need to for accessibility reasons.”

I also checked to see if they supported either the sr-only or screen-reader-text class, so if you were to want to add an extra heading just for screen reader users, and then you went to the CSS section of your builder, and you were to just put that class on it, would it make it disappear for cited people? That’s what I checked. I checked for both of those, screen-reader-text is the WordPress standard for screen reader text. SR-only is the bootstrap standard, and a lot of older themes or builders are based on bootstrap. That’s why I also check for that. I would give them a pass if they had either because my assumption is hopefully they’d have that in their documentation for people.

Then now we’re getting to things that are more technically accessibility ready requirements, not Amber’s accessibility ready requirements, so I looked for visible keyboard focus on all elements, focus that follows the visual order, and all expected items are keyboard, focusable. Theme features that behave as buttons or links have to use the appropriate buttons, inputs, or <a> elements. All controls have to have machine-readable texts to indicate the nature of the control. Every page has to have an H1. For this, I looked at Homepage, Post archive, Single post, and just a Sample page. No, skip heading levels out of the box. I would do the same thing if they had a template and I had said, “Hey, create my website using the template,” I would look at those.

I also checked on taxonomy archive page so like an example category and on the post single for skip heading levels. The header needed to either be in a header tag or have role equals banner. Main content needed to be in a main tag or have role equals main. Sidebars in the aside tag or role equals complementary and no content out of HTML landmarks, which are those main ones we said, and there are a few others, but that all of these are accessibility-ready requirements.

Then I wanted to see that content links are underlined or can be underlined. Maybe they didn’t do it in their theme, but is there a setting in some global settings panel summer where you can say, “Underline my posts in body links very easily without having to write CSS?” I know, yes, we can all write CSS for that. It takes about 15 seconds to do that but we’re thinking testing page builders to make it easy for users who are non-technical to build accessible websites, so therefore there needs to be a setting if it’s not already done by default, by the builder.

No title attribute on images. No images were missing the alt attribute. They could have empty alt text or they could have alt text pulling from somewhere, that’s fine, either one of those. What I’m really checking for is did they forget to put the alt attribute on it completely? No positive tab index. That would be like tab equals 1, or tab equals 10, or tab index, sorry, tab index equals with a number because that would force something to be out of order when you’re tabbing through the page.

No opening tabs and new windows without warning the user. Typically for this, if a builder had a social media icons block, I always checked that because I wanted to see does it just out of the box, open them in a new tab, and then does it add a warning, opens a new tab for users or is there a way to toggle that option off? I checked a few other places, but that’s why I most frequently see it is in those social media icon blocks. It’ll just by default be like, “Oh, everybody wants their social media. Open a new tab and it will do that.”

Then I checked comment forms on blog posts. Comment forms have to have appropriate field labels and all content within formed tags needs to be explicitly associated with a form control. Also, I checked post-submission responses on comment forms, both the errors and confirmations and to ensure that they’re perceivable. We’ll talk more about that one in a minute when I have my sheet up, and that’s it.

Let’s go back to accessibility-ready requirements on my spreadsheet. This is really a mix across the game. This is definitely AKA let’s pick on Divi night. I apologize if you are a Divi user, but as you can see, Divi, the only thing that it really got a pass for is that it supports the screen reader text, so class. That’s about it. Otherwise, there were some concerns and a lot of fails.

Another thing that really jumped out for me on many of these is the visible keyboard focus or the buttons links. All controls having machine-readable text. To be totally honest, a lot of the components I tested had failures here so we’ll circle back on those. If they had a failure on their accordions, or like we talked about their header search had an unlabeled button, then they obviously got it a fail here, if that makes sense because if you fail it on one, then you fail it in the accessibility-ready check as well. That is like a summary of maybe other failures they had in other areas.

I had a concern. I said I was going to come back to talking about the post-submission responses. It seemed like every single one of the plugins were just using default WordPress.

This is coming from WordPress core comment form messages. If you did not submit or did not fill in the required fields and you hit Submit, it would take you to a totally different page that looks like a WordPress error page with an error message that’s announced out to a screen reader. Looks really ugly, but that’s WordPress core, and that worked fine.

The success message that says like, “Your comment is being held for moderation,” in WordPress core, then it seems like now that I’ve seen this pattern across all of the builders that actually control the theme, so the only one that it doesn’t really apply to is CoBlocks because It doesn’t apply to a theme. It just reloads the page and the user’s focus is up at the top and it doesn’t announce that message to them that success they’d have to go find it.

Technically, I would call that a failure, but as you note, I’ve seen this now on nine different builders. I don’t think that’s their fault. I think this is a core issue that I’m planning to go look at and see if we already have a track ticket for and if not open one because It seems like we need to message that, so I just wanted to make that clear. The other really one that stands out here that just disappointed me quite a bit is this row 44, no skipped heading levels out of the box.

All of the builders except for CoBlocks and I will say even that pass is a little dicey because it’s just like only looking at their blocks. It wasn’t looking at whole built pages, and I wasn’t looking at it in their go theme, so it’s possible they could also fail there. Everyone failed this. A lot of them failed it on the single posts. If there were no comments there, it skipped to an H3. A lot of them also failed it in their templates or their starter themes that you can pick. They have random headings just for size or color or style. Some of them failed it on their testimonials block. The quote would be a heading even though it’s really just big text.

Pretty much every page builder needs to work on this and it’s a common thing that we see on almost every website that we audit too. I would say as a developer, something I would take away if I was watching this is I should really go back and rethink how I’m using headings. I think most of them did a pretty good job about keeping all of their content in landmarks I saw, which made me really happy.

I saw a lot of use of the header tag, the main tag, the footer tag where applicable. The only two who failed to do this was Breakdance and Divi. Now, I do know in breakdance it would be easy to go through and set that. That said again, their starter themes don’t do it, so they are failing to do that when they’re creating all those starter themes. Divi, I don’t think you can control that. I will say I did apply to Divi Beta because I really wanted to test Divi 5 because I know that they’ve been saying that it will be better, but I haven’t been approved yet. We don’t know if they’ll decide to because I told them honestly, I want to look at the accessibility of it, so we’ll see.

I’ll say most of them did really well on the landmarks and that made me really happy and good job to all of them for paying attention to HTML landmarks. Another thing was not using title attributes on images. Divi was the only builder that failed that. Everyone else did not use the title attributes on image. No positive tab index on row 53. Everybody passed that. You can see as the fails and things go through in other sections with the comments on the spreadsheet. Accordions were the first component that I tested. What I looked at in accordion is I wanted to see that the titles were headings with button tags in them, so that would be like H3, open tag, open button tag, all your stuff, close button tag, close H3. Button tag inside the heading. Headings are incredibly important especially for blind people to use in their navigation and they are vital to use in accordions. The details block is not an accordion. I doesn’t include headings. It can be used incidentally, one-off, but it should not be used in the long list of them.

Looking to make sure that the titles were headings with buttons in them. A heading with a role of button does not work because when you add a role of button to a heading, then it removes the heading from the heading list in the screen reader, so it’s really important. The buttons need to use aria-expanded to communicate to users if they’re open or closed, they need to use aria controls to reference the content.

I want to see that users could choose the heading level for their accordion because on just an FAQ page with an H1, you might want all of your headings to be H2s. On a different page where you already have an H2 for FAQs, and then the accordions fall under that you might want them to be H3 and so on. We want to give the user easy ways to control and set what those are. Then of course we looked for visible focus and I checked to make sure that it worked well on Zoom.

What I saw for accordions, almost everyone except for Breakdance and Kadence failed titles are headings with button tags in them. Avada did have a remediated link that they had then turned into a button and it was inside a heading, but they forgot their space bar handler, so it didn’t function with a space bar. A lot of them failed because they had headings. Elementor, it was headings with a role of button. GeneratePress had a button, but it didn’t have any heading or way to mark it as a heading. Let’s see. CoBlocks use the details tag, which as I mentioned is not good for an accordion. It should not be used for an accordion.

SiteOrigin also had a link that they had remediated and turned it into a button, but they had forgotten their space bar controls, which obviously it looks like I did something funky there. I’m totally going to change it right on the fly. This should be a, not a concern. Watch if that changes. I want to be consistent, but basically, so you can see that was something that almost everyone missed.

Then there was pretty good use of aria-expanded except for Bricks and Divi. There was less consistent use of the aria controls to reference. Also, a lot of times, even if it was a heading, the user couldn’t choose the heading label. Then you get into issues where your headings are out of order. That happened for quite a few of them. Then there were also a few where they didn’t consistently have visible focus, so that was an issue as well.

Right now, what it looked like for the most part I don’t see anyone except for Breakdance that had a complete pass. Breakdance had the best accordion out of all of them. Also, had an interesting note looking back at that like GeneratePress, for example, I noted that some of their aria was just off. For example, they had aria-hidden but they’d typed it as ariahidden, all one word on an icon, and it actually has to have aria-hidden. Some of them, I think they’re trying and working on it, but it looks like maybe they need to go back and study the spec a little bit more.

Divi and Bricks, both of them were completely non-functional, not just for blind people, but for any keyboard. They didn’t work without a mouse, and typically, it’s because they didn’t have any buttons they were using divs to build their accordion.

The next thing were carousels or sliders. These were all pretty different, but I tried as much as possible to find a carousel that wasn’t just an image carousel, but a slider where you could add text and a link and an image in it like you might see on the top of websites. We all try and convince our clients not to use what they want any. I was looking for, is the carousel wrapped in a section tag or does it have role equals region with an aria-label or an aria labeled by attributes. I want to see that the slides are in a list. That’s really important.

One, the region because there’s a lot of content in the carousel and that helps people understand when they encounter it with a screen reader, “Oh, now I’m entering this.” It would also allow them to skip beyond it and not have to tab through or arrow key through everything and they could just go to the next thing. It could also allow them to return to it if it was labeled as a section tiger or region.

The list is helpful because it gives context. There are 4 slides here, there are 10 slides here, that sort of thing. We want to see that the user can set the heading level if headings can be added to the slide. The previous next and dot navigation buttons should actually be buttons, not links, not divs, not spans. They need to have meaningful labels. The dot navigation, I wanted to see that it included aria-current for the current item to indicate to the user which one was currently selected.

Then I wanted no keyboard focus to go to hidden items, so if you have links in other slides that are not currently being shown, they should not be able to be tab two unless the slide also changes, that’s fine, or they should just not be able to be tab two. Also, screen readers should not read out hidden items. When you are using the navigation button, so those dots at the bottom, if you use your keyboard to click and go to one and it changes the slide, it should shift the keyboard focus up to the slide so that the screen reader will then read the slide and the user doesn’t have to go Shift-tab, shift-tab, shift-tab to get back to the thing that they just changed to. That’s what focus shifts to slide when using navigation button means.

Auto-play carousels have to have a pause button. Animation should respect prefers reduced motion. I just have my computer set to prefers reduced motion now and I was turning on autoplay on all these carousels and going and refreshing the page and do they still autoplay? If they still autoplay, then that was a fail. They should stop because they should understand that I don’t want motion on the website. Then I checked for visible focus on all of the focusable elements and does it still work on Zoom?

There were a lot more fails and concern areas as we can imagine on carousels and sliders. I don’t really know just going through this, if there’s anyone that I can say they did a great job on a carousel or a slider. I also have an interesting little note on these down below. Three of the sliders that I saw behind the scenes Breakdance, Bricks and Elementor use Swiper, which is a JavaScript library for creating carousels.

You’ll notice in many cases they have the same passes and the same failures, and that’s because it came from that JavaScript library, so you really have to be careful when you’re using JavaScript libraries. I have detailed notes on all of these in the fails, what the issues were with each one. I’m going to move on, but I’m certainly happy to answer questions about any of them when we do Q&A later.

The next component that I looked at was an Icon list. What do I mean by this? I mean something where you might list out features of something and you have either a checkmark and a feature, and a checkmark and a feature, and a checkmark and a feature, or it might be like a different icon for each different little feature. I included this because it’s something that a lot of times our clients have in their designs or they want to have in their designs, so I was like, “I should look at these if they have the component,” not all of them did.

Basically, what I was looking at was three things. Are they coded as an unordered list? This is really big for me. If you’re literally calling your block or your widget in your builder a list block, it should be coded like a list. It is grouping things all together that are part of the same thing. It is very helpful for screen readers to encounter this as a list and not just a group of divs. Especially, if you’re giving the expectations of the content creator that this creates a list, it should be a list, so I looked for that. Then I listened to make sure that the icon has our aria-hidden=”true” because otherwise, what happens, these are typically all SVGs is you just get image and nothing is. I wanted to make sure that it didn’t announce the image because the image is usually decorative and doesn’t provide meaning that’s important. Then I checked to make sure it works on Zoom.

For my icon list, and this is a short row here. I would say most people that had them did okay. There were– let’s see. Breakdance, and CoBlocks. They did not have aria-hidden=”true” on their images, so it read out, Beaver Builder, and CoBlocks, and Page Builder by SiteOrigin. They did not use list markup, and I was so sad. Page Builder by SiteOrigin, I have an extra note, “User can’t control heading levels” because their features block, or features widget, which is the closest to one of these icon lists, it included headings in it, but I think they were H5s or something, and the user couldn’t change that. That’s the extra note on there.

Kadence, Elementor, Bricks, Avada, they all did a good job on the icon list form. Then the next thing I looked at was the loop or post block. I gave them a bonus. I called a bonus. I’m going to check for this. Could we set one link around the entire component? If there was a featured image, and a title, and an excerpt, and a read more, or maybe no read more, could we have one link that goes around all of them? My expectation was that’s not going to happen. CoBlocks don’t do that.

I think it would be awesome if all builders had that at least as an option or just did it by default because it would be better for users. I’m calling this a bonus, it’s not a requirement, but you can get an extra point if you do that. Then I checked to see if they hid redundant links from screen readers and keyboard users. Maybe they would only have the title focusable and the image could be clicked with a mouse, but not actually with a keyboard, and that would be okay. I wanted the post to be in a list.

Again, this is really important. Group like items allow users to understand how many there are, more easily skip beyond them. Especially, if you think, well, somebody might put a grade of nine on a page, or something like that. The ability to choose the heading level or even potentially using a paragraph tag for post titles. There might be some instances where you don’t– let’s say, you’re having these posts display as a bulleted list with visual bullets, and there’s no excerpt or content below them, there’s no reason for that post title to be a heading. It should be a paragraph tag.

I wanted to see, can I choose the heading levels or set it to a paragraph tag for my post titles? The read more should not be ambiguous. Read more can be the visual text and then there should be screen reader text or an aria label that says “Read more of blog post title.” Then the linked image describing the purpose. What I look for on this is that the alternative text should not– one, it shouldn’t be empty. Two, it should not be missing. Three, it should not be the alternative text for the image that I put in the media library. Why? Because if the image is linked, it does not matter, this really great description of a beach scene.

If the title of my post is all about renting chairs like link, “How to rent chairs at the beach?” I don’t need to describe all the chairs sitting in the sand next to a sandcastle. That’s not telling people where the link goes.

I wanted to see that the builder recognized this and did not pull alt text out of the media library, and instead that it actually got the title of the post and made that the alt text on the image when the image was linked. If the image is not linked, then it probably should pull the alt text out of the media library, but I didn’t go that far on my test. This was interesting because they were all pretty different. I will call out GeneratePress here. They were the only one who got my bonus point of, you have the ability in GeneratePress to link an entire card.

They didn’t totally get it, they got a concern only because when I inspect the code, they actually put an empty a tag above the div that has all the content. I guess they’re using CSS to position it over the content, which is a little odd, but it’s empty. There’s nothing in it. I tested it with VoiceOver, I didn’t have time because this was one that I did today. I didn’t have time to test it with NVDA, so I’m not sure.

In VoiceOver, it did actually read the name of the post, even though I have no idea where it’s coming from because it looks like an empty link to me in the code. I didn’t fail it, it’s just something that if you use GeneratePress and you toggle this feature on, you might want to do a little bit more investigation on, not just trust me that it’s perfect, is what I’m saying. Nobody else did that. I would love to see more builders do this, have the ability to have that. Good job GeneratePress for thinking and making a feature there, but let’s just check it.

There were a lot of failures here on the redundant links. Elementor and GeneratePress were the only ones that did the hid redundant links from screen reader users. That’s one of those things that is more of a best practice for accessibility, it’s not a literal Web Content Accessibility Guidelines failure, but it can really enhance usability if you do that. Almost nobody had their posts in a list except for Avada and Bricks.

There were a few Elementor and Kadence that used article tags. Article tags are good, they should still be in a list. Setting the heading level. I gave a bunch of concern because they allow you to choose an H1. We all know what users do when they want things to be big, they make them an H1. There is no reason in a list of posts that they should all have an H1. I think we all know that this is an SEO no-no, it is also an accessibility no-no, so I would love for these builders, they would all get a pass here if they would just go in and remove H1 from the option on their post list.

You should not be able to set an H1 for every single post in a group of posts. The only ones that actually had a link that described the purpose was Avada, Divi, surprise [laughs] and Kadence. Otherwise, most of them were either not using all types or they were pulling out of the media library and not describing the purpose of the link. Then I had two notes on both CoBlocks and Divi, their post carousel are as not accessible. That is an issue. Then the next thing I looked at was the tabs. The tabs, what I was looking at was tab control, the containers that contain the buttons you click, that needs to have role=”tablist.” Then the actual tab controls should be buttons. I said they can be in a list, or they should read like a list. Typically, if you have tablist, and then you have the role of tab on your buttons, they’re going to read like a list to a screen reader, but they could also be in an unordered list if you want.

That’s not an accessibility problem. Then the tab controls have to have a role=”tab,” and they have to use aria-controls to reference what they’re controlling. Whichever container contains the content for the tab, they would reference that with the aria-controls attribute. The current tab control button needed to have aria-selected=”true.” Tab panels where the content was needed to have a role of tabpanel, and the tab panels have to have aria-labeled by, which references back up to the button. Then, of course, there needed to be visible focus on things.

Bricks and Divi, not keyboard accessible, they’re divs, they just failed everything. Kadence and Breakdance had total passes on everything. Did a great job. Avada, they used links instead of buttons. I’ve done some reading on this and there are some people who argue that links might be sufficient as long as they have the Aria. I gave it a concern, not a fail. If you look at most spec and most official example code from the W3C and Mozilla developer docs, they’re going to recommend buttons. I did that. I did say it’s a concern, it’s not a total fail. The Beaver Builder would’ve gotten a pass on almost everything except for they had a fail on the currently selected tab. Didn’t have a focus, it was missing focus, everything else did.

Then they used Aria-expanded instead of Aria selected, which is not the right aria. I think most screener users might understand what that means, but it’s not the aria that is recommended by the spec. That same issue existed in Elementor and that was the only thing in Elementor. It’s not like a major problem. They still have something that communicates to users what it is, but it’s a little odd. It’s almost treating it like an accordion and it’s not. Then the Page Builder by site origin, they were just missing the aria controls attribute and the aria labeled by attribute. Otherwise, it was pretty close. The tabs were, for some of them, a lot better than I saw in some of the other components. I looked at testimonials.

Testimonials, what I was looking at there is I wanted to see that the quote from the person used the blockquote tag. I checked for no random headings. Don’t make big things a heading just to make them big. Then if it was a carousel, it’s accessible. Testimonials were so different on all of these. I didn’t really want to check the carousel testimonials, but some of them literally only have carousel testimonials. Some of them you can do a single testimonial. They were all very different as far as what the components were. Some of them didn’t even have a testimonial block there. Actually, the ones that had carousel testimonials all failed.

I have notes specifically in the sheet about what failed. The no random headings pretty much all passed. I did have a note on CoBlocks. Oh, maybe I didn’t put it in here. What I’ll say about CoBlocks and their testimonial is that they have a simple testimonial, a fancy testimonial. Wait, oh, you know what? I might not have gotten my notes in it. I’ll fix this later for you guys. Their simple testimonial is good, their fancy testimonial is really bad. It fails. That’s how the testimonial goes. If you have the sheet, you already know who wins. We’ll talk about that. Before I dive into who wins and how I figured that out, I do want to say, you may have noticed that I did not say anything about forms. Why not? Because I feel pretty strongly that there are some really good WordPress form plugins out there.

You should be using a form plugin, not a Page Builder to create your forms. Maybe if it’s a really basic website and you need a super simple contact form that just emailed you and you don’t need it to go to a Google spreadsheet or go into a CRM or any of these other things or have hidden fields, maybe then you might use it. Really I think you’re going to get better accessibility out of a form plugin, then you’re going to get from a Page Builder form block. That’s why I did not test that. If you want to use them, go ahead, and then you can just test them and maybe report back to us. Who won? If you saw my talk at the Page Builder Summit, I had a ranking, which may be a little different than it’s going to be today because I spent more time thinking about this.

What I did at the Page Builder summit initially was I literally just ordered them by who had the most passes. As I’ve been adding a few like I talked to some people from the GoDaddy team and they’re like, “Yes, test CoBlocks.” Well, I tested CoBlocks, but a lot of the checks didn’t apply to them. I’m like, “That doesn’t really seem fair, because they’re going to have a lower number of passes because they had a lower number of things I checked.” I was like, “I can’t use a literal account.” Here’s what I did and what I came up with. I used Google Sheets fancy functionality to basically total for me any of the cells that include the word pass, the word concern, the word fail.

I also combined concern and fail because I’m like, “It’s not a literal pass.” I totaled the two of them. Then what I did is I calculated a percentage of pass applicable checks. This excludes anything I put N/A on. Basically, I calculated that by taking the pass and dividing it by pass plus fail plus concern, and then times 100. The example that I have up on the slide is a total pass of three, a total concern of zero, total fail of nine. Concern plus fail is zero plus nine, that equals nine. There’s 50 things that were not applicable in this example. My percentage then would be calculated by saying three divided by three plus nine, so 12.

That says this innocence is, it would be 25% of the checks actually passed. I think that this gives us a better look at how good are they at the code they actually have written at accessibility versus counting things or making them lose points because they haven’t– if you haven’t put a slider block in your plugin, I don’t think that you should lose points for that. Probably you should gain points for that. [laughs] Good job. You probably have better accessibility for that. This is the methodology that I came up with and you can see all those totals at the bottom of that spreadsheet. Here’s what it is. From best to worst at accessibility in number one, we have Kadence WP with a percent passing of 75.95%, which is pretty good.

Elementor is number two, 68.83%, GeneratePress number three, 61.02%, Avada, number four, 59.21%, Breakdance, number five, 54.67%, CoBlocks number six, 52.38%. Page Builder by SiteOrigin is number seven at 51.9%. Bricks is number eight at 50% pass. Beaver Builder is number nine at 48.65% pass and Divi is number 10 at 16.22% pass. That is the best. All the way down to the worst of the 10-Page Builders that I have tested. Remember, these specific components and based on the percentage of relevant things that they actually had available for me to test.

Again, if you join late and you need the data, you can get all of this at equalizeddigital.com/page-builders. What does this mean for you all of this data? On a short summary laws around the world, they require websites to be accessible. If you are building websites for clients or you’re here and you’re working on a website internally, depending upon what you just heard, it may be time to rethink your plugin or theme stack. If you are really good at JavaScript, you might be able to patch or remediate a lot of these things.

It might not matter for you but it may be something that could tell you. Maybe you want to rethink how you’re building websites so that you have a better starting point. It also might just mean that you want to go to your stack tomorrow and say, here are all the things that need to be fixed in the blocks that you use. It might also mean that you want to test other components in your builder that you use a lot on the websites you build that I did not test because obviously right I did not test all of them. No matter which filter you use, it likely needs remediation in some areas. Our number one, Kadence passed 75% of the things. No one here was 99% passed, 100% passed, so there’s still some areas of improvement for everyone. Obviously, that’s different for everyone.

The other thing I want to say on this is that you can improve accessibility on a budget by simplifying your website. Remove more complex components. What do I mean? All those carousels that had all those problems, those sliders, just don’t put one on your website, or none of them have pause buttons for autoplaying. Maybe you fix the other issues and you just don’t turn on autoplay because you don’t know how to add a pause button yourself, or if you’re using a builder that has issues with tabs or accordions or something. Maybe you say, I’m just not going to use tabs on this page, I’m going to communicate the information in a different way.

I don’t want you to be terrified and think, “Oh my gosh, it’s going to cost me so much money, or I have to totally start over and I don’t have the budget for that.” There are ways to work with what you already have in some instances. Some of them are way worse than others, obviously. If you make websites more simple, which does not mean it can’t look fancy, it can have a very fancy, very professional and nice design, but from a HTML component standpoint, be less complex, that can really help you to be more accessible.

Then I’ll say, if you haven’t started accessibility testing, you should start now and you can use our free plugin to do this. We have a lot more resources in the website. If you go to equalizedigital.com/meetup, and watch back issues, back recordings of Meetup, you can learn a lot about manual accessibility testing. That’s where I’ve landed off. I have not looked at the Q&A or the chat at all. I am happy to answer any questions. I don’t know, Paola, if you want to jump on here and maybe I’ll stop sharing.

>> PAOLA: Yes, I’m right here. We can go over the questions that came in. Can you explain a bit more about search form label is visible when field has data typed in it.

>> AMBER: Yes. Oh, maybe I shouldn’t have stopped sharing. Let me reshare actually. Did I just do something silly like close my whole browser window? No. Okay. There it is. Yes. The important thing is that when we’re thinking about accessibility, we’re thinking about a lot of different users. In some cases, if people have a memory issue or something like that, then it may be confusing for them if they can’t see the label of the field. Potentially they might enter a page and their auto complete could accidentally fill in that search form field. You always want to have visible labels all the time.

This is a website where the designer really wanted the search resources by keyword text to be on the line, and for it to look more simple and fancy. What traditionally people would do is this would be placeholder text, but what we’ve done is that when you click in the field, it jumps up. Then even when I’ve typed in there and I click away, I can still see the label. That’s what I was talking about there.

>> PAOLA: Thank you. Mami asks, I’m curious why you chose to also include Kadence in your testing since it’s primarily a block library that depends on core, while all of the others are overhaul side builders and visual composers. I haven’t tested the Kadence theme in a while, so correct me if I’m wrong, but last time I did it was still using a classic customizer setting themes and the rest was the block editor, so it seems out of place. Why did you decide to include it and not the major block libraries like Stackable?

>> AMBER: I wanted to include some block libraries when I tested. I don’t care necessarily about it being a classic theme because to be totally honest, SiteOrigin, I had never heard of that until I went to the WordPress plugin repo and I searched the word Page Builder and that came up. It’s basically like building your website with widgets. It’s probably really old, but it has 700,000 active installs, so it’s not a lot of– maybe really old websites, but it’s not in a lot of websites. I wanted to use at least one block library because I couldn’t really compare against core. Because a lot of the components I wanted to test, like accordions, tabs, icon list, these don’t exist in four.

While traditionally Kadence or GeneratePress is another one where they have a theme and they have blocks, they’re not Page Builders per se. They are these ecosystem that yes, it utilizes the block, the Gutenberg block editor, but it’s still is an ecosystem the people go into and they use like a Page Builder. The other thing too, CoBlocks it’s interesting. You might be like, well it’s not– and they don’t even have a CoBlocks theme. If you go read their listing on wordpress.org, it says all over it, it’s a Page Builder, it’s a Page Builder, because I think they’re trying to optimize for that. I think that’s worth testing.

Then the other thing I will say is, especially in my first pass of this, I tested things I had access to. Kadence had previously given me a license to do some testing on so I could. I didn’t get GeneratePress until this round or Breakdance until this round, because either I had a friend who had a license, they’re like, “Oh, I’ll set you up a testing site,” or in the instance of Breakdance, someone from Breakdance reach out to me and is like, “We want you to test it and include it,” and here’s how it’s. Beaver Builder, I don’t have a license for that, but they had a demo on their website I could spin up, but they don’t all have demos. That impacted a little bit on what I decided to test.

Then like I said, I did go and I searched the word Page Builder, that’s how I discovered the SiteOrigin one, to see what has a lot of active installs. I do have a plan. I recently got access to– during WordCamp Canada, someone gave me a zip file of WPBakery. I’m planning to add that in the future. I would love if anyone can throw in the chat if there are other Page Builder-esque plugins you think I should add to this. I’m going to publish a huge blog post too. I will add them in so that it will be added in the sheet. You’ll have access to this sheet as well.

>> PAOLA: A follow up question, why didn’t you test Gutenberg by itself?

>> AMBER: Well, I suppose I could have tested the accessibility ready requirements against 2024, but it already has accessibility ready tags, so we already know it passes all of those things. Then looking at what I was testing, let me go back to that list. Gutenberg does not have accordion, sliders, icon lists, tabs, or testimonials. It literally doesn’t have any of those. I’ll be totally honest, I do not think that you can build a super professional looking business website with only four blocks. You either need custom blocks or you need to have a block library if you want to build in Gutenberg.

>> PAOLA: Yes, that makes sense. When you were testing Divi, did you try the Divi accessibility plugin and if so, did it make any difference?

>> AMBER: I did not test Divi with the Divi accessibility plugin. The Divi accessibility plugin does make a lot of difference. That was something someone asked me too, because someone told me the first time around when they saw this and how bad Bricks was, and they were like, “Oh, but you just have to use this third party Bricks add-on because it’s way better.” My strong opinion is that we should not have to add accessibility add-ons or get third-party components for our builders in order to make them accessible. I really want the builders themselves to make them accessible. That’s why I didn’t test that. The Divi accessibility plugin does make difference and I will give a big shout out to, next month, in the same time slot, Renee Dunn is going to come and she’s going to talk about– she’s a developer who works for a design agency that told her she has to use Divi [chuckles] when she builds their designs. She has been doing a lot to make them accessible. She has codes and bits and a lot of stuff she’s going to share, and I think that that’s going to be really good.

That said, 16% pass is not good. Hopefully, I’ll get access to Divi 5 and we can see if they’re improving there, but if I was using Divi, I would just go somewhere else. This could be easier. It’s so much like get closer, a better starting point.

>> PAOLA: That makes a lot of sense. Another message, “Thank you for the thorough review, Amber. It sounds like you’re in touch with a couple of these theme-plugin authors. Do you plan on reaching out to all of them? We use Avada on over 100 websites, and I’m wondering if I should share your presentation with them.”

>> AMBER: Yes. Some of them have reached out to me already. The Brooks team reached out to me, for example. I am planning on reaching out to all of them and sharing this information with them. I will say if you actually– I don’t pay, for example, Avada any money, so they probably think a lot less about what I have to say than if I had 100 licenses of Avada. I would say you should also do it, [chuckles] and get anyone else to do it, because the more people that go to these builders and say, “Hey, you really need to make this accessible,” the more they’re going to prioritize it.

>> PAOLA: We have a few more questions about details on the audit. One of them is from Christian, and it says, “For one link card style, should it be the heading that is the link before the descriptive text?”

>> AMBER: No. One link card title– oh, sorry, for the descriptive text of the link. I think maybe that’s what you’re saying. The way we do this when we build custom blocks is the A tag goes around everything. The image is treated as decorative. Typically, we add the aria-label on the A tag and it is just the title of the post. If the excerpt is really important, then you might not have the aria-label. You would have an empty alt on the image, it would have the title, and it would have the excerpt, but you want to be careful about doing that and then having a date and all this meta.

Honestly, I go down to more simplified. I don’t know if on your homepage it necessarily matters the date the post was published. Maybe it matters who the author. Sometimes it does. You have to be thoughtful about this and figure out what is the important information. No matter what it is, the title should be first. Even if visually you have categories, for example, this has come up on websites we’ve audited with blind people. If the categories appear before the title in the link, then it takes them a while to hear the title.

If you’ve ever watched a screen-reader user go, they go very fast and don’t listen to everything. They listen to like the first part until they’re able to identify what it is and decide if they want to go there or not. No matter what, I would always have the title first, and then any other context that you think is important. A lot of times, even the categories, we’ve had our users tell us the category of a blog post on that page, they consider it decorative. They’re like, “I don’t care. I want the title. I want to know what I would go click on to learn more.”

>> PAOLA: Another question. David asks, “For post lubes, should we use a P tag if it is only an image and a post title?

>> AMBER: You should not use a heading if you don’t have any content following the heading, it should be a P tag.

>> PAOLA: What was the issue with Swiperjs? Swiper JavaScript?

>> AMBER: Yes, that’s the slider that is used by Elementor and a couple of the other plugin. The things that are fails on that sheet specifically, I don’t remember off the top of my head, so give me just a second. Those typically came from Swiper. Let me just look at Elementors, for example. It doesn’t shift focus when you click the button in the dot navigation button. I lost that tab. What was the other thing? Oh, the pagination. The pagination dots are not always– oh, wait, sorry. No, that wasn’t on them. Never mind.

Keyboard focus. That was the big thing. Things that were hidden would still get read out. That’s probably the hardest thing. That keyboard focus would go to something, but it wouldn’t become visible. You just tab a bunch, and you’d be like, “Where am I? Oh, I’m in the three slides before this one slide that I can currently see.”

>> PAOLA: Got it. We are out of time, but we do have a few minutes with a capture. We have a couple of questions to be answered.

>> AMBER: I’ll try and go fast.

>> PAOLA: Should the screen reader still access the content if the accordion is closed, or only the visible collapsed items?

>> AMBER: Only the visible collapse items. You should never be able to hear anything that is not visible on the page unless it is intentional screen-reader text.

>> PAOLA: Then why did you fail people for not having visible persistent labels on search fields when they are specifically exempted?

>> AMBER: They’re exempted in the WordPress accessibility-ready requirements that were last updated in 2014. They are not exempted in web content accessibility guidelines. I will tell you the big project that I’m working on right now on the core for the accessibility team is working on putting together a proposal to update those requirements.

>> PAOLA: Perfect. The last questions that we have here is from Hamal. “If all of this checks in or passes for any website, did they get the AA accessibility rating?

>> AMBER: No. What I did was not a full accessibility audit of everything and not a full WCAG audit. Now, it was, for like tabs, everything I listed there would be yes. Even if a builder got 100% on this sheet, it would not mean– because I didn’t test everything, so it wouldn’t be 100% WCAG-compliant necessarily.

>> PAOLA: Okay, perfect. I think we are out of time, Amber. Do you have any parting thoughts, and where can people find you?

>> AMBER: Hold on. I saw what Dean said about labeling controls. I think that the search-form label. I don’t know. I’ll look back at that, but I thought that I saw some more recent requirements on that, that it was required by WCAG. I appreciate the link, and I will review back on that. I know you guys all know where to find me, but a good place to get me if you don’t want to– you can obviously email meetup@equalizedigital.com, but also I’m on Twitter @AmberHinds or in make WordPress Slack and just at Amber Hinds. Pretty sure. You can find me there as well if you have any follow-up questions.

The biggest thing I would say is no matter what builder you’re using, if you can go to them and encourage them to do better, because everyone who’s here, we all know about accessibility. You’re here because you care, but a lot of users who especially use Page Builders and some of these really big Page Builders have no idea. They’ve probably never even heard about accessibility.

I feel like all of us as accessibility advocates, we can make a huge difference for WordPress and for people with disabilities by going to the people who build the builders and saying, “Hey, this is really important,” because that’s what’s going to make it easier for all of the people who don’t know anything. They just have a beauty parlor and they want people to know how much haircuts cost to have accessible websites that work for people with disabilities.

If you can, go to whatever builder you use as the person who pays for it, or uses the free version or whatever, and encourage them to make it accessible, because that’s what’s going to make the biggest difference for web. That’s my soap box for the evening.

>> PAOLA: Thank you, Amber.

>> AMBER: All right. Thanks, everybody. We’ll see you in a couple of weeks.

>> CHRIS: Thanks for listening to Accessibility Craft. If you enjoyed this episode, please subscribe in your podcast app to get notified when future episodes release. You can find Accessibility Craft on Apple podcasts, Spotify, and more. And if building accessibility awareness is important to you, please consider rating Accessibility Craft five stars on Apple podcasts. Accessibility Craft is produced by Equalize Digital and hosted by Amber Hinds, Chris Hinds, and Steve Jones. Steve Jones composed our theme music. Learn how we helped make 1000s of WordPress websites more accessible at equalizedigital.com.