Elementor Accessibility: What Audits Find and How to Fix It

An Elementor site looks finished long before its markup is. Somebody dragged in a Heading widget, picked a size that looked right, linked a card, dropped in an icon for Instagram, and published. Every one of those choices writes HTML, and most of the accessibility failures on an Elementor site come from widget settings, not from code anybody typed.

That is good news if you have just inherited one, from a client, a former freelancer or your own past self. Most fixes are a setting in the panel, not a rebuild. The catch is where those settings live: the worst failures sit in Theme Builder templates, and fixing pages one at a time never reaches them. This guide covers where Elementor sites fail, the fix for each, and an order to work in.

Where Elementor sites fail

Run an automated scan on a typical Elementor page and the findings cluster in a few places:

• Headings chosen for their size, so the outline skips levels or has three H1s.
• Links with no name: icon widgets, social icons and image links with nothing a screen reader can read.
• Nested links inside cards, where the whole container is a link and the button inside it is another.
• Menus, tabs and accordions that work with a mouse and only partly with a keyboard.
• Contrast from global colors that were picked in a design file and never checked.

The first four are covered below. You can see which of them a page has in about a minute with a free accessibility scan, which is a good way to start before you open the editor.

Heading tag versus heading size

Elementor's Heading widget has two separate controls that people treat as one. The HTML Tag setting offers "H1 to H6, Div, Span, or Paragraph", and the font size lives in Typography (Elementor Heading widget docs). The tag is what a screen reader announces and what people navigate by. The size is only how it looks.

When an editor picks H2 because it is the right size for a footer tagline, or H5 for a card title because H3 looked too big, the outline stops describing the page. That fails 1.3.1 Info and Relationships: the visual structure says one thing and the markup says another.

<!-- Broken: tags chosen by size -->
<h2 class="elementor-heading-title">Trusted by local businesses</h2> <!-- a tagline, not a section -->
<h5 class="elementor-heading-title">Our services</h5>              <!-- the real section heading -->

<!-- Fixed: tags follow the outline, Typography handles the size -->
<p class="elementor-heading-title">Trusted by local businesses</p>
<h2 class="elementor-heading-title">Our services</h2>

The fix is in the widget panel: set HTML Tag to the level the content needs, then set the size in Typography so the design does not change. Text that should look like a heading but is not one (a tagline, a big number, a quote) gets Paragraph or Div. Each page needs one H1, usually the page title, and levels should step down in order.

Elementor's own Accessibility Assistant flags exactly these cases: a missing H1, more than one H1 and a heading that skips a level, with an option to "Keep the visual style but remove the semantic heading role" (Elementor help). Our headings and landmarks checker shows the outline of any page, and the guide to heading structure covers the rules in detail.

Icon-only buttons and nested links inside cards

Links and buttons with no name

An Icon widget or Social Icons widget with a link and no text produces a link that a screen reader announces as "link" and nothing else. The same happens with an image linked to a page when the image has no alt text. Both fail 2.4.4 Link Purpose (In Context) and 4.1.2 Name, Role, Value.

<!-- Broken: an icon link with no accessible name -->
<a class="elementor-icon" href="https://instagram.com/example">
  <svg aria-hidden="true">...</svg>
</a>

<!-- Fixed: the link says where it goes -->
<a class="elementor-icon" href="https://instagram.com/example"
   aria-label="Example Bakery on Instagram">
  <svg aria-hidden="true">...</svg>
</a>

You do not need code for this. Widgets with a Link field have a gear icon that opens Custom Attributes, which take a key|value format (Elementor custom link attributes). Enter aria-label|Example Bakery on Instagram and the attribute lands on the link. For linked images, write alt text in the media library that describes the destination. Our link text checker lists what a link name has to do to count.

The card that is a link with a link inside it

Elementor lets you make a whole container clickable: in Additional Options, set HTML Tag to "a (link)" (Elementor docs). It is the quickest way to build a clickable card, and it is where nested links come from. Elementor's own warning is plain: "When linking a container, the child elements within the container should NOT be linked themselves. Nesting <a> tags will cause issues."

The HTML standard does not allow an a element inside another a, or any interactive element such as a button inside a link (HTML standard, the a element). Browsers repair the invalid markup in different ways, so a screen reader may hear the whole card as one long link, and a keyboard user may tab to two stops that go to the same place.

<!-- Broken: a linked container with a linked button inside -->
<a class="e-con" href="/services/catering">
  <h3>Catering</h3>
  <p>Breakfast and lunch for offices of 10 to 200.</p>
  <a class="elementor-button" href="/services/catering">Read more</a>
</a>

<!-- Fixed: one link, named by the heading -->
<div class="e-con">
  <h3><a href="/services/catering">Catering</a></h3>
  <p>Breakfast and lunch for offices of 10 to 200.</p>
</div>

In Elementor, the fix is one of two things. Either link the container and remove the link from every child (the button can stay as a visual cue), or leave the container as a div and link the heading. The second is easier to understand with a screen reader, because the link name is the card title instead of every word in the card. Elementor's docs say version 3 of the editor will not stop you from nesting links, so check every card template, not only the ones built recently (Elementor nested links).

Menus, tabs and accordions

Interactive widgets are where a site can pass an automated scan and still fail a keyboard user, so these need a hand test. Unplug the mouse, press Tab from the top of the page, and check that every menu item, tab and accordion panel can be reached, opened and closed, with a visible focus ring the whole way (2.1.1 Keyboard, 2.4.7 Focus Visible). Our guide to testing keyboard accessibility by hand walks the full pass.

Menus

Elementor has improved its menus over several releases, so the version installed matters. Version 3.13 made the mobile menu toggle work with Enter and Space as well as a click (Elementor 3.13 notes). Version 3.16 gave the Menu widget a menubar role, menuitem roles, arrow key navigation and Escape to close, based on the ARIA Authoring Practices (Elementor 3.16 notes). Version 3.23 added a Menu Name control for labelling each menu (Elementor 3.23 notes). An inherited site that has not been updated in a while may have none of this.

Two checks after updating. First, a menubar role promises application-style behaviour: arrow keys between items, Enter or Space to open a submenu and Escape to close it. Test that all of it works, because the W3C's own navigation example notes that "Typical site navigation does not need all the keyboard interactions specified by the menu and menubar pattern" and uses simpler disclosure buttons instead (W3C disclosure navigation example). Second, when a page has more than one menu (header, footer, a sidebar), give each a distinct Menu Name so screen reader users can tell them apart. The navigation menus guide covers what good looks like.

Tabs and accordions

Tabs and accordions look alike and behave differently. An accordion header is a button that reports whether its panel is open (aria-expanded), and each one is a Tab stop (W3C accordion pattern). A tab list is one Tab stop, with arrow keys moving between tabs and the selected tab marked with aria-selected (W3C tabs pattern). Open the page with your browser's accessibility inspector and check that the Elementor widget exposes those states, then test the keys. If an FAQ was built from Toggle or Accordion widgets with headings inside the panels, check the heading levels there too. The guide to accordions and tabs has the markup for both.

What the accessibility widget does not fix

Many Elementor sites also run Elementor's own accessibility plugin, now listed on WordPress.org as Web Accessibility (formerly Ally). On 26 October 2026 it showed 500,000+ active installations and a rating of 2.9 out of 5 from 162 ratings (WordPress.org plugin page).

It does two different things, and it helps to keep them apart. The Accessibility Assistant scans pages and guides you through fixes, such as the heading fixes above, and those fixes change the page. The usability widget gives visitors a floating menu to resize text, change contrast and similar adjustments. That changes how the page looks for one visitor; it does not add a missing label, name an icon link or untangle a nested link.

The plugin is honest about this. Its description says it "is not a substitute for a thorough accessibility audit" and "is NOT intended to completely make your website legally compliant." The same is true of every automated tool, ours included: automated checks find many problems, but they cannot confirm a site conforms to WCAG. If a client believes the widget took care of accessibility, our piece on accessibility overlays explains the difference in plain terms.

A fix order for an inherited site

Work from the templates that appear everywhere down to individual pages, so each fix reaches as many pages as possible.

1. Update Elementor and the theme on a staging copy, so you are fixing the current widgets and not ones that have since changed.
2. Scan a sample of pages: the home page, one of each template type and the pages with forms. Save the results so you can show what changed.
3. Fix the Theme Builder header and footer. They appear on every page, so the menu, logo link and social icons fixed here are fixed site wide.
4. Fix global colors and typography in Site Settings, checking each text and background pair for contrast.
5. Fix single, archive and loop item templates: card links, heading levels in post titles, image alt text in featured images.
6. Fix pages one by one: heading tags, icon links, tabs and accordions, forms.
7. Test by hand with the keyboard and a screen reader, then rescan the same pages and compare.

Next steps

• Run a free scan on the home page and one inner page to see which of these failures the site has.
• Check the outline of each template with the headings and landmarks checker and every icon link with the link text checker.
• Search your card templates for linked containers with linked children.
• Keyboard test every menu, tab set and accordion after updating Elementor.
• For the rest of the WordPress stack (form plugins, theme CSS, media library), see WordPress accessibility issues and fixes.

When you explain this to a client or a manager, the short version is: most of it is settings, not a rebuild, and the templates come first because one fix there reaches every page.