Beaver Builder is one of the longest-running WordPress page builders, popular with freelancers and agencies because it produces noticeably cleaner front-end markup than many competitors and rarely locks you in - disable the plugin and your content survives as readable HTML. That reputation for clean code leads a lot of people to assume Beaver Builder sites are accessible by default, but clean markup and accessible markup are not the same thing. Beaver Builder gives you a heading-tag dropdown on most modules, so editors still pick H1 through H6 by visual size and break the document outline. Its Tabs and Accordion modules, its Content Slider and Slideshow, its Contact Form and Subscribe modules, and its Callout and Photo modules each carry the same recurring accessibility gaps you find in every visual builder: tab and accordion widgets that miss the full ARIA and keyboard pattern, sliders that autoplay without a usable pause control, forms that lean on placeholder text instead of real labels, and images published with empty alt text because the field is optional. On top of that, Beaver Builder themes and the Beaver Builder Theme let you place text and buttons over row background colors, gradients, and photos, where contrast quietly drops below the 4.5:1 and 3:1 minimums. The European Accessibility Act is now in force for businesses serving EU consumers, and ADA Title III claims continue to name small-business WordPress sites in the US, so Beaver Builder users should treat accessibility as part of the build, not a final-step scan. This checklist covers the issues we see most often on Beaver Builder sites and the specific module settings and markup targets that fix each one. None of this is legal advice; consult a qualified attorney for your jurisdiction.

Common Accessibility Issues

critical

Module Heading Tags Chosen by Size, Breaking the Document Outline

WCAG 1.3.1

Most Beaver Builder modules that show a title (Heading, Callout, Pricing Table, Call to Action, and others) include an 'HTML Tag' or heading-level dropdown (H1-H6, sometimes div/span). Editors pick the tag that gives the right font size, so pages end up with multiple H1s, skipped levels, and section titles at the wrong depth. Screen reader users who navigate by headings get an outline that does not match the visual structure of the page.

How to fix:

Plan one H1 per page (usually the page title or hero Heading module) and a logical H2/H3/H4 nesting with no skipped levels. In each module's settings, set the HTML Tag to match the outline and control size separately with the typography font-size setting. Audit any saved template or imported layout immediately, they frequently duplicate the H1 or set every section title to H2.

Before
<!-- Heading module tag chosen for size -->
<h1 class="fl-heading">Grow Your Studio</h1>  <!-- second H1 -->
<h4 class="fl-heading">What We Offer</h4>       <!-- should be H2 -->
After
<h1 class="fl-heading">Northgate Studio</h1>
<h2 class="fl-heading">What We Offer</h2>
<h3 class="fl-heading">Brand Design</h3>
serious

Tabs and Accordion Modules Miss the Full ARIA and Keyboard Pattern

WCAG 4.1.2

Beaver Builder's Tabs and Accordion modules render interactive widgets that do not always expose the expanded/collapsed state or implement the complete keyboard pattern. Accordion headers may not announce as expandable controls or report whether a section is open; tabs may not support Left/Right arrow navigation or announce the selected tab. Keyboard and screen reader users cannot reliably operate the content.

How to fix:

For accordions, ensure each header is a real button exposing aria-expanded="true"/"false" and aria-controls pointing at its panel, with the panel as a labelled region. For tabs, apply the tablist pattern: role="tablist", each tab a button with role="tab", aria-selected and aria-controls, each panel role="tabpanel" with aria-labelledby, and Left/Right/Home/End key handling. If the module markup does not provide this, add the ARIA via a small HTML/JavaScript module or theme code. Test that Enter and Space operate the controls and that state changes are announced.

Before
<!-- Accordion header without role/state -->
<div class="fl-accordion-button">Do you offer refunds?</div>
After
<button class="fl-accordion-button" aria-expanded="false" aria-controls="acc-1">
  Do you offer refunds?
</button>
<div id="acc-1" role="region">...</div>
critical

Content Slider and Slideshow Modules Autoplay Without a Pause Control

WCAG 2.2.2

The Content Slider and Slideshow modules can auto-advance on a configurable interval with no built-in pause/stop control surfaced to keyboard and screen reader users. Auto-moving content that runs longer than five seconds must be pausable under WCAG 2.2.2, and motion that a user cannot stop is a barrier for people with cognitive, attention-related, and vestibular conditions who cannot finish a slide before it changes.

How to fix:

The simplest fix is to turn auto-play off in the module's settings - a static hero or a manually advanced slider is almost always better. If auto-play is required, add a visible, keyboard-operable Pause/Play button with an accessible name and aria-pressed state, enable pause-on-hover and pause-on-focus, and make sure the previous/next arrows and any dots are reachable by Tab, operable with Enter/Space, and have accessible names.

Before
<!-- Content Slider auto-playing, no pause control -->
<div class="fl-slideshow" data-autoplay="true" data-speed="4000"> ... </div>
After
<!-- Auto-play off, or add a pause button: -->
<div class="fl-slideshow"> ... </div>
<button type="button" aria-pressed="false" aria-label="Pause slideshow">Pause</button>
serious

Contact Form and Subscribe Modules Use Placeholder Labels and Unassociated Errors

WCAG 3.3.2

The built-in Contact Form and Subscribe modules can render field names as placeholder text inside the input rather than as persistent, programmatically associated labels. Placeholder text disappears on typing, is announced inconsistently by screen readers, and is usually low-contrast gray. Validation errors are often shown as a single general message instead of being tied to the field with aria-describedby, and focus is not moved to the first error.

How to fix:

Give every field a real, persistent label associated via for/id, and enable visible labels in the module settings rather than relying on placeholders. Indicate required fields in text, not color alone. Associate each error message with its field via aria-describedby, set aria-invalid on failed fields, and move focus to the first invalid field on a failed submit. For complex forms, consider an accessible form plugin instead of the basic module.

Before
<!-- Field name as placeholder only -->
<input type="email" name="fl-subscribe-email" placeholder="Email">
After
<label for="sub-email">Email <abbr title="required">*</abbr></label>
<input type="email" id="sub-email" name="fl-subscribe-email"
       required aria-required="true" aria-describedby="sub-email-error">
<span id="sub-email-error" role="alert"></span>
critical

Text and Buttons Over Row Backgrounds Fall Below Contrast Minimums

WCAG 1.4.3

Beaver Builder lets you set row and column background colors, gradients, and photos and place text and buttons on top. Because you preview against the design's own background, light-gray body text, pale button fills, and link colors that fall below 4.5:1 for normal text (3:1 for large text and UI components) are easy to miss - especially text laid over a busy photo, where contrast varies across the image.

How to fix:

Check body text, button text on button fill, and link colors with a contrast checker, then correct them in the module typography settings and the Beaver Builder Theme Customizer global colors. For text over photos, add a solid or semi-opaque overlay so contrast holds across the whole image, or move the text off the image. Re-check hover and focus states and any text on gradient overlays.

Before
/* Light button text on a pale fill */
.fl-button { color: #c4c4c4; background: #eaeaea; } /* ~1.3:1 - fails */
After
/* Corrected to meet 4.5:1 */
.fl-button { color: #ffffff; background: #1d4ed8; } /* ~7:1 - passes */
serious

Photo, Gallery, and Callout Images Published Without Alt Text

WCAG 1.1.1

The Photo, Gallery, Callout, and Slideshow modules pull images from the WordPress Media Library, where the alt-text field is optional and frequently left blank. Informative images then reach screen reader users as nothing, or as a filename. Conversely, decorative images and icons are sometimes exposed to assistive technology, adding noise to the page.

How to fix:

Fill in alt text in the Media Library or the module's image settings for every image that conveys information, describing what the image communicates rather than how it looks. For Gallery and Slideshow modules, set alt text on each image. Leave the alt empty (not missing) only for genuinely decorative images, and ensure decorative icons used next to headings are hidden from assistive technology.

Before
<!-- Photo module image with no alt -->
<img src="/wp-content/uploads/team.jpg" alt="">
After
<img src="/wp-content/uploads/team.jpg"
     alt="Northgate's four-person team in their downtown studio">
moderate

Module Animations and Reveal Effects Ignore Reduced-Motion Preferences

WCAG 2.3.3

Beaver Builder modules and rows offer entrance animations (fade, slide, scale) and reveal-on-scroll effects that run for everyone regardless of the operating-system reduce-motion setting. Large or repeated positional motion can cause nausea and dizziness for people with vestibular disorders.

How to fix:

Add a prefers-reduced-motion media query in the Beaver Builder Theme Customizer Custom CSS (or your child theme) that disables entrance animations, transforms, and transitions when reduced motion is requested. Keep any remaining motion subtle and opacity-based rather than large positional movement.

Before
/* Entrance animation applied to all visitors */
.fl-animation { transform: translateY(60px); transition: transform .6s; }
After
@media (prefers-reduced-motion: reduce) {
  .fl-animation, [class*="fl-animated"] {
    transform: none !important;
    animation: none !important;
    transition: none !important;
  }
}

Beaver Builder-Specific Tips

  • Do not assume clean markup means accessible markup. Beaver Builder outputs tidier HTML than most builders, but heading tags, ARIA on tabs/accordions, alt text, and contrast are still entirely your responsibility.
  • Set a heading plan and reflect it in each module's HTML Tag setting: one H1 (the page title or hero Heading), then H2/H3 in reading order. Control size with typography settings, never with the heading level.
  • Audit saved templates and imported layouts the moment you apply them. They commonly carry duplicate H1s, low-contrast text, and autoplaying sliders into the new page.
  • Turn slider auto-play off by default. If it is required, add a visible, keyboard-operable pause control with aria-pressed and enable pause-on-hover/focus. A static hero is almost always more accessible.
  • Tabs and Accordion modules usually need an ARIA/keyboard assist via an HTML/JavaScript module or theme code: expose aria-expanded on accordion headers and apply the tablist pattern (roles plus arrow keys) to tabs.
  • Test the published page with the keyboard and a screen reader, not the Beaver Builder editor preview. Tab order, autoplay, focus handling, and module ARIA only behave like production on the live front-end.

axe DevTools

Browser extension that scans the published Beaver Builder page for WCAG violations with specific fixes. Run it on the live front-end with sliders, tabs, accordions, and forms in place rather than on the editor preview.

WAVE by WebAIM

Visual evaluator that flags missing alt text, empty links, contrast failures, and heading-order problems directly on the rendered page, helpful for pinpointing which Beaver Builder module is at fault.

WebAIM Contrast Checker

Check module text, link, and button colors and the Beaver Builder Theme global palette against 4.5:1 and 3:1, including text placed over row background colors and photos.

NVDA + Firefox / VoiceOver + Safari

Manual screen-reader testing verifies heading announcements, accordion and tab state, slider behavior, and form labelling on Beaver Builder sites, things automated scanners cannot judge for announcement quality.

Lighthouse (Chrome DevTools)

Built-in Chrome audit that catches common Beaver Builder issues like low contrast and missing accessible names. Treat a high score as necessary but not sufficient and pair it with manual keyboard and screen-reader testing.

Beaver Builder Module Accessibility At a Glance

Plugin / Tool ModuleCommon FailureWCAGBest Fix
Heading / Callout section titles Tag chosen by size, broken outline1.3.1Set HTML Tag to match outline; size via typography
Tabs / Accordion grouped content No ARIA state, no full keyboard pattern4.1.2 / 2.1.1Add aria-expanded / tablist roles + key handling
Content Slider / Slideshow hero, galleries Autoplay, no pause control2.2.2Turn autoplay off or add a pause button
Contact Form / Subscribe lead capture Placeholder labels, general errors3.3.2Persistent labels; per-field error messages
Photo / Gallery images Empty alt text from Media Library1.1.1Add meaningful alt; hide decorative images

Frequently Asked Questions

Is Beaver Builder more accessible than Elementor or Divi?

Beaver Builder is well regarded for producing cleaner, lighter front-end markup than Elementor or Divi, and clean markup does make some accessibility work easier. But the issues that fail real audits - heading tags chosen by size, tabs and accordions missing the full ARIA and keyboard pattern, sliders that autoplay without a pause control, placeholder-only form labels, missing alt text, and low contrast - depend on how you build, not on which builder you chose. All three can produce a conformant site and all three can produce a failing one. Beaver Builder gives you a slightly better starting point; the heading plan, ARIA, alt text, and contrast are still your job. Always test the published front-end with a keyboard and a screen reader.

Do I need extra code to make Beaver Builder tabs and accordions accessible?

Often yes. The built-in Tabs and Accordion modules do not always expose the expanded/collapsed state or implement the complete keyboard pattern - arrow-key navigation between tabs, Enter/Space to operate accordion headers, and announced state changes. The cleanest fix is to add the missing ARIA (aria-expanded and aria-controls on accordion headers; role=tablist/tab/tabpanel plus arrow-key handling on tabs) with a small HTML/JavaScript module or child-theme code, or to use an accessible component you control. Avoid burying essential content inside a tab or accordion that a keyboard user cannot reach, and test the live page with a screen reader after any change.

Does the Beaver Builder Contact Form module meet WCAG?

Not by default in every configuration. The basic Contact Form and Subscribe modules can render field names as placeholder text rather than persistent labels, and they tend to show a single general error rather than messages tied to each field. To meet WCAG 3.3.2 and 3.3.1, enable visible labels associated via for/id, indicate required fields in text rather than color alone, associate each error with its field via aria-describedby, set aria-invalid on failed fields, and move focus to the first error on a failed submit. For multi-step or complex forms, an accessibility-focused form plugin is usually a safer choice than the built-in module.

Further Reading

Other CMS Checklists