The 2026 Elementor Pro Accessibility MOT: A Widget-by-Widget Checklist for UK Builders
Accessibility audits have a reputation for being either a box-ticking exercise or a full rebuild. In the UK, neither is helpful. If you maintain Elementor Pro sites for clients, you need to know which widgets are likely to fail WCAG 2.2 AA and what you can fix this week without throwing away the layout.
This checklist is the MOT I run on existing builds. It is not legal advice, and it does not replace a proper audit, but it will catch the Elementor-specific problems that come up again and again. The Equality Act 2010 sets the expectation that services are accessible; WCAG 2.2 AA is the practical benchmark most UK clients ask for.
Before you touch a widget
Test the site with a keyboard only. Put the mouse away. Tab through the homepage, a form page and a popup. Can you see where focus is? Can you reach every link and button? Can you get out of a menu or modal? Then zoom to 200% and 400%. Finally, run a screen reader spot check with NVDA on Windows or VoiceOver on Mac. Browser extensions such as axe DevTools and WAVE will catch structural issues quickly.
Fix the global stuff first: focus outlines, link colours and heading order. Elementor's Global Settings can handle a lot of that without editing every widget.
Forms widget
What to test: Tab through every field. Check that each field has a visible label, not just a placeholder. Submit the form with errors and listen for the error message. Can you tell which field failed and why?
Common Elementor failures: Placeholder-only labels, required fields marked only with an asterisk, error messages that appear visually but are not announced, and multi-step forms that do not move focus to the next step.
Fixes: Turn on field labels in the Form widget and keep placeholders as hints. Add 'required' text, not just an asterisk. Use the form's custom messages to make errors specific. For multi-step forms, add a small script to move focus to the first field or the step heading. If you use reCAPTCHA, test it with a screen reader; if it fails, switch to a honeypot or a more accessible challenge.
Tabs widget
What to test: Use the arrow keys to move between tabs. Does focus follow? Does the content change? Can you tab into hidden tab panels?
Common failures: Missing tab roles, no keyboard arrow support, and hidden panels that remain focusable. Elementor's Tabs widget is visually tidy but sometimes needs help with ARIA.
Fixes: Add role='tablist', role='tab' and role='tabpanel' with a small child-theme script if the widget does not expose them. Add left/right arrow key handling. If that feels like too much, replace the tabs with an Accordion widget, which is usually easier to make keyboard-friendly.
Carousel and Slides widgets
What to test: Stop the carousel with the keyboard. Can you pause autoplay? Are the previous and next buttons labelled? Can you reach slides that are off-screen? Does it respect reduced motion?
Common failures: Autoplay with no pause, icon-only controls with no accessible name, hidden slides still in the tab order, and no announcement when the slide changes.
Fixes: Turn off autoplay unless the client insists. Add accessible labels to the controls in the widget settings or with aria-label. Use CSS to hide inactive slides from assistive tech and remove them from the tab order. Add a prefers-reduced-motion rule to stop animation for users who ask for it.
Popups
What to test: Open the popup with the keyboard. Can you close it with Escape? Does focus stay inside the popup while it is open? When it closes, does focus return to the button that opened it?
Common failures: Popups that open automatically on page load, close buttons with no label, focus escaping to the page behind, and no aria-modal or dialog role.
Fixes: Avoid auto-opening popups on page load; use a click trigger instead. Give the close button a text label or aria-label='Close'. Add a focus trap and return-focus script. Mark the popup container as a dialog with aria-modal='true'. If the popup contains a form, test it like a form page.
Navigation and Menu widgets
What to test: Tab through the main menu. Can you open submenus with the keyboard? Does the mobile toggle announce whether it is open or closed? Is there a skip link?
Common failures: Dropdowns that only work on hover, mobile toggles with no accessible name, and no aria-expanded state. Elementor Pro's Menu widget is better than it used to be, but custom CSS can undo the good work.
Fixes: Add a skip link via an HTML widget at the top of the page. Give the mobile toggle an aria-label and make sure aria-expanded changes. Add visible focus styles for menu links. If the dropdown is hover-only, add a click or focus trigger.
Quick wins beyond the big five
Check image alt text, heading levels, link text, colour contrast and video captions. Use real link text rather than 'click here'. Make sure headings run in order. Check that any embedded maps or third-party widgets have an accessible alternative.
How to sequence the fixes
Start with the issues that block a task: forms, navigation, popups and carousels. Then fix structure: headings, landmarks, skip links. Then polish: contrast, focus styles, motion. Document what you tested and keep the notes with the site. That record is useful when a client asks what 'accessible' means for their site.
The point is not to rebuild in Elementor. Most of these fixes are settings, a little CSS and a few lines of JavaScript in a child theme. An MOT approach keeps the site familiar and makes the improvements manageable.
