Spike: accessibility validator for the Block Editor (WCAG / Section 508), parity with the TinyMCE WYSIWYG checker

Research Question

How should we provide an on-demand accessibility checker inside the new Block Editor — equivalent to the TinyMCE WYSIWYG's "AChecker Validation" — that lets an author validate their content against a chosen guideline set (WCAG 2.0 A/AA/AAA, Section 508, etc.) and reports the violations to fix?

The legacy TinyMCE editor exposes a toolbar checkmark with a dropdown of rulesets (BITV 1.0, Section 508, Stanca Act, WCAG 1.0/2.0 A/AA/AAA). The new Block Editor has no equivalent — there is no way to validate content for accessibility from within the editor.

Key unknowns to resolve:

1. Engine / approach. The legacy "AChecker" is an aging external service. What's the right modern foundation — axe-core (de-facto standard, actively maintained), a hosted service, or a custom ruleset? Build vs. integrate.
2. What gets validated. The Block Editor stores ProseMirror JSON, not HTML. Do we validate the rendered HTML (getHTML() / headless render) or map rules onto the JSON model? Where does validation run — client-side in the Angular editor, or server-side?
3. Ruleset scope. Which guideline sets do we actually need to support for customer/compliance parity (WCAG 2.x AA is the common bar; do we still need Section 508 / BITV / Stanca explicitly)?
4. UX. How are results surfaced — a panel, inline markers on offending blocks, a modal report? How does this relate to the inline a11y-metadata indicators tracked in #36050?

Timebox

8h

Acceptance Criteria

• Document the recommended approach (engine, where validation runs, JSON-vs-HTML) with pros/cons of at least two options (e.g. axe-core client-side vs. a service-based checker).
• Define the ruleset scope we should support for parity, with a recommendation (and what to drop from the legacy AChecker list).
• Sketch the results UX and how it complements #36050's inline indicators (avoid overlap/duplication).
• Identify whether this is primarily front-end or full-stack, and rough-size the implementation follow-up task(s).
• Proof of concept if feasible within the timebox (e.g. axe-core run against an exported Block Editor document).

Context

Split out from #36050, which was originally scoped to a single symptom (table accessibility metadata having no visual indicator). #36050 is being generalized to cover surfacing a11y metadata across all block types; validating content against accessibility guidelines is a distinct, larger capability and is tracked here.

Customer accessibility/compliance requirements (WCAG, Section 508) are a recurring theme, and losing the TinyMCE checker on the move to the Block Editor is a parity gap.

Links

• Generalized inline-indicator ticket: #36050
• Block Editor parity epic: #35262
• Legacy reference: TinyMCE "AChecker Validation" toolbar control (WCAG 2.0 A/AA/AAA, Section 508, BITV, Stanca Act)
• Candidate engine: axe-core (https://github.com/dequelabs/axe-core)

Start by comparing the legacy TinyMCE AChecker Validation behavior with the Block Editor context described here, including axe-core as a candidate. Evaluate client-side versus service-based validation, rendered HTML versus ProseMirror JSON, ruleset scope, and the relationship to #36050; done means a documented recommendation, UX sketch, follow-up sizing, and a feasible proof of concept if time permits.