Optimizely CMS Accessibility Checklist 2026 | Episerver WCAG 2.1 AA
Last updated: 2026-07-30
Optimizely CMS, which most teams still call Episerver, sits behind a particular kind of website: large corporate, financial services, manufacturing, healthcare, and public sector properties running on .NET, usually with a dedicated development partner, a design system, and a marketing team publishing daily. That profile changes where accessibility problems come from. Unlike a hosted website builder, almost nothing here is decided by the platform. The markup that reaches a visitor comes from block templates your own developers or an agency wrote, so accessibility is a property of your codebase and your component library rather than a vendor's roadmap. The authoring model compounds this. Editors assemble pages by dropping blocks into content areas, which means heading order, landmark structure, and reading sequence are emergent results of composition, not fixed page templates a developer verified once. A block that renders a Heading 2 is correct in one slot and wrong in another, and no editor can see the difference. Optimizely's experimentation and personalization capabilities add a dimension most CMS checklists ignore: the page a visitor actually receives may be a variant that no one audited, since accessibility review typically happens on the control version. The legal picture is usually serious for organizations on this platform. European operations fall under the European Accessibility Act, which since June 2025 has applied to e-commerce, banking, transport, and other in-scope services, and EU public sector bodies additionally carry the Web Accessibility Directive and its EN 301 549 requirements. US-facing enterprises face ADA Title III exposure and, when selling to government, VPAT requests during procurement. This checklist focuses on the block, template, and experiment layers where enterprise Optimizely failures actually concentrate.
Common Accessibility Issues
Every visible component on an Optimizely site is a block template written by your team or your agency, and accessibility defects there replicate across every page that uses the block. The recurring patterns are clickable div and span wrappers standing in for links and buttons, card components where the entire tile is wrapped in an anchor containing an image with no alternative text, accordions and tabs built with JavaScript toggles carrying no ARIA state, icon-only controls with no accessible name, and generic div soup where a list, table, or nav element belongs. Because a single hero or card block may appear on hundreds of pages, one defective template produces most of an audit's findings.
Fix accessibility in the block library rather than page by page, since a corrected template propagates automatically to every page that renders it. Use native elements first: anchor tags for navigation, button elements for actions, real list markup for repeated items, and table markup with scope attributes for tabular data. Give every block that composes an accessible name a required editor property rather than leaving it optional, so an unlabeled control cannot be published. Add keyboard and screen reader checks to the definition of done for new blocks, and run an automated scan against a page composed of every block in the library, which catches template-level defects in one pass instead of one page at a time.
Editors build pages by dragging blocks into content areas, and each block renders whatever heading level its template hard-codes. The result is pages with several Heading 1 elements because three hero blocks were stacked, sections that jump from Heading 2 to Heading 4, and long pages whose outline bears no relationship to their visual structure. Screen reader users navigate long enterprise pages by heading, so a scrambled outline turns a scannable page into a linear read, and it is invisible to the editor who assembled it because the visual design looks perfectly ordered.
Give heading-bearing blocks an editor-selectable heading level property with a sensible default, so an editor placing a block into a subsection can set the correct level without touching code, and document in the block description which level to choose. Where the design system allows, decouple visual size from semantic level so an editor can pick a Heading 3 that still renders large. Reserve the page Heading 1 for the page template rather than any block, preventing duplicates by construction. Add a heading-outline check to editorial review for new landing pages, and use a browser extension that lists the document outline, since it exposes the problem in seconds.
Optimizely's core value proposition is testing and personalizing what visitors see, and accessibility review almost always happens on the control experience. Variants introduce untested contrast changes, new overlays and interstitials, autoplaying media, urgency banners, and rewritten calls to action that lose their accessible names. Personalized blocks swap content based on segment, so an audit of the page as an anonymous visitor never renders what a logged-in customer receives. The site can pass an audit while a majority of real traffic sees an unaudited variant.
Treat every variant as a publishable page requiring the same review as the control, and add a contrast and keyboard check to the experiment launch checklist rather than the post-analysis phase. Constrain variants to design-system tokens so a marketer cannot introduce a failing color pair by hand. Audit personalized experiences by impersonating each major segment or visitor group instead of testing only the default view, and confirm that swapped blocks retain accessible names and heading levels. Pay particular attention to interstitials and urgency mechanics introduced only in variants, since modals and countdowns are among the most common sources of keyboard traps and unannounced dynamic content.
Optimizely Forms is used for the high-value conversions on these sites, including quote requests, demo bookings, dealer and branch contact, and support intake. Designers frequently ask for a clean look, so labels are removed and placeholder text carries the field name. Placeholders disappear on typing, are often too low contrast to read, and are inconsistently exposed by assistive technology, so a user who is interrupted mid-form no longer knows what a field is. The same forms often mark errors with red borders alone and never move focus or announce anything when validation fails, so a screen reader user submits, hears nothing, and cannot tell what went wrong.
Require a persistent visible label on every field, positioned above the input where it survives zoom and reflow, and treat placeholder text as an optional format hint rather than a substitute. Associate labels programmatically with their inputs and expose required state through markup instead of relying on an asterisk convention. On validation failure, move focus to a summary that lists each problem as a link to the offending field, describe the error in text next to the field, and never signal the error with color alone. Set appropriate autocomplete attributes on name, email, phone, and address fields so browser and assistive technology autofill works, which meaningfully reduces effort for users with motor and cognitive disabilities.
Enterprise sites on Optimizely run on a corporate design system whose palette was approved by a brand team on aesthetic grounds. The recurring failures are light gray body and metadata text, brand-colored link text and button labels below threshold against their backgrounds, disabled and secondary button states that are unreadable, text placed over photographic heroes with no scrim, and status or validation meaning conveyed by color alone. Because these values live in shared design tokens, a single failing token reproduces across the entire site and every experiment variant derived from it.
Audit the design system tokens rather than individual pages, validating every text and background combination against 4.5 to 1 for normal text and 3 to 1 for large text, and checking interactive component boundaries and focus indicators against 3 to 1. Darken brand variants intended for text and controls while leaving decorative brand usage alone, which preserves the brand without failing the requirement. Add a solid or gradient overlay behind text over imagery so contrast holds regardless of the photograph an editor chooses. Confirm the design system did not suppress the browser focus outline, since custom component styling in these codebases frequently removes it, and pair every color-coded status with text or an icon.
Optimizely commonly serves many country and language sites from one installation, and the language declared on the rendered page frequently does not match its content. Typical symptoms are every locale inheriting the default site language, mixed-language pages where an untranslated block sits inside a translated page with no language marking, and language switchers implemented as unlabeled flag icons or as links whose text is only in the target language. A screen reader reads a French page with an English voice profile when the declaration is wrong, producing output that is close to unintelligible.
Verify the rendered language attribute for each site and locale rather than trusting the CMS configuration, and confirm regional variants declare the correct code. Mark inline passages that differ from the page language, which matters most for untranslated product names, legal text, and fallback blocks. Build the language switcher as a labeled control listing each language in its own language, ensuring it is reachable and operable by keyboard, and avoid flag icons as the only indicator since flags represent countries rather than languages. Where fallback content in another language renders inside a translated page, mark that block's language explicitly instead of letting it inherit.
Optimizely CMS (Episerver)-Specific Tips
- Fix accessibility in the block library, not on individual pages, because one corrected template propagates to every page that uses it.
- Build a hidden staging page containing every block in the library and scan it, which surfaces template-level defects in a single pass.
- Give heading-bearing blocks an editor-selectable heading level so composition cannot scramble the page outline.
- Add contrast and keyboard checks to the experiment launch checklist, since audits normally test only the control variant.
- Audit personalized pages while impersonating each visitor segment, not just as an anonymous visitor.
- Make an accessible name a required editor property on any block that renders a control, so unlabeled components cannot be published.
- Ask your implementation partner for an accessibility conformance report covering the block library specifically, not just the Optimizely product.
Recommended Tools
Optimizely Accessibility
Optimizely's accessibility documentation and conformance information for its CMS and experimentation products, useful for separating platform-level conformance from your own block library's.
axe DevTools
A browser extension for auditing rendered Optimizely pages and experiment variants, catching contrast failures, missing accessible names, and non-semantic interactive elements introduced by custom block templates.
WebAIM Contrast Checker
A quick way to validate the design system's color tokens against WCAG thresholds before those values propagate across every page and every experiment variant.
NVDA
A free Windows screen reader for verifying that custom blocks expose their role, name, and state, and that form validation and language declarations behave correctly across locales.
Frequently Asked Questions
Optimizely provides accessibility documentation for its platform. Does that cover our website?
No, and this is the most expensive misunderstanding on enterprise CMS projects. Optimizely's documentation covers the product: the editing interface, the delivery APIs, and the platform's own components. Nearly everything a visitor sees on your site is markup from block templates your development team or your agency wrote, styled with your design system. If a card block wraps a clickable div instead of an anchor, if a hero renders a second Heading 1, or if your brand token for link text sits below the contrast threshold, the platform's conformance report has nothing to say about it. Practically, this means procurement should request an accessibility conformance report for your implementation, not just for Optimizely, and that report should be based on testing the actual block library. When an audit finds forty issues on an Optimizely site, they usually trace back to five or six defective templates.
Do we need to audit every A/B test and personalized variant separately?
You need to review variants before launch, but the practical answer is to constrain them rather than audit each one. Requiring every variant to pass a manual audit does not survive contact with a marketing team running dozens of experiments a quarter. What works is limiting what a variant can change: restrict color choices to validated design tokens so a failing pair cannot be introduced by hand, reuse existing accessible components rather than allowing bespoke markup in variants, and require an explicit review only when a variant adds something structurally new, such as a modal, an interstitial, an autoplaying video, or a countdown. Those additions are where variant-specific failures cluster, because overlays and dynamic content are the hardest patterns to get right. Add a keyboard and contrast check to the experiment launch checklist for those cases, and audit personalized experiences by impersonating each major segment, since testing as an anonymous visitor never renders what most logged-in traffic receives.
Our site has thousands of pages. Where do we start?
Start with the block library, not the page inventory. Because every page is assembled from shared blocks, a defect in a card, hero, accordion, or form block appears on every page using it, and a fix propagates the same way. Build a hidden staging page that renders every block in the library, scan and manually test that single page, and you will have characterized the majority of your site's issues in a day. Fix the design system tokens next, since contrast failures live in shared values and reproduce everywhere including experiment variants. Then move to templates and global elements: header, footer, navigation, search, and the form components behind your highest-value conversions. Only after that does page-by-page review make sense, and at that point prioritize by traffic and by task, meaning checkout, account, quote request, support, and legally required disclosures come before marketing pages nobody visits.
Further Reading
Other CMS Checklists
- Sitecore Accessibility Checklist
- Adobe-experience-manager Accessibility Checklist
- Kentico Accessibility Checklist
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.