Your site looks right. The designer spent weeks in Elementor or Divi getting the spacing, the animations and the hero section just so, and nobody wants to throw that away. Then an audit comes back, or a customer who uses a screen reader emails to say they could not find your phone number, and the report is full of things like “empty heading”, “link has no accessible name” and “focus not visible”. Most of these trace back to a small number of builder habits, repeated across many pages. Our Elementor accessibility fixes, and the same work on Divi sites, go after those patterns at the source so the design stays and the barriers go.
Elementor accessibility fixes without starting over
A rebuild is sometimes the right answer, but it is rarely the first one. On most builder sites we can correct the markup the builder produces by changing widget settings, adjusting templates, adding a little CSS and script in a child theme, and editing content. The visual design barely changes. What changes is what a keyboard user, a screen reader user or someone zoomed in to read actually experiences.
This is one part of our wider accessibility work for US businesses. It assumes your site runs on WordPress with a page builder doing most of the layout. If your site uses the block editor and a regular theme instead, our WordPress theme and plugin accessibility work is the closer fit.
Our yardstick on builder sites is Level AA of WCAG 2.2. We do not promise that any page builder site is “compliant” when we finish, because no honest developer can. We tell you which criteria the tested pages meet afterward and which items remain open.
Why page builder output trips up assistive technology
Page builders are visual tools. You drag a box, pick a font size, and the builder writes the HTML for you. That HTML is usually several nested wrapper elements deep, and the builder has to guess what each piece means. It often guesses wrong, or uses a default the designer never thought to change.
Some examples of what that looks like from the other side:
- A screen reader user pulls up the list of headings and hears “heading level 2, Welcome” followed by eleven more level 2 headings, some of them just a phone number styled large.
- A keyboard user presses Tab and focus jumps into an icon list where every icon is a separate link with no name: “link, link, link”.
- A tabs widget looks like tabs but behaves like a stack of clickable boxes, so arrow keys do nothing and the screen reader never says which tab is selected.
- An entrance animation fades text in from the side every time you scroll, which is distracting for many people and a real problem for anyone with motion sensitivity.
None of this is unique to one builder. The specific widgets differ, but the cause is always the same: visual settings were chosen and the meaning of the content was left to defaults.
Elementor patterns we fix most often
Heading widgets used for decoration
The Heading widget outputs an H2 unless someone changes it. Designers use it for taglines, prices, phone numbers and button-like labels, so a page can end up with a dozen headings that are not headings at all. We set each one to the right level or change it to a paragraph, and we check the page title is the single H1.
Icon boxes, icon lists and social icons
When the icon is the link, it needs a text name. When the icon sits next to text that already says the same thing, it should be hidden from screen readers. We sort out which is which and fix both.
Carousels and sliders
Autoplay without a pause control, slides that stay in the tab order while hidden, and arrow buttons with no names are the usual findings. Sometimes the honest recommendation is to replace the slider with a static section. Our guide to making carousels and sliders usable explains the tradeoffs.
Popups
Popups built with a builder’s popup tool often open without moving focus into them, cannot be closed with Escape, and leave focus stranded on the page when they close. We correct the focus handling and the close button. The details of good dialog behavior are in our article on accessible popups and modals.
Forms and buttons
Builder forms sometimes hide labels and rely on placeholders, and button widgets are sometimes plain links styled as buttons with text like “Click”. We restore visible labels, check error messages and give buttons text that makes sense out of context.
For an owner-level explanation of these problems, with the habits that prevent them, read our article on common Elementor accessibility problems.
Divi accessibility: the modules that need attention
Divi sites share many of the same root causes but show them through different modules. The ones we look at first:
- Slider and Fullwidth Slider modules, for autoplay, hidden slides in the tab order, and controls without names.
- Toggle, Accordion and Tabs modules, for whether the open or closed state is announced and whether they work from the keyboard.
- Blurb modules, where an image or icon and a title are often both linked to the same page, giving a keyboard user two stops and a screen reader two identical links.
- Contact Form and email opt-in modules, for visible labels, error wording and the success message.
- The Divi menu and mobile menu, for keyboard access to submenus and a proper toggle button.
- Text modules where heading levels have been picked for size.
There are third-party plugins that patch some Divi behavior for accessibility. They can help, but they do not replace testing, and they sometimes fix one thing while changing another. We test with and without them before recommending one. Our separate article on Divi theme accessibility covers this ground for site owners in more depth.
Other builders, briefly
We also work on sites built with WPBakery, Beaver Builder and a few others. The approach is the same: find the repeated pattern, fix it where the builder generates it, then fix the content. Older shortcode-based builders can be harder, because their markup is less flexible and some widgets cannot be changed without replacing them. In those cases we say so plainly and give you the options.
Add-on packs deserve their own mention. Many Elementor sites carry one or two bundles of extra widgets from other vendors: fancy headings, flip boxes, timelines, mega menus. Each bundle has its own markup and its own update schedule, and their quality varies a lot. We note which add-on each problem widget comes from, because the fix and the long-term risk depend on whether that vendor is still maintaining it. A widget from an abandoned pack is usually better replaced than patched.
If you are weighing a move away from a builder altogether, our post on moving from a page builder to the block editor covers what that migration involves.
Motion, color and focus: the design choices that need a second look
Some barriers on builder sites are not about one widget. They come from design choices applied everywhere.
Animation
Builders make it easy to fade, slide, zoom and parallax nearly anything. A little motion is fine. Constant motion is tiring, and for people with vestibular conditions it can cause real discomfort. Success criterion 2.2.2 Pause, Stop, Hide asks for a control whenever content moves on its own for more than five seconds alongside other content, so a looping background video or a logo ticker in the footer needs a pause button. We add CSS that respects the reduced-motion setting people can turn on in their operating system, remove animation from text that people need to read, and add pause controls where moving content stays.
Color
A brand palette set once in global styles is usually tested by nobody. We measure text against its real background, including text laid over photos and gradient sections, and check buttons and form borders against the 3:1 non-text contrast level. Where a brand color fails, we suggest a darker shade that stays close to the original rather than a new palette.
Focus
Plenty of builder kits ship with the default outline switched off, since it clashed with the mockup. We put back a clear, on-brand focus style that works on light and dark sections, and we check that sticky headers do not cover the focused element as you tab down the page, which WCAG 2.2 added as 2.4.11.
Fixing it once in templates, not on every page
The fastest way to clean up a builder site is to start with what repeats. Both Elementor and Divi let you build headers, footers and post layouts as site-wide templates, and save sections for reuse. A fix in the header template reaches every page at once. A fix made page by page reaches one.
So our order on a builder site is:
- Site-wide templates: header, footer, single post, archive, search, 404.
- Global styles: colors and fonts set in the builder’s site settings, which decide contrast everywhere.
- Saved and reused sections, such as a call-to-action block that appears on thirty pages.
- Code in a child theme: focus styles, reduced-motion rules, small scripts for focus handling.
- Individual pages, starting with the ones you tell us matter most.
This is also where we spot things like a global color that fails contrast on white, which, once fixed in the global setting, clears dozens of report items in one change.
| Situation on the builder site | Patch it | Consider a rebuild |
|---|---|---|
| Wrong heading levels, missing labels, unnamed icons | Yes, settings and content edits | No |
| Focus outline hidden by builder or theme CSS | Yes, child theme CSS | No |
| Slider or popup with poor keyboard behavior | Usually, or swap the widget | Rarely |
| Menu that cannot be made keyboard friendly | Sometimes, with a different menu widget | If the header is custom-built around it |
| Hundreds of one-off pages with no shared templates | Possible, but slow | Worth discussing |
| Old builder version you cannot update | Limited | Often the better path |
When a rebuild really is the better path, our accessible redesign service builds accessibility in from the first wireframe.
How a builder accessibility project runs
- Inventory. We list the builder, its version, add-on packs, site-wide templates and the pages you consider most important.
- Staging copy. Builders store layouts in the database, so we work on a full copy, never on live pages.
- Testing. A scan with tools like WAVE and axe, then a person working through pages using only the keyboard, then again with NVDA or VoiceOver, at desktop and phone widths, since builders often lay out mobile differently. Our manual testing service describes that method in full.
- Fixes in the order above, templates and globals first.
- Retest with the same method that found each issue.
- Deploy carefully. Builder layouts live in the database alongside your content, so we plan the push to avoid overwriting edits your team made on live in the meantime, then regenerate builder CSS and clear caches.
Records you keep and the logins we need
You get a document that lists each issue, the page and template where it appeared, the WCAG criterion, what we changed, and where the change sits: a builder template, a widget setting, the child theme, or page content. It also includes a one-page guide for whoever edits the site in the builder, with the five or six habits that stop the same problems coming back, such as choosing heading levels on purpose and naming icon links.
From you we need:
- An administrator login and, ideally, hosting access for staging.
- Your builder Pro license and any add-on licenses, so we can update and use the full set of tools.
- A short list of key pages, forms and the journeys visitors most often take.
- Agreement on a brief editing pause before we push changes live.
Checking builder pages yourself afterward
You do not need to trust our report blindly. Open a page you care about and press Tab from the top. Can you see where you are at each step? Does the menu open? Can you reach and close the popup? Install a free browser extension like WAVE and look at the heading outline: does it read like a table of contents? Zoom the browser in well past normal size and look for text that overlaps or disappears.
Then check our work where it is most likely to slip: the mobile layout. Builders let designers hide and show elements per device, so a fix on desktop does not always carry over. Narrow the browser window and repeat the Tab test.
When your own editor can handle it, and when not
Someone comfortable in the builder can change heading tags, fill in alt text, rewrite vague button text and turn off decorative animations. That covers a fair share of a typical report. What usually needs a developer is focus handling in popups, menus and tabs, contrast in global styles that ripples across a brand, and anything the widget settings simply do not expose.
Mistakes that make builder sites worse
- Adding ARIA attributes through a builder’s custom attributes field without testing them, which can make a screen reader announce things that are not true.
- Installing an overlay widget on top, which leaves the builder markup unchanged underneath.
- Fixing pages one by one while the header template keeps the same barrier on every page.
- Updating the builder on live right after fixes, with no retest.
Questions worth asking whoever does the work
- Will you fix templates and global styles first, or page by page?
- How will you test the mobile layouts the builder generates?
- Will your fixes survive the next builder update, and how do you know?
- Which items will you leave open, and why?
Builder updates and the ongoing routine
Elementor and Divi release updates often, and a builder update can change the markup of a widget overnight. Add-on packs update on their own schedules too. That is why Elementor accessibility fixes need someone checking key pages after updates, not only the first time. Our WordPress maintenance plans include careful update handling, and if the builder itself starts misbehaving after an update, our Elementor troubleshooting service handles editor and loading problems.