The editor was silent to screen readers Fixed
There was no aria-live region anywhere — not in the host page, not in the editing iframe. Every outcome a sighted user reads off the chrome was announced to nobody: how many matches a search found, what the paste filter stripped, hitting the character limit, going read-only. That is WCAG 4.1.3 Status Messages, Level AA, on a product that publishes an accessibility conformance page.
This release adds polite and assertive live regions (aria-atomic, role="status" and role="alert") and a public editor.announce(text, { assertive }) so your own integration can report its outcomes too.
The regions are hidden with clip rather than display:none or visibility:hidden. Both of those remove a node from the accessibility tree, which would silence the very thing being added.
Read-only mode was invisible to assistive technology Fixed
setReadOnly() flips designMode, which genuinely blocks editing. The toolbar marked its buttons aria-disabled, but the editing region itself said nothing — so a screen reader user typed into a field described as a rich text editor, got no response, and no explanation of why.
The editing region now carries aria-readonly and says so in its accessible name, and the change is announced when it happens.
Accessibility checker: 6 rules to 8 New
New table-header-empty (a <th> with no accessible name in a data table) and link-empty (an <a href> with no accessible name). Both ship with repairs.
The empty corner cell of a cross-tab is deliberately exempt. It names neither axis, so flagging it would raise an error the author could only clear by inventing a word — and an unsatisfiable rule is worse than a missing one.
Dialog fields, .docx round trip Fixed
Dialog labelling reached the Find & Replace and Insert Link panels, whose fields were announced as a bare “edit”. Field names now come from the visible label text, so speech input matches what a user can actually see.
Import and export fidelity work in documentimport.js and docxexport.js.