Accessibility

Every edit you save in the Visual Editor is scanned by axe-core, a widely used accessibility-testing tool. Issues surface as inline findings in the panel, so you can fix them before publishing. Findings are warnings only. They never block you from shipping.

Rule families

The editor runs a focused set of axe rules, tuned for the kinds of changes people make in a visual editor. Each family covers one common type of regression.

color-contrast: Foreground and background colours fail to meet WCAG AA contrast ratios. Most common when editing text or background colours. Axe docs.
image-alt: An img is missing an alt attribute. Often triggered when swapping out a hero image without updating the description. Axe docs.
button-name: A button has no accessible name. Triggered by icon-only buttons that lack aria-label or visually-hidden text. Axe docs.
link-name: An a has no accessible name. Same problem as button-name but for links. Axe docs.
heading-order: Heading levels jump, for example an h2 directly under an h4. Easy to introduce when restructuring a page section. Axe docs.

Severity levels

Each finding is tagged with one of axe-core's four standard severities. Severity changes how prominently the finding is displayed. It does not block publishing.

critical: Blocks users from completing core tasks. Failing colour contrast on a primary CTA is the canonical example.
serious: Significant impact on a user's ability to use the page. Missing form labels, unlabelled buttons.
moderate: Causes confusion but not blocking. Misordered headings, low contrast on secondary text.
minor: Best-practice violations that rarely affect day-to-day use. Surfaced for completeness.

After every save, the panel reveals an Accessibility tab with a count badge per severity group. Each finding shows the rule name and a severity chip: red for critical, orange for serious, blue for moderate, grey for minor. It also shows the element it relates to, a short description, and a View axe rule link that opens the full documentation.

Findings never block publish

A vs B treats accessibility findings as guidance, not gates. Many tests intentionally use bold visual treatments that fail one rule or another for a short experimental run. You can publish a variation (a version of the page you're testing) with open findings at any time. Nothing in the publish flow checks them first.

We scan the change list. Your customers' own accessibility obligations (WCAG conformance commitments, legal requirements, brand standards) are not relaxed by A vs B publishing a variation. Treat critical findings as you would in production code.

Live re-scan after each edit

Every time you save a change to the selected element, the editor re-scans it and shows a delta. It waits half a second after your last edit before scanning, so a burst of quick changes doesn't trigger a scan for each one. For example, you might see:

"This edit introduced 1 contrast issue"
"This edit resolved 1 missing alt text finding"
"No new accessibility findings"

This way you catch regressions as you author, not only on a full-page scan at the end. The Accessibility tab stays in sync with your live edits, including when you're previewing a mobile or tablet layout: the scan always checks the actual page in your canvas, at whatever size you're viewing it.

Saved findings also appear outside the editor: on the experiment's Review step, inside the visual-changes dialog, so anyone checking a variation before launch can see the same accessibility findings without opening the editor.

The findings you see live, in the panel while you work, are accurate. But right now, the findings A vs B saves with your change (and so what shows on the Review step above) are checked against a separate copy of the page, not the one in your editing canvas. If your edit just introduced or fixed an issue, the live panel reflects that correctly; the saved copy may not yet. Trust what the panel shows you while editing over anything saved.

One-click fixes at the point of edit

When a finding affects the element you're currently editing, it also surfaces in the Inspector (right panel), not only in the left Accessibility tab. This puts the issue and the fix right where you're working.

Colour contrast fix

When colour contrast fails the WCAG AA threshold, the editor computes the nearest compliant colour and offers it as a suggestion. WCAG AA requires:

4.5:1 contrast for normal text. That means anything smaller than 24 pixels, or smaller than about 18.7 pixels when bold.
3:1 contrast for large text. That means 24 pixels and up, or about 18.7 pixels and up when bold.

If you click to accept the suggestion, the colour is staged as a normal, editable style change. It's never auto-applied, and you can tweak it further to match your brand.

Missing image alt text fix

When an img is missing an alt attribute, a one-click fix jumps focus straight to the alt-text input field, so you can type a description immediately.

All fixes are suggestions you review and apply. The editor never changes your styles or content automatically. You stay in control, and can tweak the suggested colour or skip the fix entirely.

Custom code: escape hatch for variation logic that the visual tools don't cover.
Troubleshooting: what to do if findings disagree between the editor and a third-party scanner.