If you have a WordPress site built on Divi and an accessibility report telling you to rebuild it from scratch on a different theme, you probably do not need to rebuild it. You probably need to fix five specific things, and four of them take less than an hour each.

Divi gets a bad rap in accessibility circles, and some of it is fair — the visual builder produces nested DOM that is heavier than what a developer would write by hand, and the shape-first design philosophy puts a lot of meaning in CSS that does not always survive the trip to a screen reader. But “Divi sites are inaccessible” is a generalization that papers over the actual problem. The actual problem is a small set of specific patterns that the visual builder makes easy to introduce and slightly harder than necessary to find later.

We have audited a meaningful number of Divi-built sites in the last few months. The five issues below show up on roughly every site we look at. None of them are platform limitations. All of them are fixable inside Divi without changing themes, and four of them do not require a developer.

Why Divi sites are easy to break

Before walking through the five issues, it is worth understanding why they are so common, because the same root cause sits underneath all of them.

Divi is a visual builder. You drag rows onto a page, drop modules into the rows, style each module from a panel, and the result is a beautiful page that looks exactly the way you designed it. The thing the visual builder is fundamentally optimizing for is what the page looks like. The thing it is not optimizing for, because no visual builder really can, is what the page sounds like to a screen reader or feels like to a keyboard user.

The result is a workflow where the designer or owner can produce a stunning page without ever once being shown the underlying HTML, and the underlying HTML can have heading levels that do not match the visual hierarchy, ARIA attributes that were never set, and dynamic interactions whose state is invisible to assistive tech. The page looks done. It is not done.

Most of the patterns below are a direct consequence of this gap between visual editing and DOM reality.

The five things that almost always fail

1. Heading hierarchy that the Theme Builder broke

Divi’s Theme Builder lets you define page templates that override how individual posts, archives, or product pages render. This is enormously useful — it is one of the reasons people choose Divi. It is also a common source of broken heading hierarchy.

The pattern: the page template puts an H1 with the post title at the top. The body of the post, written by an editor in the Visual Builder for that page, also has an H1 because the editor wanted a big heading. The page now has two H1 elements, which violates the accessibility expectation that a page has exactly one. Worse, the section that introduces the actual content of the post is often tagged H3, because it visually fits between the post-title H1 and the body subheadings — but H3 without an H2 between them is a heading-level skip, which throws off screen reader navigation.

The fix is in the Theme Builder template: confirm the template uses one H1 for the post title, then the editor’s body should use H2 for top-level sections, H3 for subsections, and so on. Open every page where the Theme Builder is overriding the layout and verify there is exactly one H1 and the levels descend without skipping.

2. Modules that are hidden on mobile but still in the DOM

Divi has a control on every module called “Disable on” with checkboxes for Phone, Tablet, and Desktop. Designers use it constantly — show this hero image on desktop, show that simpler version on mobile, hide the third on tablet. Visually it works. The issue is that “Disable on” applies CSS display: none to the module on the targeted breakpoint, but the module stays in the DOM, which means a screen reader user on a phone is still announced the desktop-only content if their assistive tech does not respect the display: none rule (and many announcement modes do not).

The result: a visitor on VoiceOver on iPhone hears two heroes, two CTAs, two paragraphs of intro text — one of which is invisible to sighted users and was never meant for them. The mobile experience for screen reader users contains more confusing duplicate content than the desktop one.

The fix is to use aria-hidden="true" on hidden modules in addition to the visual hide, or to use Divi’s built-in “Disable on” along with a separate Custom CSS rule that adds aria-hidden based on the screen size. Less elegant: actually delete the duplicate modules and rely on responsive CSS to reflow content. Either way, the screen reader needs to be told the hidden module is not for them.

3. Image alt text that defaults to the filename or nothing

Divi’s Image module has an Alt Text field. It is empty by default. When you upload an image directly into the Visual Builder without going through the Media Library first, the alt text is empty and stays empty until you remember to fill it in. When you upload through the Media Library and then insert from there, the alt text inherits whatever you put in the Media Library — which, on most sites we audit, is nothing for older uploads and the filename for the more recent ones.

The result: image alt text on Divi sites is a coin flip between blank, gibberish (IMG_4823), and accurate. Screen reader users have no way to know which they are getting until they hear it.

The fix is tedious but mechanical: open every page in the Visual Builder, click each image, set the Alt Text field. Decorative images — dividers, textures, background flourishes — should have empty alt (the field is set to the literal value "" or just left blank with role="presentation"). Photos, diagrams, product images, screenshots all need real descriptions. The Bulk Edit option in the WordPress Media Library can speed this up if you have hundreds of images to handle.

4. Sliders, Toggles, Tabs, and Accordions with no announced state

Divi ships a set of interactive modules that look great and announce nothing. The Slider module rotates through panels. The Toggle module expands and collapses. The Tabs module swaps content. The Accordion module opens and closes sections. All four are built with custom JavaScript that updates the visual state without telling the screen reader anything has happened.

A keyboard user navigating to a Toggle module presses Enter to expand it, hears nothing, has no idea whether the action did anything. They press Enter again to close it, hear nothing again. The module is functionally invisible to anyone who cannot see the chevron rotating.

The fix is the same on all four module types: add ARIA attributes and announcement logic. The Toggle module needs aria-expanded="true|false" on the trigger button, updated when the state changes. The Tabs module needs role="tablist", role="tab", role="tabpanel", aria-selected, and aria-controls to wire the relationships. The Slider module needs an aria-live region that announces “Slide 2 of 5: [title]” when the slide changes. The Accordion module needs the same treatment as the Toggle.

This is the only one of the five patterns that requires actual code. It is also the one that most Divi sites we audit have shipped without. If your site uses these modules and you have not customized them, they are almost certainly silent to screen readers.

The Divi child theme is the right place to add this. Override the module’s frontend JavaScript to inject the ARIA updates. There are several free child theme templates floating around the Divi community that include accessibility-corrected versions of these four modules, which is faster than writing them yourself.

5. Color contrast in module-level styling overrides

Divi lets you set colors on every module — text color, background color, button colors, link colors, hover colors. The global theme sets defaults; individual modules override them. The contrast between text and background on each module is whatever the designer happened to pick when building that module.

The result is a site where the homepage hero might pass WCAG AA contrast (because the designer was paying attention) and the testimonials section might fail it (because the designer used a softer grey for “personality”). The site’s contrast is not one number; it is a different number on every module, and most of them have not been measured.

The fix is purely manual. Use the Divi Theme Customizer to set global defaults that pass WCAG AA at minimum (4.5-to-1 for body text, 3-to-1 for large text). Then walk through every page module by module, copy each text color and background color combination into WebAIM’s free contrast checker, and adjust whichever combinations fail. There is no shortcut here, but the work is bounded — most Divi sites have 20 to 40 unique color combinations across the whole site, and once you have audited and fixed the templates that get reused, you have done most of the work.

Verifying the fixes

For four of the five issues — heading hierarchy, hidden modules, alt text, color contrast — running axe-core or WAVE after the fix will tell you whether the change took. The automated scanners catch these patterns reliably.

For the interactive modules, automated scanners cannot tell you whether your ARIA is working correctly, only whether you remembered to add it. The verification step is a manual screen reader pass: open the page in NVDA or VoiceOver, navigate to the Toggle, expand it, and listen to whether the announcement is correct (“button, expanded” vs “button, collapsed”). Repeat for each interactive module type. If the announcements match the visual state, the fix is working. If they do not, something in the JavaScript is not updating the ARIA correctly and needs another pass.

Run the verification on both desktop width and mobile width. Divi’s responsive CSS sometimes hides the desktop-corrected modules and shows uncorrected mobile-only ones, which means a fix that looks complete on desktop is still broken on mobile.

What to ask before you hire someone

If you are paying a developer or auditor to fix accessibility issues on your Divi site, three questions before you sign:

Will the work include modifying the Slider, Toggle, Tabs, and Accordion module JavaScript to add ARIA announcements? This is the only fix in the list that requires actual code. If the answer is “we will use a plugin to handle that,” ask which plugin and verify it actually rewrites those four module types — most accessibility plugins do not.

Will the deliverable include verification on both desktop and mobile? Divi serves slightly different DOM at different breakpoints, and fixes that pass on desktop sometimes regress on mobile. Auditing only one width misses real issues.

Will the work address the Theme Builder template, not just the page editors? If your site uses the Theme Builder for post or archive layouts, the template itself often contains the heading hierarchy bug. An auditor who only looks at individual pages and not at the templates will fix the symptoms without fixing the source.

If those three are clear with examples from past Divi work, the auditor or developer has done the work before. If they are vague, the report you get back is going to look thorough and miss the patterns above.

Closing

Divi is a fine platform for sites where visual flexibility matters more than minimalist DOM. We are not in the camp that says you should switch off it for accessibility reasons. The same five patterns we listed above also show up on Elementor, WPBakery, and to a lesser extent on the WordPress block editor itself — they are visual-builder issues more than they are Divi issues.

What is true is that any Divi site that has not been audited specifically for these five patterns almost certainly has all five. The fix is not a rebuild. The fix is one focused pass through the existing site, fifteen to forty hours of work depending on size, and the same site you have today with the issues that caused the failing report removed.