Brizy Accessibility Checklist 2026 | WCAG 2.2 AA & EAA Compliance

Last updated: 2026-06-11

Brizy is a drag-and-drop website builder that comes in two flavours: Brizy Cloud, a hosted standalone builder, and Brizy for WordPress, a free page-builder plugin used on top of an existing WordPress install. Both share the same visual editor, where you size and style elements by eye, drop in pre-built blocks and popups, and publish without touching code. That convenience is exactly where accessibility problems start, because the editor lets you make every common mistake without warning. You pick a heading by how big it looks rather than its level in the document outline, so pages end up with several H1s, skipped levels, and styled text blocks standing in for real headings. The color picker shows no contrast feedback, so pale body text and low-contrast buttons ship straight to production. Popups and modals — a headline Brizy feature — open without trapping focus or returning it, leaving keyboard and screen reader users stranded behind an invisible overlay. Forms render placeholders in place of persistent labels, the mega menu and mobile hamburger frequently break keyboard operation, and the icon and image elements expose alt text as an optional field that editors leave blank. With the European Accessibility Act now enforceable for businesses serving EU consumers, and ADA Title III obligations applying to Brizy's large base of small-business and agency sites in the United States, these defaults matter. This checklist walks through the issues we see most often on Brizy sites and the specific editor settings that fix each one. None of this is legal advice; consult a qualified attorney for your jurisdiction.

Common Accessibility Issues

critical

Heading Levels Chosen by Size, Not Document Structure

WCAG 1.3.1

In the Brizy editor you add a Heading element and then resize it visually, so editors pick the look they want rather than the correct level. Pages routinely end up with multiple H1s, jumps from H2 to H4, and ordinary Text elements styled large to act as section titles. Screen reader users who navigate by heading get an outline that does not match what they see, and skipped levels are reported as a WCAG 1.3.1 failure.

How to fix:

Set the semantic tag (H1-H6) explicitly on every Heading element and control the visual size separately with the typography styles. Use exactly one H1 per page (the main title), then H2 for sections and H3 for subsections with no skipped levels. Convert any large styled Text element that acts as a heading into a real Heading element with the right tag. Review the heading outline of each page before publishing.

Before 
<!-- Two H1s plus a styled Text block as a heading -->
<h1>Welcome</h1>
<h1>Our Services</h1>
<div class="brz-text" style="font-size:32px;font-weight:700">Pricing</div>
After 
<h1>Welcome</h1>
<h2>Our Services</h2>
<h2>Pricing</h2>
critical

Color Picker Has No Contrast Feedback

WCAG 1.4.3

Brizy's color picker and global color palette let editors choose any text, button, and background color with no warning when the combination falls below the WCAG minimum. Because editors judge colors against the design's own background, light-gray body text, pale button fills under 4.5:1, and low-contrast hover states are easy to miss and ship to production. Text over full-width image backgrounds is especially risky because contrast varies across the photo.

How to fix:

Check body text, links, and buttons with a contrast checker and correct them to at least 4.5:1 for normal text and 3:1 for large text and UI components. Define a global color palette in Brizy using only contrast-safe combinations so editors reuse safe colors instead of inventing failing ones. For text over images, add a solid or semi-opaque overlay so contrast holds across the whole image. Re-check hover and focus states, which are often forgotten.

Before 
/* Pale gray body text on white - about 2.8:1, fails */
.brz-text { color: #aaaaaa; background: #ffffff; }
After 
/* Darkened to about 7:1, passes AA and AAA body text */
.brz-text { color: #595959; background: #ffffff; }
critical

Popups and Modals Do Not Trap or Return Focus

WCAG 2.4.3

Popups are a flagship Brizy feature used for newsletter opt-ins, promotions, and announcements, but by default they often do not move keyboard focus into the popup when it opens, do not trap focus inside it, and do not return focus to the trigger on close. Keyboard users can tab behind the overlay onto the hidden page, and screen reader users may not be told a dialog opened. Auto-opening popups with no obvious close compound the problem.

How to fix:

Ensure popups expose a real, keyboard-reachable close button with an accessible name (for example aria-label="Close"), can be dismissed with the Escape key, move focus into the dialog on open and return it to the trigger on close, and keep focus trapped inside while open. Give the popup container role="dialog" and aria-modal="true" with an accessible name. Avoid popups that open automatically on load without a clear, persistent close control.

Before 
<!-- Popup with no role, no labelled close, focus not managed -->
<div class="brz-popup">
  <span class="close" onclick="hide()">x</span>
  ...
</div>
After 
<div class="brz-popup" role="dialog" aria-modal="true" aria-label="Newsletter signup">
  <button type="button" aria-label="Close" class="close">x</button>
  ...
</div>
<!-- JS: focus into dialog, trap focus, Escape closes, focus returns to trigger -->
serious

Form Fields Use Placeholders Instead of Labels

WCAG 3.3.2

The Brizy Form element commonly renders the field name as placeholder text rather than a persistent, associated label, and surfaces validation as a single generic message rather than per-field errors. Placeholder text disappears as soon as the user types, leaving no visible label, is announced inconsistently by screen readers, and often fails contrast itself. Unassociated error messages leave screen reader users unsure which field failed.

How to fix:

Add a visible, persistent label for every field and make sure it is associated via for/id, not used as a placeholder. Indicate required fields in text, not color alone. Associate each error message with its field using aria-describedby, set aria-invalid on failed fields, and move focus to the first error on a failed submit. In Brizy, set the field Label option rather than relying on the placeholder, and test the form with a keyboard and a screen reader.

Before 
<input type="email" placeholder="Email" /> <!-- placeholder as the only label -->
After 
<label for="brz-email">Email <abbr title="required">*</abbr></label>
<input id="brz-email" type="email" required aria-required="true" aria-describedby="brz-email-err" />
<span id="brz-email-err" role="alert"></span>
serious

Mega Menu and Mobile Hamburger Break Keyboard Operation

WCAG 2.1.1

Brizy's Menu element supports a multi-column mega menu and a mobile hamburger toggle. The mega menu's submenus often reveal only on hover, so keyboard users cannot reach them, and the hamburger toggle is frequently a div or icon with no button semantics, no aria-expanded state, and no accessible name. Keyboard and screen reader users then cannot open the navigation at all on mobile, which is a 2.1.1 keyboard-access failure.

How to fix:

Make the hamburger a real button element with an accessible name (aria-label="Menu") and aria-expanded that toggles true/false as it opens and closes. Ensure submenus open on focus and click, not hover alone, and that every menu item is reachable and operable with Tab and Enter. Test the full navigation with the keyboard on both desktop and the mobile breakpoint, including closing the menu with Escape.

Before 
<div class="brz-menu-toggle" onclick="toggle()"></div>
<ul class="submenu"><!-- only shows on :hover --></ul>
After 
<button class="brz-menu-toggle" aria-label="Menu" aria-expanded="false" aria-controls="main-nav">
  <span aria-hidden="true">&#9776;</span>
</button>
<ul id="main-nav"><!-- submenu opens on focus and click, closes on Escape --></ul>
serious

Images and Icon Buttons Ship Without Accessible Names

WCAG 1.1.1

The Brizy Image element exposes alt text as an optional field, so informative images - product shots, banners with text baked in, infographics - regularly publish with empty or filename-based alt. The Icon element is often used as a standalone link or button (social icons, a search trigger) with no text and no accessible name, so screen reader users hear nothing or only the file name.

How to fix:

Set meaningful alt text on every informative Image element describing what it communicates; for a banner with text in the graphic, reproduce that text in the alt. Mark purely decorative images so they render alt="". For icon-only links and buttons, add an accessible name with aria-label and hide the decorative glyph from assistive tech with aria-hidden="true". Never let the build fall back to the filename as alt.

Before 
<img src="sale-banner.png" alt=""> <!-- informative banner, empty alt -->
<a href="/search"><i class="icon-search"></i></a> <!-- no name -->
After 
<img src="sale-banner.png" alt="Summer sale: 30% off all orders">
<a href="/search" aria-label="Search"><i class="icon-search" aria-hidden="true"></i></a>
moderate

Entrance Animations Ignore Reduced-Motion Preferences

WCAG 2.3.3

Brizy offers built-in entrance, scroll, and hover animations on blocks and elements, and they typically run for every visitor regardless of the operating-system reduce-motion setting. Large parallax, zoom, and slide effects can trigger nausea, dizziness, or migraines for people with vestibular disorders, and continuous motion competes for attention for users with cognitive disabilities.

How to fix:

Respect the prefers-reduced-motion media query so entrance and scroll animations are disabled when a visitor has requested reduced motion. Where Brizy does not expose this, add custom CSS in the editor or theme that switches off transforms, transitions, and animations under the reduced-motion query. Keep essential motion brief and avoid large parallax and auto-playing zoom effects on key pages.

Before 
/* Parallax and entrance animation applied to all visitors */
.brz-animated { transform: translateY(60px); transition: transform .6s; }
After 
@media (prefers-reduced-motion: reduce) {
  .brz-animated { transform: none !important; transition: none !important; animation: none !important; }
}

Brizy-Specific Tips

  • Set the semantic heading tag (H1-H6) explicitly on every Heading element and control size with typography styles - never let visual size decide the level. Keep one H1 per page.
  • Define a global color palette using only contrast-safe combinations so editors reuse safe colors; Brizy's picker gives no contrast warning of its own.
  • Treat every popup as a dialog: labelled close button, Escape to dismiss, focus moved in on open and returned on close, and focus trapped while open.
  • Use the form field Label option, not the placeholder, for field names, and tie validation errors to fields with aria-describedby.
  • Make the mobile hamburger a real button with aria-expanded and an accessible name, and ensure mega-menu submenus open on focus and click, not hover alone.
  • Set meaningful alt on informative images and aria-label on icon-only links and buttons; the alt field is optional, so it is easy to skip.

axe DevTools

Browser extension for automated WCAG testing. Run it on the published Brizy page (not just the editor preview) to catch missing alt text, low contrast, broken headings, and unlabelled buttons across popups and forms.

WebAIM Contrast Checker

Check Brizy text, link, button, and hover colors against the 4.5:1 and 3:1 minimums before saving them into your global palette, since the Brizy color picker shows no contrast feedback.

NVDA + Firefox / VoiceOver + Safari

Manual screen-reader testing verifies that popups announce as dialogs, the menu toggle reports its expanded state, and form fields and errors are read correctly - things automated scanners cannot fully judge.

Keyboard-only testing (Tab, Enter, Escape)

Unplug the mouse and operate the whole page with the keyboard to expose Brizy's most common failures: hover-only mega menus, hamburger toggles you cannot open, and popups that trap or leak focus.

Lighthouse (Chrome DevTools)

Built-in Chrome audit that flags low contrast, missing alt text, and missing accessible names on a published Brizy page. Treat a high score as necessary but not sufficient, and pair it with manual keyboard and screen-reader testing.

Brizy Accessibility At a Glance

Plugin / Tool AreaCommon FailureWCAGBest Fix
Headings Heading element Level chosen by size; multiple H1s1.3.1Set explicit H1-H6 tag, style size separately
Color picker / palette No contrast warning; pale text ships1.4.3Build a contrast-safe global palette
Popups opt-ins, promos Focus not trapped or returned2.4.3role=dialog, Escape, manage focus
Forms Form element Placeholder used as label3.3.2Real associated label + field errors
Menu mega menu / hamburger Hover-only; toggle not a button2.1.1Button with aria-expanded; open on focus

Frequently Asked Questions

Does Brizy Cloud or the WordPress plugin behave differently for accessibility?

The accessibility issues are largely the same because both use the identical Brizy visual editor: heading levels chosen by size, a color picker with no contrast feedback, popups that do not manage focus, placeholder-only form labels, hover-dependent mega menus, and optional alt text. The main difference is what surrounds the page. On Brizy for WordPress you also inherit the WordPress theme, other plugins, and the comment and search features, so you should audit those too and can add custom CSS through the theme. On Brizy Cloud you are limited to what the hosted builder exposes, so respecting reduced motion or hardening a popup may require the editor's custom-code option. In both cases the fixes are the same: set explicit heading tags, build a contrast-safe palette, make popups behave like dialogs, use real labels, and give icons and images accessible names.

Are Brizy popups accessible by default?

Not reliably. Popups are one of Brizy's headline features, but out of the box they frequently open without moving keyboard focus into the dialog, do not trap focus while open, and do not return focus to the trigger on close, so keyboard users can tab onto the hidden page behind the overlay. Many also lack a properly labelled close button and cannot be dismissed with the Escape key, and auto-opening promotional popups make this worse. To make a Brizy popup conformant, give it role="dialog" with aria-modal="true" and an accessible name, expose a real close button with an accessible name, support Escape to close, move focus in on open and back to the trigger on close, and keep focus trapped inside. Then test the whole open-and-close cycle with the keyboard and a screen reader.

Can a Brizy site pass an EAA or ADA accessibility audit?

Yes, a Brizy site can be made to conform to WCAG 2.2 AA, which is the benchmark both the European Accessibility Act and US ADA Title III claims are measured against, but not by accepting the defaults. The builder will happily let you ship multiple H1s, low-contrast text, focus-leaking popups, placeholder-only forms, and unlabelled icons - all of which are common audit findings. Conformance comes from working against those defaults: set explicit heading tags, build a contrast-safe global palette, treat popups as managed dialogs, use real associated form labels with field-level errors, make the navigation and hamburger keyboard-operable, and give every informative image and icon an accessible name. Verify the result with an automated scanner plus manual keyboard and screen-reader testing on the published page. This is general guidance, not legal advice; consult a qualified attorney about your obligations.

Further Reading

Other CMS Checklists