WPBakery Accessibility Checklist 2026 | WCAG 2.1 AA & EAA Compliance
Last updated: 2026-07-22
WPBakery Page Builder, still widely known by its former name Visual Composer, ships bundled with thousands of commercial WordPress themes and powers a very large share of older business sites, agency builds, and ThemeForest templates. Because it is bundled rather than chosen, most site owners inherit it without ever evaluating how it builds pages, and that matters for accessibility: WPBakery works by wrapping your content in shortcodes that expand into deeply nested rows, columns, and wrapper divs at render time. What you see in the back-end editor is a grid of blocks, not the markup a screen reader actually receives, so structural problems stay invisible until someone tests the live page. The most common failures follow directly from that model. Heading levels are chosen per text block for visual size, so a page can jump from an H1 straight to an H4 or repeat several H1s across sections, leaving screen reader users without a usable outline. Interactive elements bundled with the builder and its add-on packs, especially tab groups, accordion toggles, image carousels, and icon-only buttons, are frequently rendered as generic containers with click handlers, no keyboard support, and no accessible name. Layout columns are ordered visually in the editor, but on mobile they stack in source order, which can leave the reading and tab order out of sync with what users see. Because WPBakery sites are often commercial storefronts, booking pages, and service businesses serving EU customers, they fall within the scope of the European Accessibility Act, and the ADA continues to drive demand letters against similar sites in the US. This checklist covers the accessibility issues most likely to appear in a WPBakery build and how to fix them from the element settings, theme options, and a small amount of custom CSS.
Common Accessibility Issues
Every WPBakery text block, custom heading element, and section title lets you pick a heading tag independently, and editors almost always pick the one that looks right rather than the one that fits the document outline. Real pages end up with multiple H1s, sections that skip from H2 to H5, and decorative taglines marked up as headings, which destroys the outline screen reader users navigate by.
Give each page exactly one H1 that matches its main topic, then use H2 for each major section and H3 for subsections in unbroken order without skipping levels. In the Custom Heading element set the element tag by meaning and control the visual size with the font size or a CSS class instead. Audit the finished page's heading list with a screen reader or a headings extension rather than trusting the editor layout.
The bundled tab, tour, and accordion elements commonly render their triggers as anchor tags with empty href values or as plain div and heading elements with a click handler. Keyboard users cannot reach or activate them, and screen readers do not announce whether a panel is expanded or which tab is selected, so the content inside is effectively hidden.
Verify the rendered triggers are real buttons that receive keyboard focus and respond to Enter and Space, and that each one exposes an expanded or selected state tied to the panel it controls. Where the bundled element cannot do this, replace it with an accessible pattern that follows the WAI-ARIA Authoring Practices for tabs and disclosures, and confirm arrow key behavior and focus visibility on the live page.
WPBakery ships image carousels, post sliders, and Revolution Slider integrations that auto-rotate by default. Users who read slowly, use magnification, or have cognitive disabilities cannot finish a slide before it changes, and the prev, next, and dot controls are often unlabeled icons that keyboard users cannot reach or identify.
Turn autoplay off, or provide a clearly labeled pause control that stops motion and stays available. Give every carousel control a text accessible name such as 'Previous slide' and 'Next slide', make the slide dots keyboard reachable with an indication of the current slide, and ensure off-screen slides are not focusable while hidden. Consider replacing a hero carousel with a single static image, which almost always performs better anyway.
Icon element, button, and social sharing widgets render font icons or SVGs with no text, so screen readers announce them as 'link' or read the raw class name. A row of header and footer social icons or a set of icon-only call, cart, and search buttons becomes a set of unlabeled destinations with no way to tell them apart.
Give every icon-only control a text alternative through the element's title or label field, or add visually hidden text inside the link. Name the destination or action, such as 'Call our Austin office' or 'A11yFix on Instagram', rather than 'Click here'. Confirm the icon font itself is not the only carrier of meaning, since custom icon fonts can fail to load and leave nothing behind.
Rows built from multiple columns place an image on one side and text on the other. Because columns stack in source order on small screens, a layout that visually reads text-then-image on desktop can read image-then-text on mobile, and CSS ordering tricks used to fix the visual result leave the tab and screen reader order out of sync with the visible order.
Build rows so the source order already matches the intended reading order and let the stack fall naturally, rather than reversing columns with CSS ordering. Tab through each page at mobile and desktop widths and confirm focus moves in the same order the eye follows. Where a visual swap is essential, restructure the row instead of reordering it in styling.
WPBakery elements each carry their own color settings layered on top of theme defaults, so light gray body copy, white text over image backgrounds, and pale ghost buttons appear throughout a site with no central place to catch them. Section overlays and parallax backgrounds are especially prone to failing contrast where the underlying image is bright.
Check body text against its actual background for at least 4.5 to 1 contrast, and large headings and interactive borders for at least 3 to 1. Add a solid or sufficiently dark overlay behind text placed on images, and set contrast-safe defaults once in the theme so individual elements inherit them instead of each being styled by hand.
WPBakery Page Builder-Specific Tips
- Always audit the rendered front-end page rather than the back-end block editor, because WPBakery shortcodes only expand into real markup at render time.
- Set heading tags by document meaning in the Custom Heading element and control the visual size with font size settings, never the other way around.
- Treat bundled add-on packs such as slider and mega-menu plugins as separate accessibility risks, since they ship their own markup that the theme author does not control.
- Disable carousel and slider autoplay across the site as a default, then add motion back only where a labeled pause control exists.
- Tab through every template you use once, since most WPBakery sites reuse a handful of row layouts and fixing them at the template level fixes hundreds of pages.
Recommended Tools
WAVE Browser Extension
Runs against the rendered WPBakery page and visually flags skipped heading levels, unlabeled icon links, and contrast failures directly on top of the layout, which makes shortcode-generated structure problems easy to spot.
axe DevTools
A browser extension that runs automated WCAG checks on the published page, catching missing accessible names on tab and accordion triggers, empty links, and ARIA state problems introduced by bundled elements.
NVDA
A free Windows screen reader for confirming how WPBakery tabs, accordions, and carousels are actually announced, which is the only reliable way to verify expanded and selected states on bundled elements.
Frequently Asked Questions
Is WPBakery Page Builder accessible out of the box?
Not reliably. WPBakery renders your layout through shortcodes, and the accessibility of the result depends on the builder version, the theme that bundles it, and any add-on element packs installed alongside it. The bundled tab, accordion, and carousel elements have historically produced triggers without keyboard support or state information, and the builder does nothing to enforce a sensible heading order. You can build an accessible WPBakery site, but it takes deliberate work: correct heading tags, accessible names on icon controls, autoplay turned off, and real testing on the published page rather than in the editor.
Should I migrate off WPBakery to fix accessibility?
Not as a first step. Migrating a large WPBakery site to another builder or the block editor is a full rebuild that introduces its own regressions, and most of the highest-impact fixes here are configuration changes you can make in place: correct the heading tags, label the icon buttons, disable carousel autoplay, and fix contrast in the theme settings. Migration makes sense when you are already replanning the site or when a bundled interactive element genuinely cannot be made keyboard accessible. Fix the live site first, then decide about the platform separately.
Further Reading
- Wordpress Accessibility Guide
- Accessible Tabs Tabbed Content Guide
- Image Carousel Accessibility Lawsuits
Other CMS Checklists
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.