Divi gives you visual control over almost every pixel, which is exactly why Divi accessibility problems are so easy to create without noticing. The builder will happily let you stack three H1s, style a link to look like a button, or set pale gray text that no one with low vision can read.
None of that shows up in a design preview, but it shows up immediately for someone using a keyboard or a screen reader, and it is what an automated audit flags first. This guide walks through the five areas where Divi pages most often fail WCAG 2.2 Level AA, the baseline the European Accessibility Act has required since 28 June 2025, with concrete fixes you can apply inside the builder.
Heading modules: structure, not size
Divi's heading-bearing modules (the Text module, the Blurb title, the dedicated Heading module) let you pick H1 through H6 from a dropdown, and the visual size is set separately in the Design tab. People treat the dropdown as a font-size picker. It is not. The heading level is the document outline that screen-reader users navigate by, jumping heading to heading to scan a page.
Two rules fix most of it. First, exactly one H1 per page, usually the page or post title; check whether your Divi theme already outputs an H1 in the template before you add another. Second, never skip levels: an H2 section can contain H3 subsections, but jumping from H2 straight to H4 because H4 looked the right size breaks the outline. Style the size in the Design tab and keep the level semantic. This is what WCAG 1.3.1 Info and Relationships asks for.
A common Divi trap is the Blurb module, whose title defaults to an H4 regardless of where it sits. Drop three Blurbs into a section under an H2 and you get three orphaned H4s with no H3 between them. Change each Blurb's title level to match its real position. You can map your whole outline quickly with a heading checker before and after editing.
- One H1 per page, matching the main topic
- No skipped levels (H2 to H4 is a failure)
- Use the Design tab for size, the dropdown for meaning
- Re-check Blurb and CTA modules, which default to fixed levels
Buttons vs links: same look, different jobs
Divi has a Button module and inline links, and visually you can make either look like the other. Semantically they are not interchangeable, and assistive technology announces them differently. A link navigates to a URL or anchor. A button performs an action on the current page: open a toggle, submit, play a video, expand a menu.
The failure pattern: a Button module pointed at a real page (fine, Divi renders it as an anchor), versus a clickable div or icon wired up with custom code or a plugin that triggers JavaScript but exposes no role, no name, and no keyboard support. A sighted mouse user clicks it; a keyboard user cannot reach it, and a screen reader skips it entirely. That breaks WCAG 2.1.1 Keyboard and 4.1.2 Name, Role, Value.
Practical guidance: if it goes somewhere, use the Button module or a normal link. If it does something on the page, it must be a real button element or carry role="button", be in the tab order, and respond to Enter and Space. Give every control a meaningful accessible name, not "Click here" or a bare arrow icon. Under WCAG 2.2, interactive targets should also be at least 24 by 24 CSS pixels (2.5.8 Target Size Minimum), so resist shrinking icon buttons to tiny tap targets on mobile.
Forms: labels, errors, and the contact module
Divi's Contact Form and Email Optin modules often rely on placeholder text as the only label. Placeholders disappear the moment someone types, are not reliably read by every screen reader, and usually fail contrast as gray-on-white. Every field needs a persistent, programmatically associated label, not just a placeholder, to satisfy WCAG 3.3.2 Labels or Instructions and 1.3.1 Info and Relationships.
Enable Divi's visible field titles where available, or add real label elements via the module's title settings. Mark required fields in text, not by color or an asterisk alone. When validation fails, the error must be identified in text and tied to the field (3.3.1 Error Identification), and helpful suggestions improve it further (3.3.3 Error Suggestion). WCAG 2.2 also adds 3.3.7 Redundant Entry, so avoid forcing users to retype information they already gave, and 3.3.8 Accessible Authentication, so do not gate submission behind a puzzle-style CAPTCHA with no accessible alternative.
After a successful or failed submit, the result should be announced, not just shown. A status message in an ARIA live region covers 4.1.3 Status Messages so screen-reader users know the form went through. Our accessible forms guide covers label association, error wiring, and live regions in depth.
Animations and the reduced-motion setting
Divi ships entrance animations, parallax backgrounds, scroll effects, and sticky transforms, and they are tempting to layer on. Motion that starts automatically, runs longer than five seconds, and sits alongside other content must offer a way to pause, stop, or hide it under WCAG 2.2.2 Pause, Stop, Hide (Level A). Large parallax or zoom movement can also trigger vestibular discomfort, which is why honoring a reduced-motion preference is a strong best practice (it aligns with the AAA criterion 2.3.3 Animation from Interactions).
The fix is to honor the operating-system reduced-motion preference, which Divi does not do automatically. Add CSS in Divi to Theme Options to neutralize motion when the user has asked for less of it. This single block disables Divi's transition and transform animations for those users while leaving them intact for everyone else.
@media (prefers-reduced-motion: reduce) { .et_animated, .et-pb-parallax-bg, [class*="et-animated"] { animation: none !important; transition: none !important; transform: none !important; } }
Test it by turning on Reduce Motion in your device settings and reloading. Avoid pure-decoration autoplay video and infinite-loop background motion entirely. The reduced-motion accessibility guide has the full pattern.
Contrast pitfalls baked into Divi defaults
Contrast is where Divi's beautiful defaults quietly fail. WCAG requires 4.5:1 for normal text, 3:1 for large text (at least 18pt, or 14pt bold), and 3:1 for the boundary of UI components and meaningful graphics (1.4.11 Non-text Contrast). Several Divi defaults sit below those lines.
- Light-gray body and caption text on white, common in default presets, often falls short of 4.5:1
- Button text over a gradient or photo background where contrast varies across the image
- White text on a brand pastel that looks soft but reads below 4.5:1 for body copy
- Form placeholders and 'powered by' microcopy in pale gray
- Link color that differs from body text by hue alone, with no underline, failing 1.4.1 Use of Color
Check the actual rendered colors, not the swatches in your palette, because overlays and opacity change the result. Run each text and button color through a contrast checker, and remember that text over an image must meet the ratio at its worst point, so add a solid or sufficiently dark overlay rather than trusting a busy photo.
Putting it together
None of these fixes require leaving the builder or rebuilding your site. Correct the heading levels, make every interactive control a real, keyboard-reachable button or link, give form fields persistent labels and announced errors, gate animation behind prefers-reduced-motion, and raise every color that misses its ratio. That covers the failures that an audit and a real user will hit first.
Then verify, because a design preview cannot. Tab through the page with no mouse, confirm a visible focus outline on every control, and run an automated pass. You can scan any Divi page for these exact issues with AccessScan's free checker, then work through the remaining items using our accessibility checklist and the broader WordPress accessibility guide. For the legal baseline behind WCAG 2.2 AA, see our European Accessibility Act overview. Scan your site now.