Unbounce Accessibility Checklist 2026 | WCAG 2.1 AA & EAA

Last updated: 2026-06-01

Unbounce is a conversion-focused landing-page builder, and that single purpose explains exactly where its accessibility risks concentrate. Every page exists to capture a click or a form submission, so the elements an audit flags are the elements the campaign is built around: the lead-gen form, the exit pop-up, the sticky bar pinned to the screen, and the call-to-action button whose color was chosen by a conversion-rate test rather than a contrast check. Unbounce's pixel-precise drag-and-drop canvas is the source of most problems, because it positions elements with absolute coordinates and lets builders drop text, buttons, and images anywhere with no enforced structure. The result is that the visual order on screen and the DOM order a screen reader follows often diverge, so keyboard focus jumps around the page unpredictably. Headings are frequently styled text boxes rather than real heading elements, leaving screen reader users with no document outline. Form fields lean on placeholder text instead of persistent labels. Pop-ups and sticky bars open without moving or trapping keyboard focus and often cannot be dismissed with the Escape key. Dynamic Text Replacement swaps headline text based on the visitor's search keyword, which can inject content that no longer matches the page's accessible name or that reads awkwardly to a screen reader. And because builders run A/B variants, an accessible 'A' version is no guarantee the 'B' variant a visitor actually sees is accessible too. Unbounce ships no built-in accessibility checker, so every fix here is verified with external tools (axe, WAVE, Lighthouse) and a manual keyboard and screen reader pass on each published variant. This checklist walks the page in the order a lead encounters it.

Common Accessibility Issues

critical

Visual Order and DOM Order Diverge on the Drag-and-Drop Canvas

WCAG 1.3.2

Unbounce positions elements with absolute coordinates, so a builder can place a button visually above a paragraph while it sits after it in the underlying markup. Keyboard users then Tab in an order that does not match what they see, and screen reader users hear content in a sequence that may not make sense - a headline read after the form it introduces, or a CTA announced before the offer it relates to.

How to fix:

Build the page so the meaningful reading and focus order matches the visual order: add and arrange elements top-to-bottom in the layout, avoid layering content out of sequence, and after publishing, Tab through the page to confirm focus moves in a logical order. Test the page with a screen reader to verify content is announced in a sensible sequence, and rework any section where the order is wrong.

Before 
<!-- visually: heading, then form; in DOM: form first -->
<form style="top:240px">...</form>
<h2 style="top:120px">Get your free quote</h2>
After 
<section>
  <h2>Get your free quote</h2>
  <form>...</form>
</section>
<!-- DOM order matches the visual top-to-bottom order -->
serious

Styled Text Boxes Used Instead of Real Headings

WCAG 1.3.1

On the Unbounce canvas the fastest way to make 'a big bold headline' is to drop a text element and enlarge the font, which produces a visually-large paragraph with no heading semantics. Screen reader users who navigate by heading shortcuts find no headings at all, or an outline that jumps from h1 straight to h4, so they cannot scan the page structure the way sighted visitors do.

How to fix:

Use the text element's paragraph/heading format control to mark your hero headline as an H1 and section headings as H2/H3 in a logical order, rather than only changing the font size. Keep one H1 per page, do not skip levels, and confirm the rendered outline with a headings tool (the WAVE or HeadingsMap extension) on the published variant.

Before 
<p style="font-size:48px;font-weight:700">Save 40% This Week</p>
After 
<h1 style="font-size:48px;font-weight:700">Save 40% This Week</h1>
critical

Opt-in Form Fields Labeled Only by Placeholder Text

WCAG 1.3.1

Unbounce form fields default to placeholder hints ('Work email', 'Full name') rather than a persistent, programmatically associated label. The placeholder disappears the moment someone types, so screen reader users may hear nothing useful on focus and people with memory or attention disabilities lose the prompt. Placeholder text is not a label under WCAG.

How to fix:

In the form field settings, enable a visible label for every field instead of relying on the placeholder, and make sure each input has an associated label or a correct aria-label in the rendered page. Add autocomplete attributes (email, name, tel) so browsers and assistive tech can fill fields reliably, and keep the label visible while the user types.

Before 
<input type="email" placeholder="Work email">
After 
<label for="lead-email">Work email</label>
<input type="email" id="lead-email" name="email" autocomplete="email">
critical

Pop-ups and Sticky Bars That Do Not Trap or Move Focus

WCAG 2.4.3

Unbounce pop-ups (including exit-intent triggers) and sticky bars frequently open without moving keyboard focus into the overlay and without constraining Tab order inside it. Keyboard and screen reader users keep tabbing through the page behind the dialog, may never discover it, and often cannot reach the close control or dismiss it with the Escape key.

How to fix:

When a pop-up opens, move focus to its heading or first field, trap Tab within it, return focus to the trigger on close, and support Escape to dismiss. Expose it as role="dialog" with aria-modal="true" and an accessible name. For sticky bars, ensure the bar and its dismiss button are reachable and operable by keyboard. Where the Unbounce widget cannot be controlled, build the dialog in a custom HTML/JavaScript element following the dialog pattern and test it with the keyboard alone.

Before 
<div class="ub-popup" style="display:block">
  <span class="close">x</span>
  <form>...</form>
</div>
After 
<div role="dialog" aria-modal="true" aria-labelledby="pop-title">
  <h2 id="pop-title">Wait - grab the free guide</h2>
  <button aria-label="Close dialog" class="close">&times;</button>
  <form>...</form>
</div>
<!-- JS: focus in on open, trap Tab, restore focus + close on Escape -->
serious

Low-Contrast CTA Buttons and Microcopy From Conversion Palettes

WCAG 1.4.3

Conversion-optimized Unbounce templates often pair a brand-colored CTA button with white or light text, or use pale gray for form helper text and disclaimers, producing contrast below the 4.5:1 minimum for normal text (3:1 for large text). The button may convert well in a test yet be unreadable for low-vision visitors or anyone in bright light.

How to fix:

Check every button, link, and block of microcopy with a contrast tool and adjust the text or background until normal text reaches 4.5:1 and large text 3:1. Do not rely on color alone to mark the primary action - keep a clear text label - and re-check contrast on each A/B variant, since a 'winning' color is meaningless if visitors cannot read it.

Before 
.cta { background:#7ec8e3; color:#ffffff; } /* ~1.7:1 */
After 
.cta { background:#0a5a7a; color:#ffffff; } /* ~5.9:1 */
moderate

Dynamic Text Replacement Breaks Accessible Names and Reading Flow

WCAG 2.4.6

Unbounce Dynamic Text Replacement swaps headline or label text based on the visitor's search keyword. When the injected term is awkward, lowercase, or mismatched, the page's main heading or a link's accessible name can read poorly to a screen reader, and the descriptive value of headings and labels - which WCAG expects to describe topic or purpose - degrades.

How to fix:

Always set a sensible default for every dynamic field so the page still reads well when no keyword is passed, constrain replacement to short phrases that fit grammatically, and review the rendered output with a screen reader for the keywords you actually target. Never put essential meaning only in dynamically replaced text.

Unbounce-Specific Tips

  • After publishing, Tab through the whole page once: because Unbounce positions elements absolutely, the focus order is the first thing to break and the easiest to miss in the visual editor.
  • Use the text element's heading format (H1, H2, H3) instead of only enlarging the font, so screen reader users get a real document outline to navigate by.
  • Test every A/B variant and every device layout separately - an accessible variant A tells you nothing about the variant B a visitor is actually served, and Unbounce lets the mobile layout differ from desktop.
  • Turn on visible labels for all form fields and add autocomplete attributes; never ship a form that relies on placeholder text as its only label.
  • Re-run a contrast check after any conversion test that changes button or text color, and verify pop-ups and sticky bars can be opened, used, and dismissed with the keyboard alone.

axe DevTools (browser extension)

Run axe on the published Unbounce variant to catch missing form labels, contrast failures on CTA buttons, and dialogs missing roles that the visual editor will not flag.

WAVE Browser Extension

WAVE's structure view quickly reveals whether your big headline text is a real heading and whether the page has a sensible outline after the drag-and-drop layout is rendered.

Colour Contrast Analyser (TPGi)

Sample CTA button text and pale helper microcopy against their backgrounds to confirm conversion-palette colors still meet the 4.5:1 (or 3:1 for large text) ratio.

Unbounce Accessibility: Conversion Features vs. Fixes

Plugin / Tool FeatureCommon FailureWCAG CriterionFix Direction
Drag-and-drop canvas absolute positioning Focus/reading order differs from visual order1.3.2 Meaningful SequenceArrange content logically; Tab-test the page
Headline text boxes font enlarged, not a heading No real heading structure1.3.1 Info and RelationshipsMark text as H1/H2/H3 via the format control
Opt-in forms placeholder labels No persistent field label1.3.1 Info and RelationshipsEnable visible labels; add autocomplete
Pop-ups & sticky bars exit-intent / pinned Focus not trapped; no Escape close2.4.3 Focus OrderDialog pattern: focus in, trap, Escape to close
CTA buttons conversion-test colors Text contrast below 4.5:11.4.3 Contrast (Minimum)Adjust colors; re-check on every variant

Frequently Asked Questions

Why does keyboard focus jump around on my Unbounce page?

Because Unbounce's drag-and-drop canvas positions elements with absolute coordinates, the order elements appear in the underlying HTML can differ from where they sit on screen. Keyboard focus and screen reader reading order follow the HTML, not the visual layout, so they can jump unpredictably. Fix it by arranging content in a logical top-to-bottom sequence in the builder and then Tabbing through the published page to confirm focus moves in the order a visitor reads.

Are Unbounce pop-ups and sticky bars accessible by default?

Often not. Many open without moving keyboard focus into the overlay, do not trap focus, and cannot be closed with the Escape key, so keyboard and screen reader users get stuck behind them. Make sure focus moves into the pop-up on open, is constrained inside it, returns to the trigger on close, and that Escape and a labeled close button both dismiss it. If the built-in widget cannot do this, build the dialog with a custom HTML element following the dialog pattern.

Do I need to test every A/B variant of my Unbounce page?

Yes. Unbounce serves different variants to different visitors, and an accessible variant A does not guarantee variant B - which may use different colors, copy, or layout - is accessible. Run an automated check and a manual keyboard and screen reader pass on each published variant, and re-test after any conversion experiment that changes button color, text, or structure.

Further Reading

Other CMS Checklists