Optimizely (formerly Episerver) is a digital experience platform combining content management, A/B testing, and personalisation. Its experimentation engine means a single URL can serve multiple page variants simultaneously - and each needs to be accessible independently. Under the EAA, Optimizely sites serving EU consumers must meet EN 301 549 requirements.
Common Optimizely accessibility issues
A/B test variants introduce accessibility regressions
Optimizely's experimentation platform lets teams create page variants for A/B testing. Test variants are often created by marketers focused on conversion metrics, not accessibility - changing button colours to below-contrast ratios, restructuring layouts in ways that break heading hierarchy, or replacing accessible components with untested alternatives.
Content area blocks lack consistent accessibility
Optimizely's block-based content model lets authors assemble pages from content blocks. Without block-level accessibility validation, individual blocks can have missing alt text, broken heading structure, or inaccessible interactive elements that compound across the page.
Feature flags change rendered components without testing
Optimizely's feature flagging can swap components, layouts, or entire page sections for different user segments. Flagged-on components may not have received the same accessibility testing as the default components they replace.
TinyMCE content lacks structure enforcement
Optimizely CMS uses TinyMCE for rich text editing. Content authors can produce unstructured HTML - images without alt text, tables without headers, headings chosen for size rather than hierarchy - and the CMS doesn't prevent publication of inaccessible content.
Server-side rendering with client-side experimentation
Optimizely can serve server-rendered pages that are then modified client-side by the experimentation SDK. This client-side modification can alter DOM structure, change element attributes, and inject new content - all of which can introduce accessibility issues that weren't present in the server-rendered version.
How Lumi works with Optimizely
Lumi scans your Optimizely site across all published pages, testing content block combinations, experiment variants (where accessible via targeting), and feature-flagged components. Our five engines detect issues in CMS-authored content, block markup, and experimentation-modified DOM. Monitor continuously to catch issues from new experiments, content updates, and feature flag changes.
Optimizely-specific WCAG gotchas
Experiments multiply the accessibility surface area
Every active A/B test creates new page variants that need accessibility validation. A page with three simultaneous experiments can produce eight distinct variants, each with potentially different accessibility issues.
Winning experiment variants inherit accessibility debt
When an A/B test concludes and the winning variant is made permanent, its accessibility issues become permanent too. If the variant was never tested for accessibility, those issues are now in production for all users.
Scan your Optimizely site for free
See how your site measures up against WCAG 2.2 and EN 301 549 - in 30 seconds, no signup required.
Frequently asked questions
Does Optimizely have built-in accessibility checking?
Optimizely CMS does not include built-in WCAG validation for published content. Some Optimizely partners offer add-ons for content accessibility checking, but comprehensive validation requires external scanning against the rendered output.
How do A/B tests affect accessibility compliance?
Each A/B test variant is a distinct user experience that must meet WCAG 2.2 AA independently. If a test variant changes visual design, layout, or content, it needs accessibility validation - even if it's only shown to a percentage of users.
Does the EAA apply to Optimizely experimentation?
Yes. The EAA requires the digital service to be accessible for all users. Experiment variants served to EU consumers must meet EN 301 549, regardless of whether they're the 'control' or 'test' version. Non-compliant variants expose you to the same liability as non-compliant pages.
Can I integrate accessibility testing into Optimizely workflows?
Yes - the most effective approach is scanning each experiment variant before activation and monitoring published content continuously. This catches issues before they reach users and prevents non-compliant experiments from going live.
Related resources
Last reviewed: April 2026. Content is reviewed quarterly for accuracy.