Elementor 3.26 brings multiple exciting updates, focusing on modernizing browser support, enhancing website performance, and improving accessibility. This release focused on improving carousels, in terms of optimized DOM structure and accessible usage. It adds the ability to render Gutenberg Blocks inside Elementor while continuing to merge stable features, and laying the ground for future capabilities.
Updated Frontend Browser Support
In order to provide more consistent browser support, and allow us the opportunity to use more CSS properties and HTML attributes utilized by modern websites, Elementor 3.26 officially stops supporting older Safari versions. This allows us to expand support for up-to-date features.
Supported Browsers
Previous browsers support:
- Chrome 100 – released on March 29th, 2022.
- Firefox 100 – released on May 3, 2022.
- Safari 14 – released on September 16, 2020.
New browsers support:
- Chrome 100 – released on March 29th, 2022.
- Firefox 100 – released on May 3, 2022.
- Safari 15.5 – released on May 16, 2022. (new)
Adopting Industry Standards
Browser support is a sensitive issue for any website, which is why this change roughly aligns with the recommendations provided in the Google led Baseline initiative. This ensures support for widely adopted features that have been interoperable across all major browsers for over 30 months.
As Baseline doesn’t officially set which browser versions to support, Elementor adopted the general timeframe for its technological needs.
Since Elementor officially updated the supported browsers, which Safari versions does Elementor support? Safari 15.5+, Safari 16, Safari 17, and Safari 18; browsers released in the last 30 months, give or take.
New Capabilities
The new browser support allows Elementor to support modern capabilities. To name a few:
- CSS
insetproperty (Safari 14.1) - CSS
aspect-ratioproperty (Safari 15) - CSS
float: inline-start;&float: inline-end;properties (Safari 15) - CSS
:has()pseudo-class (Safari 15.4) - CSS
@layerat-rules (Safari 15.4) - HTML
loadingattribute on img/iframe tags (Safari 15.4) - HTML
dialogtag (Safari 15.4) - HTML
inertattribute (Safari 15.5)
This change opens the door for exciting new interoperable features that couldn’t previously be implemented by Elementor.
Performance Improvements
Elementor continues improving various mechanisms to make websites faster. Version 3.26 focuses on reducing the DOM size and further reducing unused CSS. Here are the main changes, starting from the simple ones and moving to the advanced ones that have a more significant impact on websites:
Swiper Styles Optimization
Swiper is a JS-based library used by Elementor to create a slider / carousel. The problem is that because of legacy issues, Elementor loaded the swiper.min.css file on all pages, whether or not they had carousels. This increased the “Unused CSS” on Elementor pages. Elementor 3.26 finally fixes this.
Previously, swiper styles were loaded everywhere to make them available for different carousel widgets. As of 3.24, widgets need to declare which styles they are using, with the get_style_depends() method. Therefore, Elementor no longer needs to load swiper styles on all the pages, these styles are loaded conditionally only if one of the widgets is using swiper.
Pages without sliders or carousels will see a reduction of 26.7 kb, due to not loading two files: the library styles in swiper.min.css (16.4 kb) and the Elementor style customizations file e-swiper.min.css (10.2 kb).
Optimizing DOM Size for Accessible Labels
Elementor 3.26 reduces the DOM size by replacing hidden HTML elements used for screen-readers and assistive-technologies. Instead of using an HTML element with an .elementor-screen-only class to add descriptive text for screen-readers, version 3.26 uses the aria-label attributes on the parent element.
Previously used screen-reader text:
<button type="button">
<i class="eicon-plus" aria-hidden="true"></i>
<span class="elementor-screen-only">MY TEXT</span>
</button>Is replaced with this code:
<button type="button" aria-label="MY TEXT">
<i class="eicon-plus" aria-hidden="true"></i>
</button>Instead of 3 HTML elements, Elementor now uses 2 HTML elements; the same result with less DOM elements. This change affects multiple Elementor widgets that offer additional information for assistive-technologies. For instance, close buttons for modals or navigation arrows for carousels.
Optimizing DOM Size for Carousel Widgets
Elementor 3.26 extends the “Optimized Markup” experiment with an additional improvement. While the previous 3.25 version focused on optimizing button-related widgets, this version focuses on carousel-related widgets.
When activating the experiment, four carousel-related Pro widgets will have less wrapping <div> elements, removing the unused .elementor-swiper wrappers. Again, the same functionality, with less HTML.
Optimizing DOM for All Widgets
Until now, DOM optimization focused on individual widgets, fixing them one-by-one, which was not scalable. We wanted to improve areas that affect all widgets in all Elementor pages. That is why Elementor 3.26 extends the “Optimized Markup” experiment with an additional capability affecting all widgets on all pages.
Currently, when you drag any widget to the page, Elementor wraps the widget with two <div> elements and renders the widget markup inside. However, when the “Optimized Markup” experiment is enabled, Elementor will wrap each widget with only one <div> element.
Each Elementor widget has its own markup, but the wrapping elements are required as they are used for different features like backgrounds, motion effects, layout, etc. To reduce the DOM size, the inner .elementor-widget-container element was removed, while making these features work with only one widget wrapper.
Regular markup:
<div class="elementor-widget elementor-widget-{name}">
<div class="elementor-widget-container">
…
</div>
</div>Optimized markup:
<div class="elementor-widget elementor-widget-{name}">
…
</div>When the experiment is active, it completely removes the inner .elementor-widget-container element from all widgets except 6 (Spacer, Menu, Loop, TOC, Form, Hotspot). The number of removed HTML elements on each page depends on the number of widgets the page has. The more widgets a page uses, the higher the impact.
Please note that the “Optimized Markup” experiment is in an alpha stage experiment. It is considered an early stage feature that may require additional development and issue resolution. This experimental feature should not be used on production websites. Currently, not all third-party addons fully support this new feature. Future versions will further stabilize this feature.
Accessibility Improvements
Elementor 3.26 focuses on improving carousel accessibility. As of this version, it’s possible to set semantic names for carousels, the code has consistent ARIA attributes across all the carousel widgets, keyboard navigation becomes much easier, and more.
Naming Carousels
Elementor 3.23 and 3.24 added the ability to set the names for “WordPress Menu”, “Menu”, and “Off-Canvas” widgets. Elementor 3.26 adds the same ability for sliders and carousels. Now, all carousels can have custom names.
This improvement adds a new “Name” control to carousel widgets – “Image Carousel”, “Media Carousel”, “Testimonial Carousel”, “Reviews”, and “Slides”.
The text set in the new “Name” control is used in the aria-label attributes to provide assistive-technologies information describing the carousel content. It adds the ability to choose semantic labels for carousels. For instance, the reviews carousels can be named “XXX product reviews”, and the testimonial carousels labeled “Happy customer feedback”.
This is also very handy on pages that have two carousels of the same type, for example, two testimonial carousels. Now, you will be able to set different labels for each; the first for product testimonials and the other for service testimonials.
Carousels ARIA Attributes
This release enhances consistency across all Elementor carousels by adding missing attributes such as role, aria-roledescription, and aria-label, ensuring uniformity across all carousels and sliders. Previously, not all carousel widgets included these attributes.
At the element level, the role="region" attribute designates the carousel as a landmark element, while aria-roledescription="carousel" informs assistive technologies that it’s a carousel, not just a region. The aria-label provides a unique label for the carousel element.
For the slides, consistent attributes like role="group" and aria-roledescription="slide" have been implemented. Additionally, pagination bullets for “Nested Carousels” now have accessible aria-label attributes, bringing them in line with the accessibility standards of other widgets.
Notes For Accessible Carousels
What should you do to improve your website accessibility? For starters, add intuitive and descriptive names to all the carousels on your website.
Does it mean the carousels on my website are fully accessible? Well, it depends. For the majority of use cases, Elementor carousels are accessible. However, some key features are not yet available. For instance, carousels with “Autoplay” mode on are still missing the “Pause” button. This feature, and some others, are in Elementor’s 2025 accessibility roadmap.
We are constantly investigating additional improvements which can improve the usability for your users using assistive technologies. Many of the improvements have been fixed due to community requests. So, thank you for all your feedback. You are awesome!
Editor Accessibility
This release enhances the “Add New” presets at the bottom of the preview area in the Elementor Editor, making them fully keyboard accessible. You can now easily add new sections, containers, or templates by pressing the TAB key to navigate to the relevant preset.
Experiments and Features
In this release, Elementor continues to improve and merge additional features and experiments, focusing on performance-related features.
Merged Features
The “Optimized Control Loading” feature was introduced in 3.21, to improve the Controls Rendering Engine. This feature reached maturity and was merged into the plugin in Elementor 3.26.
By optimizing the way Elementor controls are loaded on the server, and conditionally removing controls that are not required in the frontend, Elementor managed to improve the Time To First Byte (TTFB) on the frontend. Now, this feature is available for all websites.
In addition, the “Upgrade Swiper Library” feature, introduced in 3.11, was also merged to Core. Elementor no longer loads the old Swiper 5 files, fully migrating Elementor widgets to Swiper 8.
Since the early days of Elementor, it has used both Slick.js and Swiper.js for creating sliders and carousels. With Elementor 2.7, Slick.js was replaced with Swiper.js, adopting a single solution across all widgets. Then, Elementor 3.11 introduced the ability to upgrade from Swiper 5 to Swiper 8. Now, Elementor 3.26 is finally retiring Swiper 5, and adopting a single and consistent version for all Elementor widgets.
Unfortunately, the long, two year migration period was needed, to help external addon developers migrate seamlessly to the new version. However, now with the new Swiper version, Elementor will be able to introduce new features and customization options that previously were not available.
New Stable Feature
The “Nested Elements” feature is a mature feature that had its status upgraded from beta to stable. This neat feature activated the “Nested Tabs”, “Nested Accordion”, “Nested Carousels” and others widgets.
While the old Section / Column structure is a strict structure that has 3 levels (Section / Column / Widget), the new Containers structure allows endless container nesting, one inside the other. Furthermore, widgets with nested capabilities can nest other widgets within.
Upgraded Features
The “Element Caching” feature is now active by default, not only on new websites, but also on existing websites. When active, this performance feature reduces server memory usage by 99%. The result is less server computation time and a much faster Time To First Bite (TTFB) on the frontend of Elementor websites.
Introduced in Elementor 3.22, the “Element Caching” feature caches the HTML output for each widget on the page separately. And on the next visit, it no longer renders each widget, loading the cached output instead. The mechanism is smart enough to cache only static widgets, excluding widgets with dynamic content.
Gutenberg Blocks Support Inside Elementor
We are thrilled to announce that this release adds support for Gutenberg Blocks inside the Elementor Editor. This improved capability will impact many use cases; for example, here’s how WooCommerce users will benefit from this new Blocks support in Elementor.
WooCommerce Transition to Blocks
eCommerce websites using Elementor to style their pages faced challenges when trying to edit their auto-generated WooCommerce pages (Cart, Checkout, etc.) as these are comprised of Gutenberg Blocks. The Blocks were inaccessible inside the Elementor Editor, and these pages broke in the frontend. This wasn’t always the case.
In the past, WooCommerce used WordPress Shortcodes to render content on its auto-generated pages. Shortcodes are fully supported by Elementor. Users could also add additional Elementor Widgets to the page, or even delete the internal WooCommerce Shortcodes and replace them with Elementor Widgets. They had full control over the page.
However, when WooCommerce transitioned to using Gutenberg Blocks, these auto-generated pages could not be edited in Elementor, as the Editor did not support block rendering. This led to significant usability issues, and the only way users could continue editing the page using Elementor was to remove the Blocks entirely.
Blocks Support Inside Elementor
As of Elementor 3.26 this workaround is no longer necessary as Gutenberg Blocks will render properly in the Elementor Editor and on the frontend.
It’s now also possible to add new Elementor Widgets alongside WordPress Shortcodes and Gutenberg Blocks, so you no longer have to choose between Gutenberg or Elementor: you can use both of them.
Note that although Gutenberg Blocks are now visible inside the Elementor Editor, they cannot be edited there.
Developer Advisory
Developers who develop Elementor Addons are advised to make the following adjustments in code to implement the latest standards and ensure a smooth experience for our shared users.
Deprecated Widget Class
Addon developers should make sure their Elementor widgets don’t use the deprecated .elementor-widget-container class, as this selector is not available on websites that enable the “Optimized Markup” experiment.
If your widgets rely on this class, in the widget selectors or in your general styles, you should seek alternative selectors to style your widget. The same applies for JS functionality. If the query selector targets this CSS class, please update the code, as this CSS class will not be present when the experiment is active, and will be completely removed in the future.
For instance, a widget selector which should be updated:
$this->add_control(
'text_align',
[
'label' => esc_html__( 'Alignment', 'textdomain' ),
'type' => \Elementor\Controls_Manager::CHOOSE,
'options' => [
'left' => [
'title' => esc_html__( 'Left', 'textdomain' ),
'icon' => 'eicon-text-align-left',
],
'center' => [
'title' => esc_html__( 'Center', 'textdomain' ),
'icon' => 'eicon-text-align-center',
],
'right' => [
'title' => esc_html__( 'Right', 'textdomain' ),
'icon' => 'eicon-text-align-right',
],
],
'default' => 'center',
'toggle' => true,
'selectors' => [
'{{WRAPPER}} .elementor-widget-container' => 'text-align: {{VALUE}};',
],
]
);In this case, the CSS selector should be updated to:
'selectors' => [
'{{WRAPPER}}' => 'text-align: {{VALUE}};',
],This is true not only for widgets developers. Many Elementor addons add new capabilities to the widget’s Advanced tab, to add features for all widgets. If you develop these types of capabilities, you need to support the new Optimized DOM. Make sure your CSS selectors and JS queries support widgets that have 2 wrapping elements and optimized widgets that have a single wrapping element.
Add Support for Optimized DOM
As mentioned above, when the “Optimized Markup” experiment is active, Elementor reduces the DOM size with multiple optimizations. Currently, each widget is wrapped with two <div> elements, but with the experiment active, each widget will have only one wrapping <div> element.
Current markup:
<div class="elementor-widget elementor-widget-{widget-name}">
<div class="elementor-widget-container">
…
</div>
</div>Optimized markup:
<div class="elementor-widget elementor-widget-{widget-name}">
…
</div>Addon developers that rely on these outer <div> elements should test their widgets with the experiment active and inactive. In addition, each widget should use the has_widget_inner_wrapper() method, declaring that it either supports optimized markup, or not.
If your widget requires both <div> wrappers, no matter if the experiment is active or not, add the following method to the widget:
public function has_widget_inner_wrapper(): bool {
return true;
}If your widget can work with only the outer <div> wrapper, without the inner .elementor-widget-container wrapper, to produce a smaller DOM fingerprint, add the following method to the widget:
public function has_widget_inner_wrapper(): bool {
return false;
}If you prefer, the markup optimization can be based on the website preference:
public function has_widget_inner_wrapper(): bool {
return ! Plugin::$instance->experiments->is_feature_active( 'e_optimized_markup' );
}For backwards compatibility reasons, widgets that don’t use the has_widget_inner_wrapper() method, will behave like unoptimized widgets, with 2 wrapping <div> elements. This is true whether the experiment is active or not.
Scheme Deletion
Elementor 3.26 finally deleted Schemes from the code base. This limited mechanism was replaced by the robust Globals mechanism in Elementor 3.0, which allows users to define limitless colors and typographies.
There were several attempts to delete Schemes over the years, however, at the request of our partners, Schemes deletion was postponed several times, to make sure websites wouldn’t break. We helped dozens of addon developers update their code, transitioning to Globals, and the majority managed to migrate from Elementor Schemes to Globals, focusing on wp.org hosted plugins.
This change is considered very risky, especially for websites that use Elementor addons not hosted in the official plugin repository. Before upgrading, backup the website and make sure all installed Elementor Addons transitioned to Globals.
Migration to Swiper 8
Elementor 3.26 finishes the long two years migration process from Swiper 5 to Swiper 8. Elementor addon developers should make sure their carousel based widgets work with the new Swiper.
Search for the following classes:
.swiper-container.swiper-container-horizontal
Replace them with:
.swiper.swiper-horizontal
Test your widget’s functionality to make sure there are no regressions.
Alternatively, to continue using Swiper 5, add the library files to your addon files, register them, and declare them as standard widgets dependencies.
To Conclude
Elementor 3.26 brings modern browser support, performance optimizations, and improved accessibility, empowering web creators to build more efficient and user-friendly websites. From DOM size reductions to seamless Gutenberg Block integration, this update simplifies workflows and enhances functionality.
