WordPress Page Builder Accessibility Comparison

No matter how diligent you are about entering your content in an accessible way, an accessible website is impossible without a solid foundation.

The theme and page builder or block library you choose for your WordPress site controls a significant portion of your website’s accessibility. If these components are not accessible, you’re going to have an uphill battle trying to patch them with JavaScript and ensure they stay patched with every update released.

The easiest way to have an accessible website is to choose themes and plugins that have already considered accessibility. Then all you have to do is add your content without worrying about the underlying code.

We frequently get asked which page builder provides the best accessibility starting point. This post compares the accessibility of popular page builders and WordPress block libraries to help you choose the right builder for your WordPress website.

If you have already selected a page builder for your website, find out how it compares to competitors when it comes to accessibility. This report will also show you accessibility issues that may exist on your website and fixes you may need to make to ensure compliance with accessibility laws worldwide.

Table of Contents

• Testing Methodology
  • Test Dates
  • Included page builders
    • Why is Gutenberg not included?
  • Tests include paid features
  • Testing site setup
  • No third-party components
  • How we tested
    • Accessibility Checker
    • Manual testing process
• Reporting and Scoring Methodology
  • Google Sheet for reporting
  • Explanation of scores
  • How page builders were ranked
• Components Tested & Results
  • How components were selected
  • Skip links
  • Navigation
  • Header search
  • Accessibility Ready requirements
  • Accordions
  • Carousels or sliders
  • Icon list
  • Loop/post blocks
  • Tabs
  • Testimonials
• Final Results
  • Summary of scores
  • Page builders ranked from best to worst
• Get the Data
  • Data request form
  • Video walk-through of the spreadsheet
• Closing Thoughts
  • What does this mean for your website?
    • No builder is perfect
    • Many factors impact website accessibility
    • The first step is to start testing
    • Simplifying can make accessibility easier
  • Page builder reaction

Testing Methodology

This report covers the accessibility of 10 popular WordPress page builders or block libraries that can be used to build professional WordPress websites for businesses or nonprofits.

For purposes of this report, we’re using the term “page builders” to refer to both page builders and also themes and block libraries that work in the core WordPress block editor (Gutenberg). We’re broadly defining “page builders” as any toolset that can be used to create a WordPress webpage.

Below is an explanation of how tests were performed for this study.

Test Dates

Page builder accessibility tests were completed between May and July 2024. The current production (live) version of each builder was used.

Included page builders

The following page builders are included in this report:

• Avada
• Beaver Builder
• Breakdance
• Bricks
• CoBlocks
• Divi
• Elementor
• GeneratePress
• Kadence
• Page Builder by Site Origin

These page builders were selected based on active install counts and whether we were able to obtain copies of current zip files or access staging sites for the builder to test.

This report will include additional page builders in the future, including WP Bakery, Oxygen, and Astra/Spectra, which are currently being tested.

Why is Gutenberg not included?

Many people have asked why Gutenberg or WordPress core is not included in this comparison. The reason Gutenberg was not included in this builder accessibility comparison is that Gutenberg does not have the components that other page builders and block libraries have. This audit looked at accordions, tabs, carousels, etc. Because core WordPress lacks these features, there is no way to compare it to the tools tested in this study.

Tests include paid features

If a pro or paid version exists for the page builder, the paid version of the builder was tested. Some features tested may not exist in free versions of the builders.

We accessed the paid versions of these builders in multiple ways:

• We or one of our clients already pay for the builder.
• The builder had a public demo linked on their website.
• A WordPress community member who pays for the builder gave us files or created a staging site so we could test it.
• The company that created the page builder gave us a free license so we could test it.

How we accessed the page builder has no impact on its accessibility score. We were not compensated for testing any of these page builders and do not plan to use the free licenses on any public websites.

Testing site setup

Each page builder, if a plugin, was tested using its companion theme. For example, Elementor was tested with the Hello Elementor theme, and Kadence Blocks was tested with the Kadence Theme, etc. The only plugin that was not tested with a companion theme was CoBlocks, which was tested in the Twenty Twenty-Four theme.

For each builder, we added basic or filler content only and no CSS styles. If the builder had templates to create a header and navigation menu, then we used a template to create the header, but the remaining content was completely unstyled.

For example, here is a screenshot of the testing page for Breakdance, showing a styled header from a template and components in black and white added to a page.

These tests focused on the underlying HTML of each element, not on how easy it is to add different components or style them in a particular way. We followed content accessibility best practices and did not add accessibility issues within the content.

We also looked at how easy it was to utilize the component in an accessible way. Numerous checks tested whether controls were provided to users to choose heading levels, define accessible names, or set other necessary accessibility-related settings.

No third-party components

Tests were conducted on elements and components solely controlled by the page builder and did not include any third-party add-ons. For example, we did not add one of the third-party plugins that fix accessibility in Divi prior to testing; instead, we tested Divi’s accessibility alone.

We feel strongly that page builders need to make their base components accessible.

Users should not have to purchase additional add-on plugins to fix known accessibility problems in their page builder. All developers should consider accessibility in their core products.

How we tested

Each page builder was tested using both automated testing tools and manual testing techniques.

Accessibility Checker

If we could install plugins on the testing website, we installed Accessibility Checker Free to scan test pages for issues. Accessibility Checker is a WordPress plugin that helps you quickly find accessibility problems in your content or those created by plugins and themes.

Accessibility Checker made it fast and easy for us to identify things like empty links and buttons, missing alt attributes, ambiguous links, out-of-order headings, and more.

Manual testing process

In addition to automated testing with Accessibility Checker, we also performed manual accessibility tests by:

• Using keyboard navigation (Tab key) to move through the site.
• Testing links with the Return/Enter key.
• Testing buttons with both the Return/Enter key and Space Bar.
• Inspecting the HTML code in the browser dev tools inspector.
• Listening to the website with Voiceover (a screen reader for Mac).
• Zooming the page to 200% and 400% to ensure components work on Zoom.

Not all accessibility testing can be identified with automated tools alone and manual tests are an important part of accessibility audits. Learn more about manual accessibility testing.

Reporting and Scoring Methodology

Google Sheet for reporting

The results were tracked in a Google spreadsheet as testing was completed. The data for each builder is accurate as of the test date and publication of this post, but it may have changed if the page builder has released an update.

The first column of the spreadsheet lists each item checked, grouped by component. There is a column for each builder under which you can see their scores. Builders received either a pass, fail, concern, or N/A for each item checked.

You can request access to this spreadsheet with all the data below. This post includes tables with high-level scores, but due to space limitations, comments are only available on the Google Sheet.

Explanation of scores

The scores for each check were given as follows:

• Pass: The element exactly matched specifications and the page builder was doing that specific thing right from an accessibility standpoint.
• Fail: The element or attribute was missing or not coded correctly. The page builder is clearly failing to meet the specific accessibility check. When given a “fail,” there is typically a note in the cell explaining why.
• Concern: The element or check mostly passes, but some small part of the component doesn’t pass, or the builder has options that would lead to a content creator adding accessibility problems. When given a “concern” there is typically a note in the cell explaining why.
• N/A: This stands for “not applicable” and is given when an element or component does not exist in the builder, and thus the check cannot be completed.

How page builders were ranked

After testing each component and scoring all relevant checks, the page builders were ranked from best at accessibility to worst at accessibility. This is how we calculated the page builder accessibility ranking:

1. Total all cells that contain “pass” for each page builder.
2. Total all cells that contain “fail” for each page builder.
3. Total all cells that contain “concern” for each page builder.
4. Calculate a percentage passing from all applicable checks.

The percentage passing was calculated in this way:

Here is an example of how this calculation works with sample numbers:

• Total pass: 3
• Total fail: 7
• Total concern: 2

(3/(3+7+2))x100=25%

In this example, we first add three, seven, and two together (this gives us 12). Then, we divide three (the total passed) by 12 (the total of pass, fail, and concern). Finally, multiply the result by 100 to get the percentage: in this case, 25%.

Using a percentage of applicable checks allows us to determine how good any given page builder is at writing accessible code when they do code things. It doesn’t penalize builders for having fewer components, as would happen if we ranked the page builders simply by the most passes.

After getting a percentage passing of the applicable checks, we were able to rank the page builders from best at accessibility (highest percentage passing) to worst at accessibility (lowest percentage passing).

Components Tested & Results

How components were selected

We chose components to test based on how commonly they are found on business websites or on websites designed by a professional designer and built by a WordPress developer. The tested components are not necessarily all components that have to be included in websites, but they are frequently used to make websites appear more polished or interactive.

We also tested for the WordPress Accessibility Ready requirements and other theme features, such as skip links and navigation. As an accessibility best practice, these components should exist in all themes.

Skip links

Skip links are a WCAG requirement and an important accessibility feature for sighted keyboard-only users and people who are blind using screen readers. Learn more about skip links and testing skip links.

When accessibility testing skip links, we checked:

• That a skip link was present.
• The skip link was the first focusable element.
• The skip link has at least AA color contrast.
• Skip link shifts keyboard focus to content as expected.
• Bonus: Skip to navigation is present (this can be helpful but is not required).

The following table shows how each page builder scored in these tests.

Navigation

Accessible navigation is vital to allowing people to move around your website, read your content, and access the pages where sales and conversions happen. Learn about coding accessible WordPress navigation menus.

When accessibility testing navigation, we checked:

• The navigation menu is contained in a <nav> tag.
• The <nav> tag is labeled with an aria-label.
• Users can define the nav tag aria-label – this is important especially for utility, footer, or secondary menus, as the aria-label should describe the links contained in the navigation.
• Subnavigation dropdowns were keyboard accessible.
• There are separate buttons for opening and closing dropdowns.
• CTA/buttons styles achievable in primary navigation – this could be possible by allowing a class to be set. It is important to allow people to set a nav link to look like a link; if that’s not easy to do, people incorrectly add these in separate widget areas outside the <nav> tag.
• All focusable elements had a visible keyboard focus.
• The mobile menu (which becomes visible on desktop on zoom) is keyboard accessible.

The following table shows how each page builder scored in these tests.

Header search

Many business websites include a button in their header that allows users to open a search form in a modal or expanded section. These search forms can make websites more user-friendly, but only if they’re coded with accessibility in mind.

When accessibility testing header search components, we checked:

• The button to open the search form is an HTML <button> or a correctly remediated element with role="button" that includes Space Bar handlers.
• The search form overlay has a focus lock so it cannot be tabbed out of without being closed.
• The search form field is labeled.
• The search form label stays visible when the field has data typed in it – I.e., the form cannot use placeholder text in place of visible labels.
• There is a button to submit the search form. Relying on the Return/Enter key alone is not sufficient.
• The button to submit search is labeled.
• The overlay close button is a button.
• The close button is labelled.
• Any search suggestions are keyboard and screen reader accessible (none had these).

The following table shows how each page builder scored in these tests.

Accessibility Ready requirements

These are requirements for themes to have the Accessibility Ready tag in the WordPress.org theme directory. Accessibility Ready requirements are created in accordance with the Web Content Accessibility Guidelines (WCAG). If you are choosing a WordPress theme, you want it to pass these requirements to ensure you are off to the best start.

When accessibility testing if a page builder was “accessibility ready,” we checked:

• There were controls allowing the website owner or developer to add HTML attributes as needed (aria-label or lang, for example).
• The theme had support for .sr-only or .screen-reader-text CSS classes baked in so that these classes could easily be added to elements in the builder to add additional information for screen reader users.
• There is a visible keyboard focus on all elements, the focus follows the visual order of the page, and all expected items are keyboard focusable.
• Theme features that behave as buttons or links must use <button>, <a>, or <input> elements.
• All controls must also have machine-readable text to indicate the nature of the control.
• Comment forms must have appropriate field labels, and all content within form tags needs to be explicitly associated with a form control.
• Post-submission responses on the comment form (errors or confirmations) are perceivable.
• Every page has an H1 (we looked at the home page, a standard page, the blog archive, a category archive, and the blog single).
• No skipped heading levels out of the box (for this, we looked at the same pages previously listed for the H1).
• The header is contained in a <header> tag or has role="banner".
• The main content in a <main> tag or has role="main".
• Any sidebars are in <aside> tags or have role="complementary".
• The footer is in a <footer> tag or container with role="contentinfo".
• No content was outside HTML landmarks (aside from the skip link, which should be just above the <header>).
• Content links were underlined by default or can be underlined without writing CSS styles.
• No title attributes were on images.
• No images were missing the alt attribute.
• No positive tabindex on any element.
• No links opened tabs in new windows without warning the user.

Learn more about WordPress Accessibility Ready requirements for theme developers.

The following table shows how each page builder scored in these tests.

Accordions

Accordions are incredibly common on most websites, especially when it comes to displaying frequently asked questions or similar groups of content. If your page builder does not code accordions accessibly, many users will not be able to access the content hidden in them. Learn how to code accessible accordions.

When accessibility testing accordions, we checked:

• The accordion titles were headings with <button> tags in them.
• The buttons use aria-expanded to communicate to screen reader users if they are opened or closed.
• The buttons use aria-controls to reference the relevant content panel.
• Users (website editors, developers) can choose the heading level so their accordion titles are properly nested in the outline of the page.
• All focusable elements had a visible keyboard focus.
• The accordion works on zoom for low-vision users.

The following table shows how each page builder scored in these tests.

Carousels or sliders

There are many arguments against using sliders or carousels on websites, and we typically avoid putting them on websites we build. However, sliders remain a favorite component for many website owners, especially in that prime spot at the top of the home page.

Unfortunately, many page builders miss the mark when it comes to carousel accessibility, so if you have a carousel or slider on your website, you should test it to confirm it’s accessible. How to test sliders for accessibility.

When accessibility testing sliders, we checked:

• The carousel is wrapped in a <section> tag (or container with role="region") with an aria-label or aria-labelledby attribute naming it. Carousels have many components contained in them and grouping all the components in a sematic region that can make them much easier for screen reader users to understand and navigate.
• Slides must be contained in an unordered (<ul>) list.
• Content creators need to have the ability to set heading levels if headings are present so that the heading levels makes sense in the context of the page.
• Previous/next and dot navigation are <buttons>.
• All buttons have meaningful labels.
• Dot navigation includes aria-current for the current item
• Keyboard focus does not go to any hidden items (such as links on slides that are not currently visible).
• Screen readers don’t read any hidden items.
• Focus shifts to the selected slide when using navigation buttons – this is important so screen reader users don’t have to Shift+Tab backward to find the slide they have selected.
• Auto-play carousels have a pause button or the ability to add a pause button.
• Animations respect prefers-reduced-motion – this is an operating system setting that allows users to communicate to websites that they don’t want any animations. If a user has this turned on, then sliders should not auto-play.
• All focusable elements had a visible keyboard focus.

The following table shows how each page builder scored in these tests.

Icon list

Icon lists are commonly used to group lists of features or benefits with decorative icons to make each item stand out. Businesses and theme designers love to include icon lists everywhere, from home pages to product pages and pricing tables. These are relatively simple components that can add accessibility issues for screen reader users, particularly if they don’t utilize HTML list format to group the items. Learn how lists help accessibility.

When accessibility testing icon lists, we checked:

• The elements are coded as an unordered list (<ul>).
• The icon has aria-hidden="true" on it so it will not be read out to screen reader users.
• The icon list wraps and reflows on zoom for low-vision users.

The following table shows how each page builder scored in these tests.

Loop/post blocks

Want to display three recent blog posts on your home page? You need a loop, a.k.a. post block. These components are incredibly helpful for drawing extra attention to blog posts and can also display grids of team members, a portfolio, or a list of featured products.

When accessibility testing loop/post blocks, we checked:

• Bonus: 1 link, card-style – this would be the ideal way to link each post, though few developers do it.
• The page builder should hide redundant links from screen readers and keyboard users. (I.e., there’s no need to tab through a linked image, then linked title, then read more link for every post.)
• The posts are in a list.
• Content creators should have the ability to choose the heading level or set a p tag for post titles so it makes sense in the context of the page.
• Read more links are not ambiguous and include the post title to differentiate them from one another.
• Linked image alt describes purpose – the correct alternative text for a linked image in a post loop is the title of the post, not a description of the image or alt text set in the Media Library.

The following table shows how each page builder scored in these tests.

Tabs

Tabs, like accordions, allow WordPress designers and content creators to group and collapse content interactively. If not coded correctly, tabs (and all the content in the not selected tabs) will be completely inaccessible to screen reader and keyboard-only users.

When accessibility testing tabs, we checked:

• The tab controls container has role="tablist".
• The tab controls are HTML buttons.
• Checked to see in tab controls are in an HTML list or announce as a list by screen readers.
• Tab controls have role="tab" and aria-controls referencing the tab content container ID.
• The current tab control button has aria-selected="true".
• Tab panels have role="tabpanel".
• Tab panels have aria-labelledby referencing the button.
• All focusable elements had a visible keyboard focus.

The following table shows how each page builder scored in these tests.

Testimonials

The last component we tested for accessibility was testimonial blocks, which had the greatest variety. Some were standalone quote blocks, while others were carousels. Social proof is incredibly important, but it won’t do much for your brand if everyone can’t access it.

When accessibility testing testimonials blocks, we checked:

• The testimonial quotes are contained in a blockquote tag.
• There were no random headings – I.e., the builder should not use headings to make text big.
• If the testimonials were in a carousel, the carousel is accessible (following the same checks listed above for carousels).
• Images or icons (star ratings), if included, are accessible with proper alt text or aria-labels.

The following table shows how each page builder scored in these tests.

Final Results

Summary of scores

The following table shows a count of cells containing “pass,” a count of cells containing “concern,” and a count of cells containing “fail” for each page builder. As not all checks were applicable to all builders, the total of these three rows is not the same. Remember, we calculate the ranking based on a percentage of passed checks of applicable checks for each builder.

After completing a nearly 100-check accessibility audit using automated testing tools and manual testing techniques of ten different page builders, we can confidently report that:

Kadence is the best page builder for accessibility today.

Of the ten page builders tested, Kadence had the highest percentage of passing checks (75.95%), with Elementor in second place (70.13%).

Divi is the absolute worst page builder for accessibility.

Divi had the worst score for accessibility (only 16.22% passing), and it wasn’t even close to the page builder that came in 9th place (Beaver Builder – with 48.00%). Divi has a ton of catching up to do.

The following table shows page builders ranked from best to worst based on their percentage of passed accessibility checks.

Page builders ranked from best to worst

Rank	Page Builder	Percent Passing
1		75.95%
2		70.13%
3		67.80%
4		59.21%
5		54.67%
6		52.38%
7		51.90%
8		50.00%
9		48.00%
10		16.22%

Get the Data

There’s much more than we could fit in this blog post!

Data request form

Fill in this form if you would like us to email you a link to view the Google Sheet with full results from our accessibility tests, including explanations of “fail” and “concern” items.

Name(Required)

First Last

Email(Required)

Company Name(Required)

Privacy Policy(Required)

I opt-in to sharing my information with Equalize Digital to receive the Google Sheet link and relevant emails. I can unsubscribe at any time. For more information, see the privacy policy.

Name

This field is for validation purposes and should be left unchanged.

Video walk-through of the spreadsheet

Watch a recap of the June 15, 2024 WordPress Accessibility Meetup, Which Page Builder is the Best (or Worst) at Accessibility, where Amber walks through the spreadsheet of data, explains her thoughts on each line item, and the final results.

Closing Thoughts

What does this mean for your website?

You may be wondering what this page builder accessibility comparison means for your WordPress site. Here are some things that you may want to keep in mind as you consider the results.

No builder is perfect

Regardless of which builder you use to build your website, there are likely to be accessibility problems. If you use one of the builders and the components listed above, your website may need to be fixed.

Many factors impact website accessibility

Accessibility issues in WordPress websites can come from your page builder, the plugins you install, or how content is entered on the site. Even the best page builder can create an inaccessible website if you don’t pay attention to content accessibility best practices. Likewise, a skilled developer or the right third-party plugin can remediate accessibility problems and create an accessible website even with a page builder that didn’t score as well.

The first step is to start testing

You can’t fix accessibility problems you don’t know about. Install our free Accessibility Checker plugin on your WordPress website today and start finding and fixing accessibility problems right away.

Simplifying can make accessibility easier

If you don’t have a slider on your website, it doesn’t really matter if your page builder doesn’t have accessible sliders. Making your website accessible doesn’t have to break the bank. Sometimes, the easiest fix for big accessibility problems is to replace complex problematic components with simpler ones. There are ways to improve accessibility on your website even if you can’t change your bage builder right away.

Page builder reaction

Testing page builders for accessibility took several weeks and is an ongoing project.

We’re thrilled to report that since initially releasing this data at a WordPress Accessibility Meetup, several page builders have reached out to us for additional information about how they can make their tools more accessible. (Shout out to Tom from GeneratePress, who released some fixes within hours of getting access to the Page Builder Accessibility Comparison Google Sheet!)

There were also a few page builders who asked to be included in this report out of genuine interest in getting feedback to make their products better.

We applaud the companies and individuals behind these tools who take accessibility feedback to heart and are willing to make their products work for all users regardless of ability.

Our intent with this report is to make it useful for both website owners and page builder developers. We’ll be adding additional page builders in the coming months and will update this report and ranking on at least an annual basis—we can’t wait to see which builder passes 100% of the tests first!