Elementor makes it easy to build a page that looks right. The catch is that what you see in the editor and what a screen reader or keyboard user gets can be two very different pages. A heading that looks like a heading may be a styled paragraph. A button that looks like a button may be a link to “#”.
Elementor accessibility problems are rarely Elementor’s fault alone. They come from a mix of widget output and how the page was put together. This post walks through the problems that turn up again and again on Elementor sites, how to spot each one, and the building habits that make an Elementor site accessible without starting over.
First, find out what Elementor is actually outputting
The editor shows you design. To see structure, look at the published page, logged out, in a normal browser window. Then do three quick things:
- Click the address bar, then step through with the Tab key and watch where focus goes. Does every button and link get a visible outline? Do you ever lose track of it?
- Run a free scanner on the page and open its heading or structure view. This shows the heading outline as a screen reader would hear it.
- Turn on a screen reader and open its list of links and buttons. Listen for repeated or empty names.
Doing this on your home page alone usually reveals the patterns that repeat across the whole site, because Elementor sites tend to reuse the same sections and templates everywhere.
Headings picked for their size
Expect to find this one first. Someone wants big text, so they choose H1 or H2. Someone wants a small label above a section, so they pick H6. The result is an outline that jumps around: three H1s on one page, H4s with no H3 above them, and card titles that are headings while the real section titles are plain text.
The fix is a habit, not a plugin. Elementor’s heading widget lets you pick the HTML tag separately from the size and style, so:
- Choose the tag for its place in the outline: one H1 for the page title, H2 for each main section, H3 for items inside a section.
- Set the visual size with the typography controls or your global fonts.
- For decorative labels or eyebrow text above a heading, use a paragraph or span tag, not H6.
Watch the other widgets too. Icon boxes, image boxes, call-to-action widgets and posts grids all output a title, and each has its own tag setting. On a services page with six icon boxes, those six titles all become headings in the outline. Our post on accessible heading structure explains how levels should nest.
Icon lists, icon boxes and social icons
Icons cause two opposite problems.
When an icon sits next to text, as in an icon list of “Free parking” or “Open Saturdays,” the icon is decorative. A screen reader should skip it. Usually this is fine, but some icon setups get announced as odd characters or “image.”
When an icon is the only content, as in social icons in the header or a phone icon that links to your number, it needs an accessible name. Without one, a screen reader says “link” with nothing after it. Open the screen reader’s links list and check that each social icon is announced with a name like “Facebook” or “Our Instagram page.” Custom SVG icons and icon-only buttons are the ones most likely to come through with no name at all.
Some versions of Elementor let you add custom attributes to an element, which can carry an aria-label for an icon-only link. Use that sparingly and only where visible text truly is not possible; a short visible label is usually better for everyone.
Buttons that are not really buttons
Elementor’s button widget outputs a link. That is right when it goes somewhere: “Book a table” linking to your booking page. Problems start when:
- The link is empty or “#”. Designers sometimes add a button as a placeholder and forget it. Keyboard users land on it and nothing happens.
- The text is vague. A row of three “Learn more” buttons gives a screen reader user three identical links. Make each one specific: “Learn about our dental implants.”
- A button opens a popup. It is still a link in the markup, so assistive technology expects it to go to a new page. Ideally the trigger should behave like a button and say it opens a dialog.
- Contrast is low. White text on a pale brand color, or a ghost button with a thin light border, often fails 1.4.3 or 1.4.11.
Popups built with Elementor
Elementor accessibility testing gets most interesting with popups, because that is where keyboard users tend to get stuck. When a popup opens, focus should move into it. While it is open, Tab should stay inside it. Escape should close it, and when it closes, focus should go back to where the user was.
Test every popup on your site this way, including newsletter signups, exit-intent offers and age gates. Common failures are a close button that is an icon with no name, a popup that opens but leaves focus on the page behind, and popups that appear on a timer and cover what someone was reading. We cover the full pattern in our guide to accessible popups and modal windows.
Carousels, sliders and testimonial rotators
Elementor’s carousel widgets are popular for logos, testimonials and hero images. Check each one for:
- Autoplay without a pause. Content that moves for more than five seconds must offer a pause or stop control under WCAG 2.2.2. The simplest fix is often to turn autoplay off.
- Arrows and dots without names. Previous and next arrows should be reachable by keyboard and named “Previous slide” and “Next slide.”
- Hidden slides still focusable. Keyboard users tab through links in slides they cannot see.
Often the right question is whether the carousel needs to exist at all. Our post on making sliders and carousels accessible helps with that decision.
Tabs, accordions, toggles and menus
Elementor’s tabs, accordion and toggle widgets have improved over time, but check them on your version. Can you reach each tab or toggle by keyboard? Does a screen reader say whether a section is expanded or collapsed? Is the content inside reachable once it opens?
For menus, test both the desktop dropdowns and the mobile toggle. The hamburger button should be reachable by Tab, say it is a button, report whether it is open, and let you reach every item in the panel that opens.
Forms built with the Elementor form widget
The most common form problem on Elementor sites is hidden labels. Designers turn labels off for a cleaner look and rely on placeholder text, which vanishes as soon as someone types and is often too pale to read. Keep labels visible. Then check that required fields are marked in text, that error messages say what is wrong, and that the success message is announced to screen readers, not only shown in green.
Elementor accessibility habits worth keeping
- Set global colors and fonts with contrast in mind. Check every text and background pair once, at the global level, before anyone builds pages.
- Build sections as saved templates. Fix a header, footer or card section once and it is fixed everywhere it is used.
- Keep text as text. Avoid putting important words inside images.
- Do not hide focus styles. If a custom CSS rule removes outlines, replace it with a visible style instead.
- Retest after Elementor updates. Widget markup changes between versions, sometimes for the better, sometimes not. Our post on editing an Elementor page without breaking it has general safe-editing habits that apply here too.
These habits sit inside the broader order of work in our guide to making a WordPress site accessible, where the page builder is treated as part of the theme layer.
Frequently asked questions
Is Elementor bad for accessibility?
Not in itself. Elementor can produce reasonably accessible pages, and its output has improved over the years. Most problems come from how pages are assembled: headings chosen by size, icon-only links without names, hidden form labels, autoplaying carousels and popups that do not manage focus. Good building habits fix most of them.
Do I need Elementor Pro for accessibility fixes?
No. Many of the most important fixes, such as correct heading tags, specific button text, color contrast and turning off autoplay, work in the free version. Pro adds widgets like popups and forms that bring their own things to test, and some extra controls that help with fine-tuning.
Should I switch from Elementor to the block editor for accessibility?
Switching is a big job and is not required. If a site has years of inconsistent Elementor pages and you were planning a rebuild anyway, it is worth weighing. Otherwise, fixing global settings, templates and the worst pages usually brings an Elementor site much closer to WCAG 2.2 AA with far less effort.
Are Elementor templates and kits accessible when imported?
Treat them as a starting point. Imported templates often use headings chosen for looks, vague button text such as “Learn more” and light text on photos. Fix your copy once, check it with the keyboard and a scanner, then save it as your own template so every new page starts from the corrected version.
If you would like help working through these on your own site, our Elementor and Divi accessibility fixes focus on builder output specifically, and our WordPress accessibility service covers the rest of the site. Both sit within our accessibility services for US businesses.
Next in this series: Divi Accessibility: Common Problems and How to Fix Them
