/Docs

Accessibility

Every edit you save in the Visual Editor is scanned by axe-core. Issues surface as inline findings in the panel so you can fix them before publishing — but findings are warnings only and never block you from shipping.

Rule families

The editor runs a focused subset 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 (e.g. 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 influences how prominently the finding is displayed but 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.
What you'll see
After every save, the panel reveals an Accessibility tab with a count badge. Each finding shows the rule name, severity chip (red for critical, orange for serious, yellow for moderate, grey for minor), 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 a11y 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 with open findings at any time — the dashboard simply surfaces a summary so your team has full context.

Customer-site rules still apply
We scan the change list. Your customers' own a11y 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.

Org-wide summary

Findings roll up into the Accessibility tab of your organisation dashboard. There you can see the total open findings per experiment, severity breakdown, and which rule fires most often across the org. The summary is read-only and intended for accessibility leads or audit reviewers.

  • Troubleshooting — what to do if findings disagree between the editor and a third-party scanner.
  • Review and publish — where the a11y summary appears in the publish flow.