Mailchimp Websites Accessibility Checklist 2026 | WCAG & EAA
Last updated: 2026-06-16
Mailchimp is best known as an email platform, but its free website builder, landing pages, and embedded signup forms now sit on the public web of hundreds of thousands of small businesses, and every one of them is in scope for the same accessibility rules as a full CMS. The catch with Mailchimp is that most users never think of it as a website at all. They design a landing page to capture leads, drop a signup form on another site, and move on, never running it through a single accessibility check. That gap is exactly where the recurring failures live: signup forms that use placeholder text instead of real labels, single-page landing layouts that stack three competing H1-styled headlines, and the Mailchimp pop-up form that traps keyboard focus behind it.
Because Mailchimp's audience skews toward marketers and solo founders rather than developers, the platform leans heavily on templated drag-and-drop sections where the underlying markup is hidden from the user. You choose a content block, pick colors, and Mailchimp generates the HTML, which means accessibility is decided by how disciplined you are inside the editor: whether you write alt text, whether you pick button colors that pass contrast, whether your headline blocks use a real heading hierarchy. This checklist walks through the issues we see most often on Mailchimp websites and forms, maps each to its WCAG 2.1 AA success criterion, and gives you a fix you can apply inside the Mailchimp editor without touching code. It is organized by impact, with the form and pop-up issues first because those are both the most common Mailchimp use case and the elements most likely to draw an ADA demand letter.
Common Accessibility Issues
Mailchimp's hosted and embedded signup forms frequently rely on placeholder text ('Email Address', 'First Name') as the only field identification. Placeholders disappear the moment a user starts typing, are read inconsistently by screen readers, and fail the low contrast threshold by default. A subscriber who tabs back to review what they entered has no label to confirm which field is which.
In the Mailchimp form builder, keep the field labels turned on rather than hiding them in favor of placeholders. Each form field has a label setting; ensure it is visible above or beside the input. For embedded forms, use the 'naked' or unstyled embed and add your own <label for> association if your site's CSS hides the default labels. Never rely on the placeholder as the accessible name.
<input type="email" name="EMAIL" placeholder="Email Address" required><label for="mce-EMAIL">Email Address <span aria-hidden="true">*</span></label>
<input type="email" id="mce-EMAIL" name="EMAIL" autocomplete="email" required>The Mailchimp pop-up (subscriber pop-up) overlays the page but does not move keyboard focus into the dialog when it opens, does not trap focus inside it, and the close control is often a small unlabeled X. Keyboard users tab straight past the visible pop-up into the page behind it, and screen reader users get no announcement that a dialog appeared.
Configure the pop-up to be triggered by user action (a button click) rather than automatically on load where possible, which reduces the disorientation. If you keep an automatic pop-up, test it with the keyboard: focus must move into the pop-up on open, Escape must close it, and the close button must have an accessible name like 'Close signup form'. Where Mailchimp's native pop-up cannot meet this, replace it with an inline embedded form, which avoids the dialog problem entirely.
<div class="mc-modal"><button class="close">x</button> ... </div><div role="dialog" aria-modal="true" aria-label="Newsletter signup">
<button type="button" aria-label="Close signup form">x</button>
...
</div>Mailchimp's color pickers make it easy to set a button or link color that matches a brand palette but fails the 4.5:1 contrast minimum for text, most commonly white text on a light teal, yellow, or pastel accent. Default template link colors also frequently fall below 4.5:1 against white page backgrounds.
Run every button and link color combination through a contrast checker before publishing. In the Mailchimp design panel, darken the button background or switch the button text to a dark color until the combination passes 4.5:1 for normal text (3:1 for large text). Do the same for link colors against the page background, and check the visited and hover states if you customize them.
Mailchimp landing pages are built from stacked content blocks, and the title block plus several large 'heading' style text blocks can all render as H1 or skip levels entirely, since users pick blocks by how they look rather than their semantic level. Screen reader users navigating by headings get a flat or nonsensical outline of the page.
Use one H1 per landing page (the page's main headline), then H2 for each major section and H3 for sub-points. In the text block editor, set the heading level deliberately using the paragraph/heading style dropdown rather than just enlarging body text. If a block does not expose heading levels, keep it as body text and let one clearly chosen headline block be the H1.
The Mailchimp image block does not force you to add alt text, so hero images, product shots, and logos are routinely published with empty or auto-generated alt attributes. Lead-magnet graphics that contain text (an ebook cover with the title on it) are especially harmful when the text is not transcribed.
Select each image block and fill in the alt text field with a description of the image's purpose. Transcribe any text baked into an image. For purely decorative dividers or background flourishes, set the alt text to empty so screen readers skip them rather than announcing a filename.
Some Mailchimp templates and embedded third-party widgets include moving or auto-advancing content. Content that moves or updates automatically for more than five seconds without a pause control fails Pause, Stop, Hide and can disorient users with cognitive or vestibular conditions.
Prefer static hero sections over auto-advancing carousels on Mailchimp landing pages. If you embed a third-party slider via custom code, ensure it has a visible, keyboard-operable pause control and respects the prefers-reduced-motion setting. Keep any animation under five seconds or make it user-triggered.
Mailchimp Websites & Landing Pages-Specific Tips
- Turn on visible field labels in the Mailchimp form builder for every signup form and landing page form; the placeholder is never a substitute for a label.
- Prefer an inline embedded signup form over the automatic pop-up - it sidesteps the focus-trap and dialog announcement problems entirely.
- Set heading levels deliberately in each text block (one H1 per page, H2 for sections) instead of just choosing the largest font size.
- Run every button and link color through a contrast checker; Mailchimp's pastel and accent presets fail 4.5:1 more often than they pass.
- Add alt text to every image block and transcribe any text inside lead-magnet graphics and ebook covers.
- Set the email field's autocomplete attribute to 'email' so browsers and assistive tech can autofill it, and add a real <label> when using the unstyled embed.
Recommended Tools
WAVE Browser Extension
Run it on your published Mailchimp landing page and any page hosting an embedded form to catch missing labels, empty alt text, and contrast failures.
WebAIM Contrast Checker
Verify Mailchimp button and link colors against the 4.5:1 and 3:1 minimums before you publish; brand accent presets often fail.
axe DevTools
Automated WCAG scanning that reliably flags unlabeled form inputs and pop-up dialogs that lack an accessible name.
Keyboard-only testing (Tab, Enter, Escape)
Open the signup pop-up and complete the form with only the keyboard; if focus never enters the pop-up or Escape does not close it, keyboard users are blocked.
NVDA + Firefox / VoiceOver + Safari
Screen-reader testing reveals whether form fields announce a name, whether the pop-up is announced as a dialog, and what your hero images actually convey.
Mailchimp Websites Accessibility At a Glance
| Plugin / Tool | Area | Common Failure | WCAG | Best Fix |
|---|---|---|---|---|
| Signup forms embedded/hosted | Placeholder-only fields | 3.3.2 | Keep visible labels on every field | |
| Pop-up form subscriber pop-up | No focus management, tiny X | 2.4.3 | Inline embed, or labeled close + Escape | |
| Buttons brand accents | White on pastel ~3:1 | 1.4.3 | Darken background or use dark text | |
| Landing headings stacked blocks | Multiple H1s, skipped levels | 1.3.1 | One H1, H2 sections set per block | |
| Images hero/lead magnets | Empty or filename alt | 1.1.1 | Describe purpose, transcribe text |
Frequently Asked Questions
Do accessibility laws apply to a Mailchimp signup form embedded on my site?
Yes. The signup form is part of your website's user experience, and accessibility law looks at the experience a visitor has, not at which vendor generated a particular widget. If a screen reader or keyboard user cannot complete your Mailchimp form, that is a barrier on your site regardless of the fact that Mailchimp produced the markup. Under the ADA in the US, demand letters routinely cite unlabeled form fields and keyboard-trapping pop-ups, both of which are common Mailchimp defaults. Under the European Accessibility Act, signup and lead-capture forms tied to selling goods or services to EU consumers fall within scope. The practical takeaway is that you are responsible for the accessibility of everything that renders on your pages, so you should configure the Mailchimp form for visible labels and test it, or use the unstyled embed and add your own accessible markup. This is general guidance, not legal advice; consult a qualified attorney about your specific situation.
Can I make Mailchimp forms accessible without writing code?
Mostly, yes. The highest-impact fixes are configuration choices inside the Mailchimp builder: keeping field labels visible instead of relying on placeholders, choosing button and link colors that pass contrast, setting deliberate heading levels on landing pages, and writing alt text for images. The one area where code helps is the embedded form on a site you control: if your theme's CSS hides Mailchimp's labels, use the 'naked' unstyled embed and add your own
Is the Mailchimp pop-up form a compliance risk?
It can be, because the native pop-up tends to fail two things keyboard and screen reader users depend on: focus does not move into the pop-up when it opens, and the close control is frequently an unlabeled icon. That combination means a keyboard user can tab past a visible pop-up into the page behind it, and a screen reader user may never be told a dialog appeared. None of this is a reason to abandon lead capture - it is a reason to test the pop-up with the keyboard and a screen reader, ensure focus enters it, Escape closes it, and the close button has a name like 'Close signup form'. Where the native widget cannot meet those expectations, an inline embedded signup form delivers the same capture without the dialog risk and is usually the safer default.
Further Reading
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.