Bricks Builder Accessibility Checklist 2026 | WCAG 2.1 AA Compliance

Bricks designers regularly create CTA buttons by adding a Div element, styling it, and attaching a click event via the Interactions panel. The result is a clickable div with no keyboard role, no Enter or Space activation, and no announcement to screen readers as a button. The same anti-pattern appears with icon-only buttons built from a Div containing an Icon element.

<div class="brxe-div cta-button" data-interactions="...">
  <span>Get started</span>
</div>

<button type="button" class="brxe-div cta-button" data-interactions="...">
  <span>Get started</span>
</button>

The Bricks Heading element defaults to H2 but designers frequently change a hero heading to H1 for visual size, then change a separate section heading to H1 for the same reason. The result is two or three H1 elements on the page. Screen reader users using heading navigation lose the ability to find the page topic. Search engines also penalise multi-H1 pages.

<section class="hero"><h1>Build faster sites</h1></section>
<section class="features"><h1>Why Bricks?</h1></section>
<section class="pricing"><h1>Pricing</h1></section>

<section class="hero"><h1>Build faster sites</h1></section>
<section class="features"><h2>Why Bricks?</h2></section>
<section class="pricing"><h2>Pricing</h2></section>

The Bricks Nav Menu element with the off-canvas trigger style renders a hamburger toggle that opens a slide-in menu on mobile. The default markup uses a div with onclick rather than a button, omits aria-expanded, and does not move keyboard focus into the menu when it opens. Screen reader users hear nothing when the menu appears, and keyboard users continue tabbing through the now-hidden page content.

<div class="brxe-nav-nested-toggle" onclick="openMenu()">
  <span class="icon-hamburger"></span>
</div>

<button class="brxe-nav-nested-toggle" aria-expanded="false" aria-controls="primary-nav" aria-label="Open menu">
  <span class="icon-hamburger" aria-hidden="true"></span>
</button>

The Bricks Slider element (built on Splide) ships with auto-play disabled by default, but designers routinely enable it for hero carousels with a 4-5 second interval. The element does not auto-emit a Pause / Play button, so users with cognitive disabilities, motion sensitivity, or screen readers cannot stop the rotation. WCAG 2.2.2 Pause, Stop, Hide requires moving content that auto-starts and lasts more than 5 seconds to be pausable.

<div class="brxe-slider" data-splide='{"autoplay":true,"interval":5000}'>
  ...
</div>

<div class="brxe-slider" data-splide='{"autoplay":true,"interval":5000}'>
  ...
  <button type="button" class="slider-pause" aria-pressed="false" aria-label="Pause slideshow">Pause</button>
</div>
<script>const splide = Splide('.brxe-slider').mount(); document.querySelector('.slider-pause').addEventListener('click', e => { const pressed = e.target.getAttribute('aria-pressed') === 'true'; pressed ? splide.Components.Autoplay.play() : splide.Components.Autoplay.pause(); e.target.setAttribute('aria-pressed', !pressed); });</script>

Bricks designers commonly build product or post cards inside a Query Loop, then wrap the entire card in a 'Block link' or place the card heading inside an anchor. The result is an anchor element containing a heading containing other interactive elements (price, add-to-cart). Screen readers announce the heading inside the link in confusing ways, and click targets overlap so screen-reader users may activate the wrong control.

<a href="/post/123" class="card-link">
  <article>
    <h3>How to fix WordPress accessibility</h3>
    <p>Excerpt...</p>
    <button>Add to favourites</button>
  </article>
</a>

<article class="card" style="position:relative">
  <h3><a href="/post/123" class="card-link">How to fix WordPress accessibility</a></h3>
  <p>Excerpt...</p>
  <button style="position:relative;z-index:2">Add to favourites</button>
</article>

Bricks Theme Styles let you define a global colour palette and apply it to every Heading, Text, and Button element. Designers frequently set the brand-blue colour for body text on a white background that measures only 3.2:1 contrast, then propagate that choice site-wide via Theme Styles. Because the failure is global, it shows up on every page in an audit.

/* Bricks Theme Style - Body text */
body { color: #5fa1d4; } /* 3.0:1 on white - fails */

/* Bricks Theme Style - Body text */
body { color: #1c5fc0; } /* 5.6:1 on white - passes */
/* Reserve the lighter brand-blue for accents only */

The Bricks Form element supports inline validation, but the error messages render inside a div that has no aria-live region and no programmatic association with the failed input. A blind user submits the form, hears nothing, and assumes nothing happened. Sighted users with cognitive disabilities also miss errors when the page does not scroll to the failed field.

<form class="brxe-form">
  <input id="email" type="email">
  <div class="error-message" style="display:none">Invalid email</div>
</form>

<form class="brxe-form" novalidate>
  <label for="email">Email</label>
  <input id="email" type="email" aria-describedby="email-error" aria-invalid="false">
  <div id="email-error" class="error-message" role="alert" aria-live="assertive"></div>
</form>
<script>document.addEventListener('brx_form_error', e => { e.detail.invalidFields[0].focus(); });</script>