Verify our claims in your browser
Every vendor’s accessibility statement and security page is prose. This page runs the checks instead. It builds a real editor below, exercises it, and reports what actually happened — in your browser, on your platform, right now.
Each check names the criterion it corresponds to, so you can match it against our conformance report and accessibility statement. If something fails here, those pages are wrong and we would like to know.
What this is and is not.It is a reproducible check of specific, mechanical properties — the ones a machine can settle. It is not a substitute for an audit, and passing it does not mean the editor is fully WCAG 2.2 AA conformant. Judgement criteria (is this alt text meaningful? is the reading order sensible for this document?) cannot be automated and are not claimed here. Our independent audit and formal VPAT remain open requirements.
Accessibility
WCAG 2.1.2 (A)not runEscape moves focus out of the editor to the toolbar. Without a way out, a keyboard user is trapped until they reload the page.
WCAG 3.3.2not runThe escape route appears in the editing area's accessible name, so a screen reader states it on entry rather than leaving the user to guess.
WCAG 2.4.3not runThe ARIA toolbar pattern: Tab enters once, arrow keys move between buttons. Dozens of tab stops is operable in theory and unusable in practice.
ARIA APGnot runSetting role=toolbar without implementing the behaviour promises a screen reader user navigation that does not exist.
WCAG 4.1.2 (A)not runBold, italic and underline expose aria-pressed, so assistive technology can report what formatting is active.
WCAG 4.1.2 (A)not runButtons that open menus carry aria-expanded.
WCAG 4.1.2 (A)not runrole=textbox with an accessible name, so the region is announced rather than presented as an unlabelled frame.
Security
Stored XSSnot runA battery of payloads is loaded, the editor's saved HTML is taken, and that string is rendered in a sandboxed frame where scripts CAN run. Nothing should fire.
Transient XSSnot runiframe srcdoc executes the moment it is inserted. Cleaning up afterwards is too late, so dangerous clipboard HTML must be filtered before insertion.
Stored XSSnot runsrcdoc carries an entire document inside an attribute — no handler, no javascript: URL, nothing for a naive filter to notice.
URL schemenot runBrowsers strip control characters before parsing a scheme, so java	script: is live unless the check strips first.
CSS injectionnot runFiltering per declaration rather than by editing the string — and keeping the author's real formatting.
Reverse tabnabbingnot runOtherwise the destination page receives a handle to the opener window.
Collaborator XSSnot runA CRDT sync engine writes remote edits straight into the live document — it does not go through paste or setHTMLCode. An editor that only filters those two entry points lets any participant run script in everyone else's browser.
Why we publish this
Because we got it wrong. Our accessibility statement previously said “users can always Esc out or Tab past the editor” and that toggle buttons exposed aria-pressed. Neither was true — the statement had been written from intent rather than from behaviour, and nothing connected the two. We found a WCAG Level A keyboard trap that had shipped for years, and separately a stored-XSS hole where an iframe srcdoc survived into saved content and executed downstream.
Both are fixed. But the deeper problem was that a claim and the code had no connection, so we built one: the comparison page is bound to shipped symbols by a build-failing test, and the behaviours are checkable here, by you, without asking us. A claim you can run is worth more than a claim you have to believe.
The method behind these checks is written up in auditing an editor for accessibility in an afternoon and “nothing executes in the editor” is the wrong bar. Both work against any editor, not just ours.