diff --git a/.github/actions/e2e-tests/action.yml b/.github/actions/e2e-tests/action.yml
new file mode 100644
index 00000000..869ccb47
--- /dev/null
+++ b/.github/actions/e2e-tests/action.yml
@@ -0,0 +1,61 @@
+name: "E2E tests"
+inputs:
+  package-name:
+    description: 'Name of the package'
+    required: true
+  working-directory:
+    description: 'Package working directory'
+    required: true
+runs:
+  using: "composite"
+  steps:
+    - name: Setup Node.js
+      uses: actions/setup-node@v6
+      with:
+        node-version-file: .nvmrc
+
+    - name: Setup environment
+      uses: ./.github/actions/setup
+
+    # Each Playwright release pins its own browser builds, so the installed version is all the
+    # cache key needs. Keying by the lockfile would drop the ~400MB of browsers on any unrelated
+    # dependency bump.
+    - name: Resolve Playwright version
+      id: playwright-version
+      shell: bash
+      run: echo "version=$(yarn workspace ${{ inputs.package-name }} exec playwright --version | awk '{ print $2 }')" >> "$GITHUB_OUTPUT"
+
+    # Cached separately from the yarn cache. No restore-keys on purpose: restoring another
+    # version's browsers would only have them cached again next to the ones actually used.
+    - name: Restore Playwright browsers
+      uses: actions/cache@v5
+      id: playwright-cache
+      with:
+        path: ~/.cache/ms-playwright
+        key: ${{ runner.os }}-playwright-${{ steps.playwright-version.outputs.version }}
+
+    # `--with-deps` is what makes webkit runnable on a bare ubuntu runner. Re-run without the
+    # browser download on a cache hit, since the system libraries are not part of the cache.
+    - name: Install Playwright browsers
+      shell: bash
+      run: |
+        if [ "${{ steps.playwright-cache.outputs.cache-hit }}" = "true" ]; then
+          yarn workspace ${{ inputs.package-name }} exec playwright install-deps chromium webkit
+        else
+          yarn workspace ${{ inputs.package-name }} exec playwright install --with-deps chromium webkit
+        fi
+
+    # The suite's own webServer command builds the workspace dependencies first — the fixture
+    # reaches @editorjs/ui and the tools through their `dist`, so an unbuilt change is invisible
+    # to it. See packages/editorjs/e2e/README.md.
+    - name: Run e2e tests
+      shell: bash
+      run: yarn workspace ${{ inputs.package-name }} run test:e2e
+
+    - name: Upload Playwright report
+      if: ${{ !cancelled() }}
+      uses: actions/upload-artifact@v7
+      with:
+        name: playwright-report
+        path: ${{ inputs.working-directory }}/playwright-report/
+        retention-days: 7
diff --git a/.github/workflows/editorjs.yml b/.github/workflows/editorjs.yml
index 8fa65bf7..bf423d72 100644
--- a/.github/workflows/editorjs.yml
+++ b/.github/workflows/editorjs.yml
@@ -16,5 +16,9 @@ jobs:
       package-name: '@editorjs/editorjs'
       working-directory: './packages/editorjs'
       include-mutations: false
+      # The ARIA semantics this package's UI depends on are only enforced by the Playwright
+      # suite — nothing in the type surface catches a dropped role or accessible name.
+      # `voiceover.spec.ts` stays out of it: screen readers can't run headless or in parallel.
+      include-e2e: true
     secrets:
       stryker_dashboard_api_key: ${{ secrets.STRYKER_DASHBOARD_API_KEY }}
diff --git a/.github/workflows/package-check.yml b/.github/workflows/package-check.yml
index 0c5be432..ff4c650b 100644
--- a/.github/workflows/package-check.yml
+++ b/.github/workflows/package-check.yml
@@ -15,6 +15,11 @@ on:
         required: false
         type: boolean
         default: false
+      include-e2e:
+        description: 'Whether to run the package Playwright e2e suite'
+        required: false
+        type: boolean
+        default: false
     secrets:
       stryker_dashboard_api_key:
         description: 'Stryker dashboard API key for mutation tests'
@@ -86,6 +91,21 @@ jobs:
         with:
           package-name: ${{ inputs.package-name }}
 
+  # Kept out of the `tests` job: it needs browsers installed and takes minutes rather than
+  # seconds, and its failures are read differently from a unit-test failure.
+  e2e-tests:
+    needs: should-run
+    if: ${{ inputs.include-e2e && needs.should-run.outputs.run == 'true' }}
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Run e2e tests
+        uses: ./.github/actions/e2e-tests
+        with:
+          package-name: ${{ inputs.package-name }}
+          working-directory: ${{ inputs.working-directory }}
+
   mutation-tests:
     needs: should-run
     if: ${{ inputs.include-mutations && needs.should-run.outputs.run == 'true' }}
diff --git a/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/.openspec.yaml b/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/.openspec.yaml
new file mode 100644
index 00000000..5e6d53a3
--- /dev/null
+++ b/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-07-24
diff --git a/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/design.md b/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/design.md
new file mode 100644
index 00000000..7d012433
--- /dev/null
+++ b/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/design.md
@@ -0,0 +1,69 @@
+## Context
+
+`@editorjs/ui` renders the editor shell as plain `<div>`s wired together via `EventBus` events (`ui:*:rendered`, `core:*`); see `openspec/specs/ui/spec.md`. None of `EditorjsUI`, `BlocksUI`, `ToolbarUI`, `InlineToolbarUI`, or `ToolboxUI` currently set any `role` or `aria-*` attribute. The paragraph block (`packages/tools/paragraph`) renders a bare contenteditable `<div>` with no accessible name.
+
+The inline toolbar's popover (bold/italic/link buttons) is not rendered by `ui` directly — `InlineToolbarUI` builds a `PopoverInline` from `@editorjs/ui-kit` (external npm dependency, pinned `^1.1.5`, source is vendored into `node_modules` but not part of this workspace and not editable here). Inspecting `node_modules/@editorjs/ui-kit/src/popover/components/popover-item/popover-item-default/popover-item-default.ts`:
+- Item construction (`make()`) sets no `role`/`aria-*` attributes; `params.title` only renders a visible text `<div class="title">`, and only when the popover isn't in icon-only/hint mode.
+- `renderParams?.wrapperTag` can be `'button'` (falls back to `'div'`), giving native button semantics for free if the caller opts in.
+- `PopoverItemDefault.getElement(): HTMLElement | null` is a **public** method returning the item's root node — so a caller can reach in and set additional attributes post-render without modifying `ui-kit` itself.
+
+Each inline tool (`BoldInlineTool`, `ItalicInlineTool`, `LinkInlineTool`) already carries a human-readable `options.title` (e.g. `'Bold'`) via `getToolbarConfig()`, unused for accessibility today.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Every interactive control rendered by `@editorjs/ui` (toolbar plus-button, toolbox items, inline-toolbar popover items) has an accessible name and, where applicable, pressed/expanded state.
+- The editable surface (blocks holder, individual blocks, paragraph's contenteditable) is identifiable and navigable by assistive tech.
+- All of this is achieved without modifying `@editorjs/ui-kit` source — only via its existing public API (`render params`, `getElement()`).
+
+**Non-Goals:**
+- Full WCAG conformance audit or keyboard-navigation rework (e.g. arrow-key roving tabindex across blocks) — this change is about semantics (roles/names/state), not new interaction patterns. Keyboard nav gaps found along the way get filed as follow-ups, not fixed here.
+- Changes to `@editorjs/ui-kit`'s own source/behavior. If its API can't carry a given semantic, that's documented as a limitation (see Risks), not patched upstream as part of this change.
+- Localization/i18n of accessible names — names are sourced from existing English strings (tool `options.title`, etc.) as-is.
+
+## Decisions
+
+- **Blocks holder role**: give `BlocksUI`'s holder `role="group"` (a structural container), not `role="textbox"`. Originally planned as `role="textbox"` + `aria-multiline="true"` on the holder — but `.ejs-blocks` (the holder) is itself `contenteditable`, and so is each block inside it (confirmed in `packages/editorjs/e2e/README.md`). A bare contenteditable element gets an *implicit* `role="textbox"` per the HTML-AAM mapping regardless of what we set explicitly, so putting an explicit `role="textbox"` on the holder as well would nest one textbox inside another — an ARIA anti-pattern that can break screen reader forms-mode navigation. `role="group"` on the holder avoids that; ownership of `role="textbox"` moves to each block instead (next bullet). This is also more future-proof: once non-text block types (image, embed) exist, the holder can't honestly claim `role="textbox"` for all of them anyway.
+- **Per-block wrapper vs. contenteditable element**: the block *wrapper* (`.ejs-block`/`.ejs-block__contents`) stays role-less — it's structural, not focusable. The block's actual contenteditable element (e.g. paragraph's `<div contenteditable>`) gets an explicit `role="textbox"` + `aria-multiline="true"` (content can soft-wrap across multiple visual lines) + `aria-label`. This makes explicit the role the element already implicitly carries from being contenteditable, and puts the accessible name at the level AT actually focuses — consistent with how a native `<textarea>` is labeled directly, not via its container.
+- **Paragraph accessible name**: use a static `aria-label` (e.g. `"Paragraph"`) rather than `aria-labelledby` pointing at visible text, since paragraph blocks have no visible label element to point to. Placeholder/empty state (if any) uses `aria-placeholder`, mirroring the native `<textarea placeholder>` semantic AT already understands. Note this label is identical across every paragraph block in a document — it identifies the block *type*, not a unique per-instance name (see Open Questions).
+- **Toolbar role**: `role="toolbar"` on `ToolbarUI`'s actions container (standard for a row of related controls), plus `aria-label="Add block"` on the plus-button, which is icon-only and would otherwise be nameless.
+- **Popover-rendered surfaces (toolbox, inline toolbar items) were fixed upstream and are consumed here, not worked around.** The original plan was to apply attributes from the `@editorjs/ui` call sites — either through `ui-kit`'s render params or by reaching into rendered DOM. Investigation showed the render-params route doesn't exist for this purpose and the DOM route is unsound:
+  - `InlineToolbarUI` and `ToolboxUI` never construct `PopoverItemDefault` instances. They pass plain param objects to `PopoverInline`/`PopoverDesktop`, which build items internally and expose no accessor for them. There is no `getElement()` to call per item, so the plan's step 6.3 is not reachable as written.
+  - The only remaining hook is querying the popover's rendered markup (`[data-item-name]`, `.ce-popover__items`). That couples `@editorjs/ui` to another package's internal DOM, and `ui-kit` replaces item `innerHTML` wholesale on confirmation-mode toggles, so anything applied to item children is silently wiped.
+  - `ui-kit` is maintained by the same team, and the information needed (`title`, `isActive`, `toggle`, `isDisabled`) is *already* passed to it as params — it simply isn't rendered as ARIA. Fixing it there is a smaller change than the workaround, and fixes every ui-kit consumer at once.
+
+  The audit and the implementation brief were written for the `editorjs-utils` repo and live with the work they describe, not in this repo. Both were executed there and are released as `@editorjs/ui-kit` **2.0.0**, which this change consumes — see the Risks section for the publish status that gates it.
+- **Source of accessible names for inline tools**: names come from the existing `InlineTool.options.title` (already `'Bold'`, `'Italic'`, etc.), which `InlineToolbarUI` already forwards to ui-kit as the item's `hint.title`. ui-kit falls back to the hint title when an item renders icon-only, which is exactly the inline toolbar's case, so no call-site change and no new field on the `InlineTool`/`BlockTool` contracts in `@editorjs/sdk` were needed. Toolbox item names likewise come from the `toolbox.title` each block tool is registered with.
+- **What stays a consumer responsibility**: ui-kit can derive roles, names and states from params it already receives, but three things it cannot know:
+  - The accessible *name of the container* — whether a menu is "Add block" or something else is the consumer's vocabulary. Supplied via the `messages.label` param on both popovers.
+  - The relationship between the trigger and the menu — `aria-haspopup`/`aria-expanded` belong on `ToolbarUI`'s plus-button, which ui-kit never sees. Wired to the existing `ui:toolbox:opened`/`ui:toolbox:closed` events.
+  - Which element holds focus while the inline toolbar is navigated. `PopoverInline` deliberately keeps DOM focus in the text (WebKit drops the selection once focus moves to a button), so it can only emit `PopoverEvent.ActiveDescendantChanged`; only the consumer knows the editable to hang `aria-activedescendant` on. `InlineToolbarUI` takes `document.activeElement` at event time and remembers it, so the attribute is removed from the very element it was set on even if focus moved on since. It qualifies that element rather than accepting whatever holds focus: a target inside the toolbar itself, or outside this editor, yields no host at all and no attributes are written — see the next bullet but one.
+- **`aria-activedescendant` lands on the blocks holder, not the block.** The holder is the outermost `contenteditable`, so the browser keeps focus there and never on an individual block's editable element. Since `aria-activedescendant` is only honoured on the focused element, pointing it at the paragraph would be inert. `role="group"` supports the property, so this is valid — but it is a symptom of the nested-contenteditable structure noted in Risks, and would want revisiting if focus ever moves per-block.
+- **`aria-owns` is what makes that reference resolvable.** Putting `aria-activedescendant` on the right element is necessary but not sufficient: the attribute is only resolved when it names an element *inside the focused element's subtree*, or one claimed by it via `aria-owns`. `EditorjsUI` appends the inline toolbar and the blocks holder as **siblings** under the editor wrapper (`#addInlineToolbar`/`#addBlocks`), so the popover is never inside the holder, and the reference on its own points out of the focused subtree — where assistive tech drops it entirely. `InlineToolbarUI` therefore sets `aria-owns` naming the popover on the same element, in the same call that sets the reference, and removes both together. The alternative — moving the toolbar inside the blocks holder in the DOM — was rejected: the holder is `contenteditable`, so the toolbar would become editable content and part of what the caret and the model traverse. `aria-owns` re-parents in the accessibility tree only, which is exactly the scope of the problem.
+
+  This was a real defect, not a hypothetical: the first implementation set the reference alone. It was invisible to every layer of the test suite, because `aria.spec.ts` compared the attribute to the button's `id` (a string match that holds whether or not the reference resolves), axe never audited the navigated state, and axe does not check containment in any case. The e2e suite now asserts the resolved relationship rather than the attribute value, and audits the navigated state as a state of its own.
+
+  With `aria-owns` in place, a real VoiceOver run (Case 8) confirms the arrangement end to end: the highlighted tool is announced by name off the reference alone. Worth noting what the defect cost in the meantime — Case 8 had been recorded as a genuinely unknowable question about screen reader behavior, when the reference was invalid on DOM structure alone and checkable in any browser with no screen reader running. An open question is worth testing for the possibility that it is a bug in disguise.
+
+- **The reference is only ever claimed from inside this editor.** `aria-owns` and `aria-activedescendant` resolve by document-wide `getElementById`, so on a page with several editors both the popover id and the element the pair is written to have to be scoped per instance. The id is (tasks.md 10.5a); the *host* had been bounded only by the toolbar, which is not the same thing — any focused element outside the toolbar qualified, including one belonging to another editor. That is reachable today through the chromium scoping bug: the toolbar raised for a selection in the second editor is the *first* editor's, which would then claim its own popover from the second editor's holder. Writing nothing is the better failure of the two — assistive technology given no reference falls back on the document, whereas one given a wrong reference confidently describes controls that operate on someone else's content.
+- **A toolbar build that has been overtaken is discarded, not raced.** Building the popover awaits a `getToolbarConfig` per tool, so two selection changes can be in flight together and finish in either order. Ordering by *start* rather than by resolution is what keeps the visible toolbar tied to the current selection: each tool's `isActive` and `onActivate` close over the range its build began with, so a stale build that won the race would expose `aria-pressed` describing text the user has left, and act on that text when a button is pressed. Hiding the toolbar counts as overtaking too, so a build outstanding at dismissal cannot bring it back for a selection that no longer exists.
+
+## Risks / Trade-offs
+
+- **[Resolved]** `ui-kit` re-renders item content on `reset()`/confirmation-mode toggle (`popover-item-default.ts:131,206`), replacing `nodes.root.innerHTML` and wiping anything a consumer set on item children. This was originally to be mitigated by re-applying attributes on every popover rebuild. → **Resolved** by not applying consumer-side attributes at all: popover semantics move upstream (see Decisions), where they are set during `make()` and survive by construction.
+- **[Resolved]** The editor's popover surfaces were inaccessible until an upstream `ui-kit` release landed. → **Resolved** by `@editorjs/ui-kit` 2.0.0, which this change consumes; the toolbox and inline toolbar are now covered by e2e alongside the blocks holder, paragraph blocks and floating toolbar.
+- **[Blocking]** `@editorjs/ui-kit` 2.0.0 **is not on npm yet** — the latest published version is 1.1.5, while `packages/ui` and `packages/sdk` declare `^2.0.0`. The branch was developed against a root `resolutions` entry pointing the package at a `link:` path to a sibling `editorjs-utils` checkout; that entry and its `yarn.lock` locator have now been removed (tasks.md 5a.2), so nothing in the repo refers to anyone's local filesystem. The consequence is deliberate: `yarn install` now fails everywhere, including here, with `@editorjs/ui-kit@npm:^2.0.0: No candidates found`, and `yarn.lock` has no entry for the package at all — it cannot be written until the version exists. Publishing 2.0.0 is therefore the single remaining blocker, and the publish must include the `dist/e2e/**/*.d.ts` exclusion recorded in tasks.md 5a.1, without which consumers cannot type-check against the package. A branch that installs nowhere is a better state to review than one that installs on exactly one machine, but it does mean CI is red until the publish lands. Nothing else in this change can land ahead of it.
+- **[Risk]** `@editorjs/ui-kit` 2.0.0 is a *behavioral* major: popovers now move real DOM focus, wrap radio-style item groups in a `role="group"` element, and set `hidden` on filtered-out items. Nothing in its TypeScript surface changed, so a type check will not catch a regression. → **Mitigation**: the e2e suite exercises focus movement and keyboard activation for the toolbox, and asserts the text selection survives inline-toolbar navigation, which is the interaction the focus change could plausibly break.
+- **[Trade-off]** Some semantics (e.g. richer live-region announcements for collaboration cursors, or per-block landmark roles) are explicitly out of scope; this change closes the "zero ARIA" gap but doesn't claim full accessibility coverage. Flagged in Non-Goals so it isn't read as a completeness claim.
+- **[Resolved]** `role="textbox"` + `aria-multiline="true"` on a `contenteditable` element (now at the per-block level, see Decisions) is a widely-used pattern (e.g. many rich text editors) but AT support/behavior varies by screen reader, and the DOM-level assertions in `aria.spec.ts` can't confirm actual AT announcement quality. → **Resolved** by adding [Guidepup](https://www.guidepup.dev/) (`@guidepup/playwright`), which drives a real VoiceOver instance against Safari and exposes what it actually spoke as assertable strings — `e2e/tests/voiceover.spec.ts` covers all 18 cases in `voiceover-verification.md`, all asserting and all passing — there is no manual checklist left. Case 8 (arrow-key navigation via `aria-activedescendant`) was the last one open and is now **settled positively**: VoiceOver announces each highlighted tool by name off the reference alone ("Bold toggle button", then "Italic toggle button"), with DOM focus never leaving the text and the selection intact. It was brought in as a *measurement* first — asserting only what was already established and printing VoiceOver's output — so that its expected value came from observation rather than from a guess about screen reader behavior. Guidepup can't run headless or in CI (screen readers are singletons and need a real, headed session), so this is a separate, local-only suite (`playwright.voiceover.config.ts`, `yarn test:e2e:voiceover`) — it doesn't change the fact that this repo's e2e suite as a whole isn't wired into CI yet. Alongside it, `@axe-core/playwright` covers the complementary structural side (missing names, invalid roles, contrast) in `e2e/tests/axe.spec.ts`, cheap to run and does run under the existing chromium/webkit projects.
+- **[Risk]** Nested contenteditable regions: `.ejs-blocks` (the holder) and each block's contenteditable child are both native `contenteditable` elements, which HTML-AAM implicitly maps to `role="textbox"` regardless of any explicit role we set. An earlier draft of this design put `role="textbox"` on the holder, which would have produced a textbox nested inside a textbox — invalid ARIA, likely to confuse screen reader forms-mode navigation. → **Resolved** by moving `role="textbox"` ownership to each block and giving the holder `role="group"` instead (see Decisions). Flagged here since it's the kind of DOM-implicit-role interaction that's easy to reintroduce accidentally as new block types (also contenteditable) are added.
+
+## Migration Plan
+
+Purely additive DOM attribute changes — no data migration, no API version bump. Roll out as a single change; if a regression is found (e.g. a screen reader misbehaves with `role="textbox"` on the blocks holder), revert is a simple attribute removal with no state to unwind.
+
+## Open Questions
+
+- ~~Does `@editorjs/ui-kit`'s `PopoverInline`/`PopoverItemDefault` support `wrapperTag: 'button'` end-to-end today?~~ **Resolved by source inspection of the installed 1.1.5, no spike needed.** `PopoverInline`'s constructor (`popover-inline.ts:18-34`) *already* hardcodes `wrapperTag: 'button'` for `PopoverItemType.Default`, with a comment explaining it fixes a Safari focus-loss bug. Inline toolbar items are therefore already native `<button type="button">`. It also accepts only `(params: PopoverParams)` — no second `itemsRenderParams` argument — so passing render params from the call site is both impossible and unnecessary. `PopoverDesktop` (used by the toolbox) does accept the second argument but does not opt in, so toolbox items are still `<div>`s; that is covered in §1 of the upstream audit.
+- ~~Should toolbox items use `role="menuitem"` or `role="option"`?~~ **Resolved upstream**: ui-kit 2.0.0 derives `menuitem` (or `menuitemradio`/`menuitemcheckbox` when the item has a `toggle` param), and pairs it with a roving-tabindex focus model rather than `aria-activedescendant`. `option` remains available via the new `role` item param if a listbox-shaped consumer ever needs it.
+- `aria-label="Paragraph"` is identical across every paragraph block in a document — does that meaningfully help an AT user navigate between blocks, or just repeat "Paragraph, edit text" on every Tab/arrow move with no distinguishing information? Not blocking for this change since there's currently only one block type, but worth revisiting (e.g. via `aria-posinset`/`aria-setsize` on the wrapper, or richer per-instance context) before more block types land and per-block identity starts to matter more.
diff --git a/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/proposal.md b/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/proposal.md
new file mode 100644
index 00000000..fa471a55
--- /dev/null
+++ b/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/proposal.md
@@ -0,0 +1,36 @@
+## Why
+
+`@editorjs/ui` (the default rendering shell) and `packages/tools/paragraph` currently emit zero `aria-*` attributes or `role`s anywhere — confirmed by grepping `packages/ui/src`, `packages/tools/paragraph/src`, and the compiled `@editorjs/ui-kit` output. The editor is a contenteditable-based block editor with a floating toolbar, an inline formatting popover, and a toolbox, none of which expose any accessible name, role, or state. As a result the editor is effectively unusable with a screen reader today. This was surfaced while writing Playwright e2e tests for `packages/editorjs` (`packages/editorjs/e2e/README.md`), where the lack of ARIA semantics also meant tests had to fall back to CSS-class selectors instead of `getByRole`/`getByLabel`.
+
+## What Changes
+
+- Add a `role="group"` structural role to the blocks holder (`BlocksUI`), and `role="textbox"` + `aria-multiline="true"` + an accessible name to each block's contenteditable element (starting with the paragraph tool), so assistive tech announces the editor as a set of editable text regions and lets a user navigate between blocks.
+- Add an accessible name to the paragraph tool's contenteditable element (`packages/tools/paragraph`) via `aria-label`, plus `aria-placeholder` from the tool's configured `placeholder`, so the block's purpose and empty state are both announced — a contenteditable has no native `placeholder`, so an empty block would otherwise reach assistive tech as an unlabelled empty field.
+- Add `role="toolbar"` to `ToolbarUI`'s actions container and an accessible name to its plus-button, so the floating toolbar's controls are operable and announced. `ToolbarUI` also focuses the plus-button when it opens the toolbox, so that dismissing the toolbox returns focus there rather than dropping it (see the Safari bug under Impact).
+- **Popover-rendered surfaces get their semantics from `@editorjs/ui-kit`, which this change consumes.** The toolbox (`ToolboxUI`) and the inline toolbar's items (`InlineToolbarUI`) are both rendered by ui-kit, which used to emit zero `role`/`aria-*` and expose no ARIA params. Rather than reaching into its rendered DOM from here — fragile (ui-kit replaces item `innerHTML` on confirmation-mode toggles) and coupling `@editorjs/ui` to another package's internal markup — the semantics were implemented upstream (the audit and the implementation brief live in the `editorjs-utils` repo alongside the work they describe). `@editorjs/ui-kit` **2.0.0** now derives `menu`/`menuitem`/`button` roles, accessible names, `aria-pressed`/`aria-checked` and a real roving-tabindex focus model from params the editor already passes it.
+- Consume that release: bump `@editorjs/ui-kit` to `^2.0.0` and wire up the parts only the consumer can supply — an accessible name for the toolbox menu and for the inline toolbar (`messages.label`), `aria-haspopup`/`aria-expanded` on the plus-button that controls the toolbox, and `aria-activedescendant` mirroring for the inline toolbar, which deliberately never takes DOM focus so the text selection survives — paired with `aria-owns`, without which the reference names an element outside the focused subtree and assistive tech ignores it (see design.md).
+- No changes to the OT/collaboration protocol, the model, or any public `@editorjs/sdk` tool-authoring contracts — this is additive DOM/attribute work in the rendering layer.
+
+## Capabilities
+
+### New Capabilities
+(none — this change adds requirements to existing capabilities, it doesn't introduce a new one)
+
+### Modified Capabilities
+- `ui`: `BlocksUI` and `ToolbarUI` gain requirements to render accessible roles and names on their DOM output. `ToolboxUI` and `InlineToolbarUI` gain requirements to name the menu/toolbar their popovers render, and `InlineToolbarUI` additionally to mirror the keyboard-highlighted item onto `aria-activedescendant`.
+- `tools`: `Paragraph` gains a requirement to expose an accessible name on its contenteditable element.
+
+## Impact
+
+- Affected code: `packages/ui/src/Blocks/Blocks.ts`, `packages/ui/src/Toolbar/Toolbar.ts`, `packages/ui/src/Toolbox/Toolbox.ts`, `packages/ui/src/InlineToolbar/InlineToolbar.ts`, `packages/tools/paragraph/src/index.ts`. Additive attributes plus the `aria-activedescendant` wiring and the plus-button focus move.
+- Dependency bump: `@editorjs/ui-kit` `^1.1.5` → `^2.0.0` in `packages/ui` and `packages/sdk`. The major is behavioral, not a type-surface break — real focus movement inside popovers, a `role="group"` wrapper around radio-style item groups, and a `hidden` attribute on filtered-out items.
+- **Blocked on publishing that dependency.** 2.0.0 is not on npm (1.1.5 is the latest). The `resolutions` entry that linked `@editorjs/ui-kit` to a local `editorjs-utils` checkout during development has been removed, along with its `yarn.lock` locator, so the branch no longer installs anywhere — `yarn install` fails with `No candidates found` and CI is red until the publish lands. That is intentional: a branch that installs on exactly one machine is harder to review than one that plainly does not install yet. See the first Risks entry in design.md.
+- Bug fixed along the way: `InlineToolbarUI` appended a fresh popover element per render without removing the previous one, so two overlapping selection changes left an orphaned popover in the DOM. It now removes the previous popover element and appends the new one, keeping exactly one — otherwise the same tool buttons could surface twice in the accessibility tree.
+- Bug found by the focus-destination tests (D in the case list below): in Safari, dismissing the toolbox dropped DOM focus onto `<body>`, so a keyboard or screen-reader user lost their place in the editor entirely — on Escape and after inserting a block alike. Safari does not focus a `<button>` when it is clicked, so the popover captured `document.body` as the element to restore focus to when it closed. `ToolbarUI` now focuses the plus-button as it opens the toolbox, which both fixes the restore and matches the WAI-ARIA menu button pattern. Chromium was unaffected, which is why only the webkit e2e target caught it.
+- Bug introduced by this change and caught by the VoiceOver suite: the roving tabindex added to the block actions toolbar handled `ArrowLeft`/`ArrowRight` with any modifiers held and called `preventDefault()` on them — but VoiceOver moves its cursor with VO+Right and VO+Left, which reach the page as `Control`+`Option`+arrow. Since Safari focuses a control when the VoiceOver cursor lands on it, a user whose cursor reached the plus button could not move off it again. `ToolbarUI` now ignores modified arrows entirely. The accessibility tree was correct the whole time and the keyboard was not, which is a distinction only a real screen-reader run makes — seven of the seventeen VoiceOver cases failed on it simultaneously, having passed 16 of 17 on the same code the run before.
+- Known gap, recorded rather than fixed here: no UI plugin's `destroy()` is ever called. Each of `InlineToolbarUI`, `ToolbarUI` and `ToolboxUI` declares one, but `Core` and `EditorJS` expose no `destroy()` and nothing invokes them, so the teardown this change corrected — hiding before detaching the holder, cancelling the pending announcement, dropping the popover's document-level listeners — is currently unreachable. It is correct and it becomes load-bearing as soon as an editor can be unmounted. Giving the editor a lifecycle is its own change.
+- Known gap, recorded rather than fixed here: inserting a block from the toolbox returns focus to the plus-button rather than putting the caret in the block that was just inserted. That is the pre-existing `focus: true` `@todo` in `ToolboxUI#addTool`; the tests assert only that focus is not lost.
+- Hardening noticed while automating Case 7: the first version of that fix used `holder.replaceChildren(popover, liveRegion)`, which detached and re-inserted the live region on every render — immediately before announcing into it. A live region should already be in the accessibility tree when its text changes, or assistive tech may not treat the change as an update at all. Only the popover is swapped now, leaving the region mounted from construction. This was not observed failing against VoiceOver — it's a fix on ARIA-practice grounds.
+- Test impact: verified by Playwright e2e in `packages/editorjs/e2e` rather than unit tests — neither `@editorjs/ui` nor `@editorjs/paragraph` has any test infrastructure today (no jest config, no `test` script, no specs), and the real browser accessibility tree is a stronger check for ARIA than a jsdom approximation would be. `e2e/tests/aria.spec.ts` covers all four surfaces; `editor.spec.ts` is fully migrated to `getByRole`. The fixture mounts one paragraph per `text` search param, so cases that need a multi-block or an empty document remount with e.g. `?text=Alpha&text=Beta`; with no param it stays the single `Hello world` block every earlier test was written against.
+- Test tooling added: `@axe-core/playwright` for static WCAG-rule audits (`e2e/tests/axe.spec.ts`, runs alongside the rest of `test:e2e`) and `@guidepup/playwright`/`@guidepup/guidepup` to drive a real VoiceOver instance and assert on what it actually announces (`e2e/tests/voiceover.spec.ts`, its own `playwright.voiceover.config.ts` and `yarn test:e2e:voiceover` script — macOS-only, headed, not part of `test:e2e` or CI). Together they bring the whole `voiceover-verification.md` checklist under `yarn test:e2e:voiceover` — all 18 cases automated, run and passing, with nothing left manual. Case 8 settled the change's longest-open question positively: VoiceOver does follow `aria-activedescendant` set on the contenteditable `role="group"` holder, announcing each highlighted tool by name with the text selection intact. Two cases failed with more than one available explanation, and only some of them were this change's fault; each was settled by a scratch page varying one attribute at a time rather than by reasoning about what a screen reader probably does, and both findings contradicted the obvious first guess: `aria-controls` turned out to be irrelevant to the plus-button's unannounced `aria-expanded` (`aria-haspopup` suppresses it), and the `role="textbox"` added by this change turned out not to be why links inside a block go unannounced (`contenteditable` is, as a plain one behaves identically). The scratch pages were throwaway; the results are recorded under Cases 15 and 17 of `voiceover-verification.md`.
+- No breaking changes to this repo's public APIs.
diff --git a/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/specs/tools/spec.md b/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/specs/tools/spec.md
new file mode 100644
index 00000000..eab1f258
--- /dev/null
+++ b/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/specs/tools/spec.md
@@ -0,0 +1,28 @@
+## ADDED Requirements
+
+### Requirement: Accessible paragraph block
+`Paragraph` SHALL expose its contenteditable text element as an editable text field to assistive technology, via `role="textbox"`, `aria-multiline="true"`, and a non-empty `aria-label` identifying it as a paragraph block.
+
+#### Scenario: Paragraph contenteditable is an accessible textbox
+- **GIVEN** a `Paragraph` instance has lazily created its contenteditable `<div>`
+- **WHEN** the element is inspected
+- **THEN** it has `role="textbox"`, `aria-multiline="true"`, and a non-empty `aria-label`
+
+#### Scenario: Every block is exposed as a text field of its own
+- **GIVEN** the editor has rendered a document of several paragraph blocks
+- **WHEN** the accessibility tree is inspected
+- **THEN** each block exposes its own `role="textbox"` with its own accessible name
+- **AND** assistive technology can move between them in document order
+
+### Requirement: Paragraph placeholder is announced
+A contenteditable element has no native `placeholder`, so an empty block would otherwise be announced as an unlabelled empty field with no indication of what belongs in it. `Paragraph` SHALL expose the placeholder it is configured with (`config.placeholder`, which the editor fills from its own `placeholder` option for the default block tool) as `aria-placeholder` on its contenteditable element, and SHALL omit the attribute when no placeholder is configured.
+
+#### Scenario: Configured placeholder reaches assistive technology
+- **GIVEN** the editor is configured with a `placeholder` and `Paragraph` is the default block tool
+- **WHEN** an empty paragraph block's contenteditable element is inspected
+- **THEN** it has `aria-placeholder` set to the configured text
+
+#### Scenario: No placeholder configured
+- **GIVEN** the editor is configured without a `placeholder`
+- **WHEN** a paragraph block's contenteditable element is inspected
+- **THEN** it has no `aria-placeholder` attribute
diff --git a/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/specs/ui/spec.md b/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/specs/ui/spec.md
new file mode 100644
index 00000000..d7c1f642
--- /dev/null
+++ b/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/specs/ui/spec.md
@@ -0,0 +1,196 @@
+## ADDED Requirements
+
+### Requirement: Accessible blocks holder
+`BlocksUI` SHALL expose its contenteditable blocks holder element as a structural container, via `role="group"` — the holder itself is not an editable region; each block owns its own `role="textbox"` and accessible name (see the `tools` spec's `Paragraph` requirement), which avoids nesting a `textbox` role inside another `textbox` role between the holder and its contenteditable block children.
+
+#### Scenario: Blocks holder exposes group role
+- **GIVEN** `BlocksUI` has rendered the blocks holder element
+- **WHEN** the element is inspected
+- **THEN** it has `role="group"`
+
+#### Scenario: Blocks holder does not nest an editable region
+- **GIVEN** the editor has rendered a single paragraph block
+- **WHEN** the accessibility tree beneath the blocks holder is inspected
+- **THEN** exactly one element exposes `role="textbox"` — the block's contenteditable element, not the holder
+
+### Requirement: Accessible floating toolbar
+`ToolbarUI` SHALL expose its actions container with `role="toolbar"` and an accessible name distinguishing it from the inline toolbar. Its plus-button control SHALL have an accessible name (`aria-label`) describing its action, and SHALL advertise the toolbox menu it controls via `aria-haspopup="menu"` and an `aria-expanded` state kept in sync with whether the toolbox is open.
+
+#### Scenario: Toolbar actions container has toolbar role
+- **GIVEN** `ToolbarUI` has rendered its actions container
+- **WHEN** the element is inspected
+- **THEN** it has `role="toolbar"` and a non-empty `aria-label`
+
+#### Scenario: Plus-button has an accessible name
+- **GIVEN** `ToolbarUI` has rendered the plus-button
+- **WHEN** the element is inspected
+- **THEN** it has a non-empty `aria-label`
+
+### Requirement: The block actions toolbar is a single tab stop
+`role="toolbar"` declares that the group is reached once by `Tab` and navigated internally with the arrow keys; a browser does not provide that on its own. `ToolbarUI` SHALL therefore maintain a roving tabindex over its own controls — exactly one in the tab order at a time, moved by the horizontal arrow keys — and SHALL declare its `aria-orientation`. Only the container's own controls take part: the toolbox popover renders *inside* the actions container, and its menu items are navigated by `@editorjs/ui-kit`, so keys arriving from within it are left alone.
+
+The pattern covers the **unmodified** arrow keys only. `ToolbarUI` SHALL ignore an arrow key pressed with any modifier held, and SHALL NOT call `preventDefault()` on it. A modified arrow always belongs to something else, and a screen reader is the case that matters here: VoiceOver moves its cursor with VO+Right and VO+Left, which reach the page as `Control`+`Option`+arrow. Swallowing those traps a VoiceOver user on whichever control their cursor reached, since Safari focuses a control when the cursor lands on it.
+
+#### Scenario: Modified arrow keys are left to their owner
+- **GIVEN** a control of the block actions toolbar holds focus
+- **WHEN** an arrow key is pressed with `Control`+`Option`, `Meta`, or `Shift` held
+- **THEN** the toolbar does not handle it and the event is not prevented
+- **AND** an unmodified arrow key is still handled by the toolbar
+
+#### Scenario: Only one control is in the tab order
+- **GIVEN** `ToolbarUI` has rendered its actions container
+- **WHEN** its controls are inspected
+- **THEN** exactly one of them has `tabindex="0"` and the rest have `tabindex="-1"`
+- **AND** the container declares `aria-orientation`
+
+#### Scenario: Toolbox keyboard navigation is not intercepted
+- **GIVEN** the toolbox has been opened from the plus-button
+- **WHEN** the user presses a vertical arrow key inside the menu
+- **THEN** the toolbox handles it and moves focus between menu items, unaffected by the toolbar's own arrow-key handling
+
+#### Scenario: Plus-button reports the toolbox state
+- **GIVEN** the toolbox is closed
+- **WHEN** the plus-button is inspected
+- **THEN** it has `aria-haspopup="menu"` and `aria-expanded="false"`
+- **WHEN** the plus-button is activated and the toolbox opens
+- **THEN** its `aria-expanded` becomes `"true"`
+- **WHEN** the toolbox is dismissed
+- **THEN** its `aria-expanded` returns to `"false"`
+
+### Requirement: Focus returns to the control that opened the toolbox
+Following the WAI-ARIA menu button pattern, dismissing the toolbox SHALL return DOM focus to the plus-button that opened it, so that keyboard and screen-reader users keep their place in the editor. `ToolbarUI` SHALL therefore move focus onto the plus-button when it opens the toolbox — Safari does not focus a button when it is clicked, which would otherwise leave the popover with `document.body` as the element to restore focus to.
+
+#### Scenario: Dismissing the toolbox restores focus
+- **GIVEN** the toolbox has been opened from the plus-button
+- **WHEN** the user presses `Escape`
+- **THEN** the toolbox closes and DOM focus is on the plus-button
+
+#### Scenario: Inserting a block does not lose focus
+- **GIVEN** the toolbox has been opened from the plus-button
+- **WHEN** the user activates a menu item and a block is inserted
+- **THEN** DOM focus is on a named control within the editor, not on the document body
+
+### Requirement: Toolbox search hides filtered-out items from assistive technology
+Filtering the toolbox by its search field SHALL remove non-matching items from the accessibility tree — not only hide them visually — so that assistive technology cannot reach a result the sighted user can no longer see. The `hidden` attribute that achieves this is applied by `@editorjs/ui-kit`.
+
+#### Scenario: Filtered-out items leave the accessibility tree
+- **GIVEN** the toolbox is open and exposes its block tools as menu items
+- **WHEN** the user types a query that matches none of them
+- **THEN** no `role="menuitem"` element remains exposed
+- **WHEN** the query is changed to one that matches again
+- **THEN** the matching item is exposed once more
+
+### Requirement: Accessible toolbox menu
+`ToolboxUI` SHALL name the menu its popover renders, so that the list of block types is announced as a named menu. The accessible names of the individual items and the `menu`/`menuitem` roles are produced by `@editorjs/ui-kit` from the `title` each tool is registered with.
+
+#### Scenario: Toolbox exposes a named menu of block types
+- **GIVEN** the toolbox has been opened
+- **WHEN** the accessibility tree is inspected
+- **THEN** a `role="menu"` element with a non-empty accessible name is exposed
+- **AND** each registered block tool is exposed as a `role="menuitem"` named after its toolbox title
+
+#### Scenario: Toolbox items are operable by keyboard
+- **GIVEN** the toolbox has been opened
+- **WHEN** the user presses `ArrowDown`
+- **THEN** DOM focus moves onto the first menu item
+- **WHEN** the user presses `Enter`
+- **THEN** the corresponding block is inserted
+
+### Requirement: Accessible inline toolbar
+`InlineToolbarUI` SHALL name the toolbar its popover renders, so that it is distinguishable from the block actions toolbar. The inline popover does not move DOM focus onto its buttons — doing so drops the text selection the inline tools operate on — so `InlineToolbarUI` SHALL mirror the item highlighted by keyboard navigation onto `aria-activedescendant` of the element that holds focus, and SHALL clear it once nothing is highlighted or the toolbar is dismissed.
+
+`aria-activedescendant` is only resolved when it names an element inside the focused element's subtree, or one the focused element claims via `aria-owns`. The toolbar is rendered as a *sibling* of the blocks holder, so setting the reference alone leaves it pointing outside the focused subtree, where assistive technology drops it. `InlineToolbarUI` SHALL therefore claim its popover via `aria-owns` on the same element, set and cleared together with the reference so the two cannot disagree. This re-parents the popover in the accessibility tree only — the DOM, and hence the text selection the inline tools operate on, is untouched.
+
+The element carrying the pair SHALL be one inside the editor this toolbar belongs to. On a page with more than one editor, a toolbar that has been raised for a selection in another instance would otherwise claim its own popover from that instance's holder, telling assistive technology that controls operating on one document belong to another.
+
+The accessible names of the individual buttons, their `button` role and their `aria-pressed` state are produced by `@editorjs/ui-kit` from the `title` and `isActive` each inline tool already provides.
+
+#### Scenario: Inline toolbar exposes named formatting buttons
+- **GIVEN** a range of text is selected
+- **WHEN** the accessibility tree is inspected
+- **THEN** a `role="toolbar"` element with a non-empty accessible name is exposed
+- **AND** each available inline tool is exposed as a `role="button"` named after its title
+
+#### Scenario: Inline tool reports whether it is applied
+- **GIVEN** a range of unformatted text is selected
+- **THEN** the bold button exposes `aria-pressed="false"`
+- **WHEN** the bold tool is applied and the text is selected again
+- **THEN** the bold button exposes `aria-pressed="true"`
+
+#### Scenario: Highlighted inline tool is announced without taking focus
+- **GIVEN** the inline toolbar is shown for a text selection
+- **WHEN** the user navigates the toolbar with the arrow keys
+- **THEN** the element holding focus exposes `aria-activedescendant` referencing the highlighted button
+- **AND** the text selection is preserved
+- **WHEN** the toolbar is dismissed
+- **THEN** `aria-activedescendant` is removed
+
+#### Scenario: The reference is not claimed from outside the editor
+- **GIVEN** the inline toolbar has an item highlighted by keyboard navigation
+- **WHEN** the element holding focus belongs to a different editor instance, or to no editor at all
+- **THEN** neither `aria-activedescendant` nor `aria-owns` is written onto it
+
+#### Scenario: The highlighted item is reachable from the element holding focus
+- **GIVEN** the inline toolbar is shown and an item has been highlighted by keyboard navigation
+- **WHEN** the reference is resolved from the element holding focus
+- **THEN** that element also exposes `aria-owns` naming the popover
+- **AND** the element named by `aria-activedescendant` is inside the popover so named
+- **AND** it is *not* a DOM descendant of the element holding focus, the relationship being an accessibility-tree one only
+- **WHEN** the toolbar is dismissed
+- **THEN** `aria-owns` is removed alongside `aria-activedescendant`, leaving no claim on a destroyed popover
+
+### Requirement: Inline toolbar announces its own availability
+The inline toolbar appears next to a text selection without moving DOM focus or the virtual cursor, so nothing otherwise tells a screen reader user that it exists or that `Tab` now leads somewhere new. `InlineToolbarUI` SHALL announce its appearance through a live region, which SHALL remain mounted across popover re-renders — a region that is not already in the accessibility tree when its text changes is unreliable across assistive tech.
+
+The announcement SHALL fire once per genuine open: not again while the toolbar stays open across selection changes, and again when the toolbar is dismissed and shown anew.
+
+The announcement is written on a short delay, so that an identical repeat still reads as a change to the region. A toolbar dismissed inside that delay SHALL NOT announce itself — the pending write is cancelled rather than allowed to describe a toolbar that is already gone.
+
+#### Scenario: A toolbar dismissed before the announcement lands stays silent
+- **GIVEN** the inline toolbar has just appeared and its announcement is scheduled but not yet written
+- **WHEN** the toolbar is dismissed before the delay elapses
+- **THEN** the live region is never filled with the announcement
+
+#### Scenario: Toolbar announces that it can be entered
+- **GIVEN** no inline toolbar is shown
+- **WHEN** a range of text is selected and the toolbar appears
+- **THEN** the toolbar's live region is filled with a message naming the toolbar and the key that enters it
+
+#### Scenario: Announcement does not repeat while the toolbar stays open
+- **GIVEN** the inline toolbar is shown for a text selection
+- **WHEN** the selection is extended or shrunk while remaining non-empty
+- **THEN** the toolbar's popover is rebuilt
+- **AND** no further announcement is made
+
+#### Scenario: Announcement repeats when the toolbar is genuinely reopened
+- **GIVEN** the inline toolbar has been shown and then dismissed
+- **WHEN** a range of text is selected again
+- **THEN** the announcement is made again
+
+### Requirement: The inline toolbar shown is the one built for the current selection
+Building the toolbar is asynchronous — every tool contributes an awaited `getToolbarConfig` — so two selection changes can be in flight at once and resolve in either order. `InlineToolbarUI` SHALL discard a build that was superseded while it was awaiting, rather than letting whichever finishes last take effect. A superseded build SHALL neither replace the popover nor reposition or re-announce the toolbar.
+
+This is an accessibility requirement and not only a rendering one: each tool's `isActive` and `onActivate` close over the range the build started from, so a stale build puts up buttons whose `aria-pressed` describes text the user has moved off, and which act on it when activated.
+
+Being dismissed counts as superseding: a build still awaiting when the toolbar is hidden SHALL NOT put it back up.
+
+#### Scenario: A superseded build does not take effect
+- **GIVEN** a toolbar build is awaiting its tools
+- **WHEN** a further selection change starts a build of its own and the first one resolves afterwards
+- **THEN** the popover in the document is the one built for the later selection
+- **AND** the earlier build neither repositions nor re-announces the toolbar
+
+#### Scenario: A build outstanding at dismissal does not resurrect the toolbar
+- **GIVEN** a toolbar build is awaiting its tools
+- **WHEN** the selection is dropped and the toolbar is hidden before the build resolves
+- **THEN** no popover is added to the document when it does
+
+### Requirement: Dismissed inline toolbar leaves the accessibility tree
+`InlineToolbarUI` SHALL remove its tools from the document when the toolbar is dismissed, rather than only hiding them visually. A control that is invisible but still exposed leaves a screen reader able to reach and activate a tool that is no longer available.
+
+Note that removal is the limit of what the editor controls: VoiceOver has been observed to keep reaching a dismissed tool after it has left the DOM, and no navigation clears it (recorded under Case 11 in `voiceover-verification.md`). The requirement is therefore stated over the document, which is verifiable, rather than over what any given screen reader will do with it.
+
+#### Scenario: Inline tools are removed once the toolbar is dismissed
+- **GIVEN** the inline toolbar is shown for a text selection
+- **WHEN** the selection is collapsed and the toolbar is dismissed
+- **THEN** no `role="button"` named after an inline tool remains exposed in the document's accessibility tree
diff --git a/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/tasks.md b/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/tasks.md
new file mode 100644
index 00000000..cc59a944
--- /dev/null
+++ b/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/tasks.md
@@ -0,0 +1,118 @@
+## 1. Spike: confirm `ui-kit` popover capabilities
+
+- [x] 1.1 Determine whether `PopoverInline` renders items as real `<button>` elements — **resolved by source inspection, no runtime spike needed**: `popover-inline.ts:18-34` already hardcodes `wrapperTag: 'button'` for `PopoverItemType.Default`
+- [x] 1.2 Determine whether consumers can reach constructed `PopoverItemDefault` instances to call `getElement()` — **they cannot**: `InlineToolbarUI`/`ToolboxUI` pass plain param objects to the popover, which builds items internally and exposes no accessor
+- [x] 1.3 Record the outcome in design.md's "Open Questions" and "Decisions", and open the upstream fix instead of a consumer-side workaround
+
+## 2. Blocks holder accessibility (`BlocksUI`)
+
+- [x] 2.1 Set `role="group"` on the blocks holder element in `packages/ui/src/Blocks/Blocks.ts`
+- [x] 2.2 Cover it with an e2e assertion that the holder resolves as `role="group"`
+- [x] 2.3 Cover the nested-textbox decision: exactly one `role="textbox"` is exposed beneath the holder
+
+## 3. Paragraph block accessibility
+
+- [x] 3.1 Set `role="textbox"`, `aria-multiline="true"`, and `aria-label="Paragraph"` on the contenteditable `<div>` in `packages/tools/paragraph/src/index.ts` at creation time (in `#onUpdate`, where the element is actually created — not `render()`)
+- [x] 3.2 Cover it with an e2e assertion via `getByRole('textbox', { name: 'Paragraph' })`
+- [x] 3.3 Expose the tool's configured `placeholder` as `aria-placeholder`, so an empty block announces what belongs in it rather than reaching assistive tech as an unlabelled empty field (a contenteditable has no native `placeholder`)
+- [x] 3.4 Cover multi-block documents: each block is its own named textbox, in document order — the single-block fixture made "no second textbox" nearly vacuous. The e2e fixture mounts one paragraph per `text` search param for this
+
+## 4. Floating toolbar accessibility (`ToolbarUI`)
+
+- [x] 4.1 Set `role="toolbar"` on the actions container and `aria-label="Add block"` on the plus-button in `packages/ui/src/Toolbar/Toolbar.ts`
+- [x] 4.2 Cover both with e2e assertions via `getByRole('toolbar')` and `getByRole('button', { name: 'Add block' })`
+- [x] 4.3 Focus the plus-button when it opens the toolbox, so dismissing the toolbox returns focus there. Safari does not focus a `<button>` on click, so the popover captured `document.body` as the element to restore focus to and both `Escape` and inserting a block dropped focus out of the editor entirely — found by the new focus-destination e2e tests, webkit only
+- [x] 4.4 Cover the `aria-expanded` round trip and both dismissal paths (Escape, insert) with e2e assertions on where focus lands
+
+## 5. Popover-rendered surfaces (toolbox + inline toolbar) — fixed upstream, consumed here
+
+`@editorjs/ui-kit` renders these items and used to emit zero `role`/`aria-*`; the only
+consumer-side hook was reaching into its internal markup, which its own `innerHTML`
+replacement on confirmation-mode toggles would wipe. Fixed in `@editorjs/ui-kit` (same
+maintainers) rather than worked around, and released as **2.0.0**.
+
+- [x] 5.1 Audit `@editorjs/ui-kit` 1.1.5 for accessibility gaps across all components
+- [x] 5.2 Write the upstream audit — per-component findings, concrete fixes, suggested sequencing, and the downstream payoff. Written for the `editorjs-utils` repo and kept there with the work it describes, not in this repo
+- [x] 5.3 Write the implementation brief — executable and phased, for the ui-kit repo, including its own Playwright e2e scaffold (ui-kit has no test infrastructure) and per-phase popover e2e coverage. Also lives in `editorjs-utils`
+- [x] 5.4 Execute the brief upstream — landed in `editorjs-utils` as `@editorjs/ui-kit` 2.0.0 / `@editorjs/dom` 1.2.0: derived item roles and names, `aria-pressed`/`aria-checked`, `menu`/`toolbar` containers, roving-tabindex focus, live-region announcements, mobile dialog semantics, and `PopoverEvent.ActiveDescendantChanged`
+- [x] 5.5 Bump `@editorjs/ui-kit` to `^2.0.0` in `packages/ui` and `packages/sdk`
+- [x] 5.6 Name the toolbox menu via `messages.label` in `ToolboxUI`
+- [x] 5.7 Name the inline toolbar via `messages.label` in `InlineToolbarUI`
+- [x] 5.8 Advertise the toolbox from the plus-button: `aria-haspopup="menu"` plus an `aria-expanded` driven by the existing `ui:toolbox:opened`/`ui:toolbox:closed` events
+- [x] 5.9 Mirror `PopoverEvent.ActiveDescendantChanged` onto `aria-activedescendant` of the focused editable in `InlineToolbarUI`, and clear it on rebuild/hide
+- [x] 5.10 Fix the popover leak found while testing: `#renderPopover` appended a new popover element per call without removing the previous one, so two overlapping selection changes left an orphan in the DOM
+
+## 5a. Upstream defect found while consuming the release
+
+- [x] 5a.1 `@editorjs/ui-kit` 2.0.0 shipped `dist/e2e/**/*.d.ts` and `dist/playwright.config.d.ts`, which `import` from `@playwright/test` — a devDependency. Any consumer type-checking against the package fails (it broke `@editorjs/core`'s `DocumentAPI.spec.ts` under ts-jest). Fixed at source by excluding `e2e/**` and `playwright.config.ts` from `vite-plugin-dts` in `packages/ui-kit/vite.config.js`. **Needs to be part of the 2.0.0 release, not published without it.**
+- [x] 5a.2 Remove the local link. The root `resolutions` entry pointing `@editorjs/ui-kit` at a sibling `editorjs-utils` checkout is gone, along with its `link:` locator in `yarn.lock`; no path to anyone's local filesystem remains in the repo. The branch therefore no longer installs *anywhere* — `yarn install` fails with `@editorjs/ui-kit@npm:^2.0.0: No candidates found` — which is the honest state rather than one that works on a single machine, and it is the state that makes 5a.3 the only remaining blocker
+- [x] 5a.3 **Done — `@editorjs/ui-kit` 2.0.0 is published**, with the 5a.1 fix included. `yarn install` regenerated the lockfile, which now resolves `@editorjs/ui-kit@npm:^2.0.0` to 2.0.0 and carries no `link:` locator anywhere. The full suite was re-run against the published package rather than a local build of it: build, 973 unit tests, 80 Playwright e2e across chromium and webkit, and lint, all green. One thing the regeneration surfaced: ui-kit 2.0.0 depends on `@editorjs/dom` `^1.2.0` while the workspace packages still asked for `^1.1.0`, and Yarn will not re-resolve an already-locked entry, so the two ranges resolved separately and `node_modules` ended up with two copies of `@editorjs/dom` — one of them nested under `@editorjs/caret`, which pins `^1.1.0` transitively. The workspace ranges were widened to `^1.2.0` and `yarn dedupe @editorjs/dom` collapsed both onto a single 1.2.0 resolution. `@editorjs/caret` is still published depending on `^1.1.0`, so a fresh install of ui-kit 2.0.0 elsewhere gets the duplicate until that range is widened upstream
+
+## 6. Test infrastructure decision
+
+- [x] 6.1 Establish that neither `@editorjs/ui` nor `@editorjs/paragraph` has any test setup (no jest config, no `test` script, no specs) — the original per-package `yarn workspace … test` tasks were not runnable
+- [x] 6.2 Verify via Playwright e2e instead: real browser accessibility tree, no new infrastructure, and stronger evidence for ARIA than jsdom would give
+- [x] 6.3 Add `packages/editorjs/e2e/tests/aria.spec.ts` — covering the blocks holder, paragraph textbox (name, multiline, placeholder, one per block, block created by Enter), floating toolbar, toolbox menu (name, items, search field, search filtering, keyboard focus and activation, focus on dismissal) and inline toolbar (name, buttons, `aria-pressed`, `aria-activedescendant`, applied links, live-region announcement)
+
+## 7. Verification and docs
+
+- [x] 7.1 Run `yarn lint` across affected workspaces (`ui`, `paragraph`, `editorjs`) to confirm no regressions
+- [x] 7.2 Run the full e2e suite (chromium + webkit) and the repo unit suites
+- [x] 7.3 Automate screen-reader verification with [Guidepup](https://www.guidepup.dev/) (`@guidepup/playwright` + `@guidepup/guidepup`), which drives a real, running VoiceOver instance against Safari and exposes its spoken-phrase log as assertable strings. `packages/editorjs/e2e/tests/voiceover.spec.ts` automates cases 1-7 and 9-18 from `voiceover-verification.md`, run via `yarn test:e2e:voiceover` (its own `playwright.voiceover.config.ts` — screen readers are singletons and can't drive a headless browser, so this suite is `workers: 1`, headed, macOS-only, and excluded from `test:e2e`/CI). **Case 8 is covered as a measurement rather than an assertion** — see 9.7 and `voiceover-verification.md`.
+- [x] 7.4 Migrate `packages/editorjs/e2e/tests/editor.spec.ts` fully to `getByRole` (the bold button was the last CSS-class locator), and rewrite `e2e/README.md`'s locator guidance to reflect the landed semantics
+- [x] 7.5 Add `@axe-core/playwright` and cover the editor's load state, open toolbox, and open inline toolbar with static accessibility audits in `e2e/tests/axe.spec.ts` — catches rule-based violations (missing names, invalid roles, contrast, etc.) that complement the role/name assertions in `aria.spec.ts` and the announcement-level checks in `voiceover.spec.ts`. Each audit waits for CSS animations to settle first (axe samples computed styles when it runs, so a mid-fade popover can report a contrast violation that isn't real) and asserts on `id (impact): help` summaries so a failure names the rule
+- [x] 7.6 Run `openspec validate add-editor-aria-semantics --strict`
+
+## 8. Review pass over the screen-reader suite
+
+Audit of the cases added in 7.3, closing the gaps between what each one is named and what it
+actually asserts. Two of them were assertions that could pass while the behaviour was broken.
+
+- [x] 8.1 Cover the reopen half of "once per open" — `InlineToolbarUI#show` only announces on a hidden-to-shown transition, so a regression leaving its visibility state stuck would silence the toolbar for the rest of the session while every existing no-repeat assertion still passed. Added to both `voiceover.spec.ts` (Case 7) and `aria.spec.ts`, and specified in `specs/ui/spec.md`
+- [x] 8.2 Anchor the `aria-pressed` assertion to the tool's name. The toolbar only exists while text is *selected*, so a bare match on VoiceOver's "selected" wording could be satisfied by it describing the selection instead of the button — passing without the state being exposed
+- [x] 8.3 Turn Case 11 into a real assertion. It dismissed the toolbar, took one cursor step and checked that item wasn't a tool — too short to reach where the tools were, so it passed regardless. It now resets the cursor, sweeps the editor, and asserts the user is put back in their document rather than stranded on a dead control. It does **not** assert that the tools become unreachable — see 8.12. The DOM half (the popover really is detached) is covered headlessly in `aria.spec.ts` and specified in `specs/ui/spec.md`
+- [x] 8.4 Compare Case 15's open/closed announcements on the item description alone — the fuller description folds in the last *spoken* phrase, which can lag a stop behind, so an exact match on it would fail on timing rather than on the state changing
+- [x] 8.5 Automate the checklist expectations that had been dropped silently: Tab-onward/`Shift+Tab`-back through the inline toolbar (Case 6), and menu-closed plus focus-not-on-`<body>` after activating a toolbox item (Case 4). The third — the "Block actions" toolbar name (Case 3) — turned out **not to be assertable**: see 8.11
+- [x] 8.6 Identify a block created by Enter (Case 14) by its placeholder rather than by "a text field that isn't the first one", which the link tool's URL input would also satisfy
+- [x] 8.7 Anchor Case 1's step-back no-op to the block it starts on, so that mounting anything above the editor fails loudly instead of turning the assertion vacuous
+- [x] 8.8 Extract `e2e/support/editor.ts` (mount, select, Tab-to-tool, placeholder) shared by all four specs, and mount per-test in `voiceover.spec.ts` — a `beforeEach` mount thrown away by the next line costs real seconds when every command drives a live screen reader
+- [x] 8.9 Lint `playwright.voiceover.config.ts` — it was covered by `eslint.config.mjs` but never passed to `eslint`, and had three real errors once it was
+- [x] 8.10 ~~Correct the "Playwright visibility is not VoiceOver reachability" note in `e2e/README.md`: the popover is detached on dismissal, so what the observation was actually about is VoiceOver answering from a stale tree until it re-navigates~~ **Wrong — reverted in 8.12.** The original note was right; a clean DOM does not distinguish "gone from VoiceOver" from "VoiceOver still holding it"
+- [x] 8.11 Run the suite against real VoiceOver and settle the two cases that failed:
+  - **Case 3** — the "Block actions" toolbar name added in 8.5 is **not announced**. `VO+Right` goes from the block straight onto the plus button in one step; the route mentions no container. The inference behind it (Case 1's unnamed group is transparent *because* it is unnamed, so a named one would be announced) does not hold at the browse cursor. Markup is correct and covered in `aria.spec.ts`; the case now pins the absence, like the `aria-expanded` finding in Case 15. Recorded as the third finding in `voiceover-verification.md` and `e2e/README.md`
+  - **Case 11** — the new sweep used `walk`, which steps before recording and so never saw the block the cursor was reset onto, failing the vacuity guard rather than the assertion. Added `sweep` ("what is reachable from here") alongside `walk` ("what is ahead of here"), and rebuilt `collectReachable` on it
+- [x] 8.12 Second VoiceOver run: with the guard fixed, Case 11's real assertion ran for the first time and failed — a dismissed toolbar's Bold **is** still reachable. Confirmed headlessly that the DOM is clean either way (popover detached, `getByRole` count 0 on both engines, with and without Tab having moved focus into the toolbar), so this is VoiceOver retaining dropped nodes and `resetCursor` does not clear it. Consequences:
+  - The 8.10 rewrite of the `e2e/README.md` trap note was wrong and is reverted; the original observation from the Case 17 work was correct. Both facts are now recorded together — the DOM is clean *and* the controls stay reachable — since either alone invites the same mistake
+  - Case 11 asserts what holds (the cursor lands on the block's content, not on a dead control) and documents the rest. Not pinned inverted the way Cases 3 and 15 pin theirs: a retained-node artifact isn't deterministic enough to fail a build over
+  - Case 17's `interact()` bound is load-bearing for the original reason, not the one 8.10 gave it. Its comment is restored
+  - `specs/ui/spec.md` states the dismissal requirement over the document, which is verifiable, rather than over what a screen reader will do with it
+
+## 9. Review pass over the ARIA implementation
+
+- [x] 9.1 Fix `aria-activedescendant` pointing outside the focused element's subtree. `EditorjsUI` appends the inline toolbar as a *sibling* of the blocks holder, so the reference named an element the focused holder does not contain — invalid per ARIA, and dropped by assistive tech rather than followed. `InlineToolbarUI` now claims the popover with `aria-owns` on the same element, set and removed together with the reference. Recorded as a Decision in design.md and as a requirement in `specs/ui/spec.md`
+- [x] 9.2 Assert the *resolved relationship* in `aria.spec.ts` rather than the attribute value. The original assertion compared `aria-activedescendant` against the button's `id`, which matches whether or not the reference resolves — it passed against the broken implementation. Two cases added: the named item is inside the owned popover (and deliberately not a DOM descendant of the focused element), and both attributes are released when the toolbar is dismissed
+- [x] 9.3 Audit the *navigated* toolbar state with axe. The existing audit opened the toolbar but never highlighted an item, so `aria-owns`/`aria-activedescendant` did not exist while it ran. Added as a fourth state
+- [x] 9.4 Build workspace dependencies before serving the e2e fixture. The fixture reaches `@editorjs/ui` and the tools through their `exports`, i.e. their `dist`, so `yarn test:e2e` audited whatever was built last — the 9.1 fix appeared to fail until the package was rebuilt, and equally a regression could have passed against a stale build. Both playwright configs now build first
+- [x] 9.5 Cover the tools spec's "No placeholder configured" scenario, which had no test: the fixture always set a `placeholder`, so nothing pinned that the tool omits the attribute rather than writing an empty one. Added `?placeholder=` to the fixture and a negative assertion
+- [x] 9.7 Bring Case 8 into the automated suite, first as a measurement and then (9.6) as an assertion. It had been left manual on the grounds that "a test asserting either outcome would just be encoding a guess" — but the suite's own convention is the opposite: Cases 3, 11 and 15 all pin outcomes that were unknown until measured, including negative ones. Two things that looked like blockers turned out to be solved already: `page.keyboard.press` delivers the arrow key reliably (`voiceOver.press` does not, per the file header), and Case 7's `VO-Z` trick captures an announcement nothing asked for, since Guidepup only samples speech while executing a command. Running it as a measurement first meant the run could not fail for the wrong reason and the expected value came from observation rather than from a guess. **The manual checklist is now empty** — every case in `voiceover-verification.md` is automated, run and passing
+- [x] 9.6 Run `yarn test:e2e:voiceover` and pin Case 8's result. **Settled: VoiceOver does follow `aria-activedescendant` set on the contenteditable `role="group"` blocks holder.** Arrowing to Bold announced "Bold toggle button", arrowing on to Italic "Italic toggle button" — each naming the item the reference points at, with focus never leaving the text and the selection intact. The measurement is now an assertion anchored to the name read off the element rather than to hardcoded tool names, keeping both arrow steps so a stale phrase replayed by `VO-Z` cannot satisfy it. The first assertion-version of it was flaky and failed once with `"hello world selected"`: VoiceOver's speech is asynchronous and unsignalled, so a single `VO-Z` straight after the keypress samples whatever was last *completed* — under load, still the selection announcement from the click that opened the toolbar. It now polls `VO-Z` on a deliberately slow 1.5s interval up to 20s (tight polling would interrupt the phrase being waited for). It then failed a second time, and differently: passing in isolation but timing out across the whole 20s in the full suite. That was the case missing `syncCursorToFocus()` — VoiceOver reports state for the element *its own* cursor is on and never sees Playwright's synthesized events, so the click that made the selection left the cursor where the previous case had it. Alone, a fresh session's cursor was close enough; after sixteen cases it was not. The rule is stated in the spec file's header and every other case that reads VoiceOver back after a page-driven focus change already followed it — Case 8 was the sole exception. The failure message now also reports where the cursor was, so a repeat names its own cause. "toggle button" shows `aria-pressed` reaching speech on this path too, left unasserted here because Case 5 & 6 owns it. The whole 18-case suite was re-run green, which is also the first confirmation that the section 10 lifecycle rework did not regress announcements or teardown
+
+## 10. Lifecycle, keyboard and string-handling cleanups
+
+Follow-ups from the same review pass, none of them user-visible today but each one a contract
+the code was not keeping.
+
+- [x] 10.1 Stop `InlineToolbarUI` holding a destroyed popover. `#hide()` destroyed the instance but left `#popover` set, so the next rebuild destroyed it again — re-running item cleanup and re-emitting `PopoverEvent.Closed` to any future listener. Extracted `#destroyPopover()`, which clears the reference, the popover element and the `aria-activedescendant`/`aria-owns` pair together, and is now the single teardown path for hide, rebuild and plugin destroy alike. `destroy()` previously removed the holder while leaving the popover's document-level listeners and any pending announcement alive; it tears down properly first now
+- [x] 10.1a Tear the old popover down *after* the last `await` in `#renderPopover` rather than on entry. Task 5.10 fixed the orphaned *element* left by two overlapping selection changes, but not the orphaned *instance*: with teardown on entry, the second call disposes before the first has built anything, so the first call's popover is then overwritten with its document-level listeners still attached. Disposing immediately before building means each call disposes whatever is actually current, whichever order they interleave in — and the outgoing toolbar no longer blinks out for the duration of the await
+- [x] 10.1b Decide *which* render wins, not just that each one disposes correctly. 10.1a made two interleaved `#renderPopover` calls tear down safely in either order, but left the outcome to whichever resolved last — and with an awaited `getToolbarConfig` per tool, that need not be the later selection. The loser is not a redundant rebuild: `isActive`/`onActivate` close over the `textRange` the call started from, so a late-resolving older build puts up buttons whose `aria-pressed` describes text the user has moved off and which act on it when activated. A generation counter is now claimed before the first await and rechecked after the last; a superseded build returns without tearing anything down or building anything, and `#handleSelectionChange` skips the `#move()`/`#show()` that would otherwise reposition and re-announce the toolbar the winner put up. `#hide()` bumps the same counter, so a build outstanding at dismissal can no longer resurrect the toolbar for a selection that is gone. Specified in `specs/ui/spec.md`. **Not covered by a test**: landing inside the window needs two selection changes to interleave with a controlled resolution order, which no Playwright interaction arranges deterministically — same disposition as 10.3 and 10.7
+- [x] 10.1c Unsubscribe `InlineToolbarUI` from the core's selection changes in `destroy()`. 10.1 gave the method a comment about tearing down "properly", but the constructor's `core:selection-changed` subscription outlived it — and as an inline arrow it could not have been removed at all. Held as a field now and removed first, before the popover teardown, so a selection change arriving mid-teardown cannot put a new popover into the holder that is about to be detached. Still dead code until the editor has a lifecycle; the point is that the method now does what it says
+- [x] 10.2 Move the popover element out of the `#nodes` bag into its own nullable field. `#nodes` is for the parts built once in `#render`; the popover element is replaced on every rebuild and absent while hidden, and typing it as always-present is what let the stale reference in 10.1 go unnoticed
+- [x] 10.3 Make the live-region announcement cancellable. It was scheduled through `delay()`, which returns no handle, so a toolbar dismissed inside the 50ms window still announced itself as available. Now a tracked `setTimeout`, cancelled on hide, on destroy, and before scheduling a replacement. **Not covered by a test**: the race is a 50ms window that no deterministic Playwright interaction can reliably land inside, and a timing-dependent assertion here would pass for the wrong reason more often than it would catch anything. Specified in `specs/ui/spec.md` instead
+- [x] 10.4 Give the block actions toolbar the roving tabindex its `role="toolbar"` promises — one control in the tab order, horizontal arrow keys moving between them, `aria-orientation` declared. Scoped to the container's own direct-child buttons, so keys arriving from the toolbox popover rendered inside it stay the popover's to handle. Invisible at runtime with one control, which is the point: adding a second one no longer silently makes the role a lie. Asserted structurally in `aria.spec.ts` — a behavioural assertion would be vacuous at a single control
+- [x] 10.4a **Stop the roving tabindex swallowing VoiceOver's own navigation keys — a real accessibility bug introduced by 10.4 and caught by the VoiceOver suite.** `#handleActionsKeydown` matched `ArrowLeft`/`ArrowRight` regardless of modifiers and called `preventDefault()`, but **VO+Right and VO+Left reach the page as `Control`+`Option`+arrow**. Safari focuses a control when the VoiceOver cursor lands on it, so once a user's cursor reached the plus button the editor ate every attempt to move off it: the cursor was trapped on the button for the rest of the session. It now ignores any modified arrow — those belong to the screen reader, the OS (`Meta`) or selection (`Shift`) — and handles the unmodified ones only. Seven of the seventeen VoiceOver cases failed on this at once (1, 2, 7, 11, 12, 13, 15) with three different-looking symptoms, and it presented as harness flakiness: it only bites once the cursor has reached a toolbar control, so an earlier full run passed 16 of 17 on the same code, and the accessibility *tree* was correct throughout — the defect was in the keyboard, which no attribute assertion can see. Settled without a screen reader: Playwright's failure snapshot marked the plus button `[active]`, a headless mount proved focus is on `<body>` there, and a scratch spec pressing `Control+Alt+ArrowRight` at the focused button reported `defaultPrevented: true`. Regression test in `aria.spec.ts` ("leaves modified arrow keys to their real owner") asserts the whole swallowed-key list rather than four separate negatives, so a handler that stops preventing the plain arrow too fails instead of passing vacuously. New scenario in `specs/ui/spec.md`. **Confirmed: the full VoiceOver suite is green after the fix** — all seven cases recovered together, which a harness-flakiness explanation would not have produced
+- [x] 10.5 Collect the strings `@editorjs/ui` writes into the DOM in `packages/ui/src/messages.ts`, and name the paragraph tool's in its own module. i18n stays out of scope; this is only the seam it would attach to, so that sourcing these from config later is a change to one file per package rather than to every call site
+- [x] 10.5a Make the inline toolbar's popover id per instance rather than a single constant. `aria-owns` resolves by document-wide `getElementById`, so a fixed id on a page with two editors hands the second editor's blocks holder the *first* editor's popover — pointing assistive tech at controls that operate on a different document. Introduced by 9.1 and caught only by mounting two editors; the fixture grew an `?editors=2` mode for it
+- [x] 10.7 Make `InlineToolbarUI#setActiveDescendant` total in which element it writes to. It picked up `document.activeElement` only when that was an `HTMLElement` and otherwise fell through to *whatever host it used last*, writing `aria-owns`/`aria-activedescendant` onto a previously focused element that had nothing to do with the current popover; and it adopted a new host without releasing the old one, so two different elements could hold the pair at once. Host selection is now a single `#activeDescendantTarget()` returning the element or null, the previous host is released before a new one is adopted, and a focus that is *inside the toolbar itself* yields null rather than a host — a control there claiming the popover would make an element own its own ancestor, and the reference is inert anyway, since the focused button is the active item. **Not covered by a test, deliberately.** A test was written for the Tab-into-the-toolbar case and passed against the unfixed code: ui-kit only emits `ActiveDescendantChanged` for its virtual-cursor navigation, and Tab switches it to real focus, so the two states are mutually exclusive upstream and neither branch is reachable from the editor today. Both are guards against an upstream behaviour change, and a test that cannot fail is worse than none — the same disposition as 10.3, and the rule this suite's own README states. The full VoiceOver suite was re-run green afterwards, which is what confirms the rework did not disturb the `aria-activedescendant` path Case 8 depends on
+- [x] 10.7a Bound `#activeDescendantTarget()` to the editor the toolbar belongs to. 10.7 made host selection total, but bounded it only by the *toolbar*: any focused element outside the toolbar qualified, including one in another editor. That is reachable today through the chromium scoping bug — on chromium, selecting in the second editor raises the *first* editor's toolbar, which then claimed its own popover from the second editor's holder, pointing assistive technology at controls that operate on a different document. The guard does not fix the scoping bug; it downgrades a confidently wrong claim to no claim, which is the safer failure for a screen reader user. Note it also changes how that `test.fail()` case fails on chromium — a missing `aria-owns` rather than a cross-editor one — which the test's comment now records so the eventual fixer isn't misled
+- [x] 10.9 Stop the e2e fixture and the specs holding the same literals separately. `PLACEHOLDER` in `e2e/support/editor.ts` repeated the placeholder string the fixture configures, so a change to the fixture would have left the specs asserting a value it no longer used. Both now come from `e2e/fixtures/constants.ts` — a module with no Playwright imports, so the fixture doesn't drag the test runner into the browser bundle. The fixture is the source of truth in that direction, since a spec asserting a value the fixture doesn't use is a test passing for the wrong reason. `?editors=` is validated in the same pass: `Number('abc')` is `NaN`, every comparison against which is false, so a typo used to mount one editor silently and let a two-editor test pass without ever having had two. It now fails the mount and records the reason on the body, because a module-level throw alone would surface only as a `data-editor-ready` timeout
+- [x] 10.6 Align the Playwright versions. `@playwright/test` sat at `^1.49.1` (resolving to 1.61.1) while `playwright-core` was pinned `^1.62.0` and `@guidepup/playwright` peer-requires `^1.57.0`. Bumped `@playwright/test` to `^1.62.0`; `playwright-core` stays as a direct devDependency because `@axe-core/playwright` peer-depends on it, and both now resolve to 1.62.0
diff --git a/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/voiceover-verification.md b/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/voiceover-verification.md
new file mode 100644
index 00000000..ee0016a2
--- /dev/null
+++ b/openspec/changes/archive/2026-10-08-add-editor-aria-semantics/voiceover-verification.md
@@ -0,0 +1,586 @@
+# VoiceOver verification — manual run
+
+Covers tasks.md 7.3. **All 18 cases now run under
+`yarn test:e2e:voiceover`** (`packages/editorjs/e2e/tests/voiceover.spec.ts`) via
+[Guidepup](https://www.guidepup.dev/), which drives a real, running VoiceOver
+instance and reads back what it actually announces (macOS only, needs a headed
+browser; see that spec file's header comment and `e2e/README.md`).
+
+**All 18 cases assert, and all 18 pass.** Case 8 was the last one open — whether
+VoiceOver follows `aria-activedescendant` on the blocks holder — and a run
+settled it: **it does**. See its section below for the measured output.
+
+This document is still useful for two things: running the steps by hand to debug
+why an automated case failed, and recording what real runs established. Fill in
+Result/Notes for whichever cases you re-run, then summarize findings +
+follow-ups at the bottom.
+
+## Four findings that shaped these cases, and a fifth that broke the pattern
+
+Four times while automating these cases a test failed with more than one explanation
+available, and only some of them were our fault. Rather than pick one, each was
+settled by experiment — a scratch page varying a single attribute at a time for the
+first two, the failure output itself for the last two. All four answers are
+recorded under their cases below (3, 11, 15 and 17), and all four are **the opposite of what
+the obvious first guess would have been**:
+
+| Case | First guess | What was actually true |
+| --- | --- | --- |
+| 15 | the missing `aria-controls` is why the state isn't announced | `aria-controls` is irrelevant; `aria-haspopup` suppresses the state |
+| 17 | the `role="textbox"` this change introduced broke link announcement | a plain `contenteditable` behaves identically; the role is blameless |
+| 3 | an unnamed container is silent, so a *named* one is announced | the converse does not hold; container names never reach the browse cursor |
+| 11 | the tools are reachable only because VoiceOver hasn't re-navigated | the DOM is genuinely clean; VoiceOver retains them and no navigation clears it |
+
+Every one of them left the editor's markup unchanged. The pattern worth carrying forward: **when a
+VoiceOver assertion fails, the null hypothesis is that VoiceOver doesn't report the thing, not that
+the markup is missing it** — check the DOM-level assertion in `aria.spec.ts` first, and note that a
+clean DOM on its own does not distinguish "the element is gone from VoiceOver too" from "VoiceOver
+is still holding it", which is exactly the trap Case 11 fell into. The result tables under each
+case are the record; the scratch pages themselves were throwaway and are not kept in the repo.
+
+### The fifth finding, which broke that pattern
+
+A later run failed **seven cases at once** — 1, 2, 7, 11, 12, 13 and 15 — and this time it was the
+editor's fault, though still not the markup's. The block actions toolbar's roving tabindex called
+`preventDefault()` on `ArrowLeft`/`ArrowRight` whatever modifiers were held, and **VO+Right and
+VO+Left arrive as `Control`+`Option`+arrow**. Safari focuses a control when the VoiceOver cursor
+lands on it, so once a user's cursor reached the plus button the editor swallowed every attempt to
+move off it. That is a genuine trap for a VoiceOver user, and it is invisible to every
+attribute-level assertion in `aria.spec.ts`: the accessibility tree was correct throughout, and the
+*keyboard* was what was broken.
+
+Three things distinguish it from the four above, and are the tells to look for:
+
+- **Many unrelated cases failed together, with different-looking symptoms.** One case failing is
+  about that case. Several failing at once is one cause, and the cases that still *passed* named it
+  — every survivor was one that walks *to* the plus button.
+- **It was intermittent.** It only bites once the cursor has reached a toolbar control, so the run
+  before passed 16 of 17 on identical editor code. That reads as harness flakiness, and the
+  cursor-position rule from Case 8 actively pointed the wrong way.
+- **It was settled headlessly, in minutes, with no screen reader.** Playwright's failure snapshot
+  marked the plus button `[active]`; a headless mount showed focus is on `<body>` there, so
+  something had focused it; a scratch spec pressing `Control+Alt+ArrowRight` at the focused button
+  returned `defaultPrevented: true`. Prefer that to another six-minute VoiceOver run once a
+  mechanism is suspected.
+
+So the null hypothesis above holds for a *single* failing assertion about what VoiceOver says. It
+does not hold for a cluster, and it says nothing at all about what VoiceOver can *do* — keyboard
+interception is a class of bug this checklist can find and `aria.spec.ts` structurally cannot.
+The regression test still belongs in `aria.spec.ts` ("leaves modified arrow keys to their real
+owner"), because once you know the mechanism it needs no screen reader to assert.
+
+## Setup
+
+1. Start the e2e fixture: from `packages/editorjs/` run
+   `yarn vite --config e2e/vite.config.ts --port 4173 --strictPort`, then open
+   `http://localhost:4173` in **Safari** (VoiceOver's best-supported browser on
+   macOS — same reasoning as the existing webkit e2e target).
+2. Enable VoiceOver: `Cmd+F5` (or Cmd+Fn+F5 on newer keyboards).
+3. Reference commands (VO = `Control+Option`):
+   - `VO+Right`/`VO+Left` — move virtual cursor
+   - `Tab`/`Shift+Tab` — move DOM focus
+   - `VO+Space` — activate item under virtual cursor
+   - Arrow keys — navigate within a component once focus is inside it (menu, toolbar)
+   - `VO+Shift+Down` — enter an element's "interact"/forms mode; `VO+Shift+Up` to leave it
+   - `Cmd+F5` — toggle VoiceOver off when done
+
+## Case 1 — Blocks holder is a group, not a nested textbox (automated)
+
+**Steps:** With VoiceOver on, `VO+Right` from the top of the page until you reach the editor.
+
+**Expected:** You hear the paragraph announced **once**, as a text field ("Paragraph, text entry area") — not *text field → text field*, which is what a `contenteditable` holder without `role="group"` produces.
+
+**Observed:** VoiceOver never announces the holder at all. An unnamed `role="group"` is structurally transparent to the virtual cursor — it isn't a landmark and has no name to speak — so it's not a stop point (`VO+Left` from the paragraph is a no-op, and `VO+Shift+Up` from it exits the whole web content rather than stepping up into a group). This is the intended outcome, not a gap: the point of the role is to *stop* the holder being announced as an editable region, and it does. The `role="group"` attribute itself is asserted in `aria.spec.ts`; the automated Case 1 asserts the absence of any second text field around the paragraph.
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 2 — Paragraph block: name, role, multiline (automated)
+
+**Steps:** Navigate to the paragraph text and enter it (`VO+Shift+Down` or just click it).
+
+**Expected:**
+- Announced as "**Paragraph**, text field" (or "edit text") — the `aria-label`.
+- VoiceOver enters forms mode / "interact" mode without odd double-announcements.
+- Typing works normally and VoiceOver echoes typed characters as usual for a multiline field (not truncated to one line).
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 3 — Reaching the floating toolbar plus-button (automated)
+
+**Steps:** With the caret in the paragraph, tab to or `VO+Right` to the plus-button.
+
+**Expected:**
+- The button is announced as "**Add block**, button" (not "button" alone — it's icon-only, so a missing name would announce as unlabeled).
+- It's identifiable as part of a toolbar named "Block actions" (VoiceOver may announce this on entry to the group, e.g. "Block actions, toolbar"). **It is not — see Observed.**
+- It announces a popup relationship, e.g. "…menu, collapsed" (`aria-haspopup="menu"` / `aria-expanded="false"`). Note the state half of that never arrives — see Case 15.
+
+**Observed — the containing toolbar's name never reaches the browse cursor.** Walking with
+`VO+Right` goes from the block **straight onto the button in a single step**, announcing
+"Add block menu pop-up button". The whole route from the block to the button contains no mention
+of a toolbar, named or otherwise:
+
+| Stop | VoiceOver said |
+| --- | --- |
+| 1 | "Hello world, Paragraph, Type text or press Tab, text entry area" |
+| 2 | "Add block menu pop-up button" |
+
+This corrected an inference, not a regression. Case 1 establishes that the *unnamed* blocks holder
+is transparent to the virtual cursor because it has no name to announce, and the reasonable-looking
+converse — that a **named** container is therefore announced — does not hold for linear `VO+Right`
+navigation. Whether VoiceOver's group navigation or the rotor would surface it was not tested; the
+browse cursor is the path these cases are about.
+
+The name itself is correct and asserted at the DOM level in `aria.spec.ts`, so what's untestable
+here is VoiceOver's reporting of it, not the editor's markup — the same disposition as the
+`aria-expanded` finding in Case 15. The automated case pins the absence, so a VoiceOver version that
+starts announcing it fails and prompts this back into a real assertion.
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 4 — Opening and navigating the toolbox menu (automated)
+
+**Steps:** Activate the plus-button (`VO+Space` or click). Then arrow through the menu.
+
+**Expected:**
+- On open, VoiceOver announces entry into a **menu** named "Add block".
+- The plus-button's state now reads "expanded" if you check back on it.
+- The search field is announced as a **search field** (or edit text) named "Search".
+- Arrowing down lands on a **menu item** named "Text" (the paragraph tool's toolbox title).
+- Activating it (`Return`/`VO+Space`) inserts a new paragraph block and closes the menu; focus/VoiceOver cursor lands somewhere sensible afterward (not lost/stuck). The automated case asserts all three: the block count, that the menu is gone, and that focus is on a real element rather than `<body>`. *Which* element deliberately isn't pinned — that's the subject of the `test.fail()` todo in `aria.spec.ts` ("puts the caret in the block it just inserted").
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 5 — Inline toolbar: name, buttons, pressed state (automated)
+
+**Steps:** Type some text into a paragraph, select it (e.g. `Shift+Cmd+Right` or drag-select), and let the inline toolbar appear.
+
+**Expected:**
+- VoiceOver announces a **toolbar** named "Text formatting" appearing.
+- Arrowing/exploring it reaches buttons named "**Bold**" and "**Italic**".
+- After applying Bold and re-selecting the now-bold text, VoiceOver announces the Bold button's state from `aria-pressed="true"`; before that it announces no such state.
+
+**Observed:** VoiceOver never says "pressed" — it maps `aria-pressed` onto its own toggle vocabulary and reads the applied button as "**Bold selected, toggle button**" (with the shortcut, e.g. "Bold ⌘+B"). An unpressed button is the same phrase without "selected".
+
+**Watch out when automating this:** the toolbar only exists while text is *selected*, so a bare
+match on the word "selected" can be satisfied by VoiceOver describing the selection rather than
+the button — passing without the state being exposed, and failing when it is. The automated case
+anchors the word to the tool's own name, close enough that the two have to belong to the same
+announcement (wide enough for the shortcut VoiceOver reads in between).
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 6 — Entering the inline toolbar via Tab (automated)
+
+Originally reported as broken: pressing Tab while text was selected just moved the
+selection instead of reaching the toolbar. Fixed upstream in `@editorjs/ui-kit` (each
+inline-toolbar button is individually tabbable while the popover is open) — this is
+now the **primary, recommended** path into the toolbar for keyboard/AT users, since it
+moves real DOM focus and VoiceOver announces real focus reliably (unlike the
+arrow-key/`aria-activedescendant` path in Case 8).
+
+**Steps:** Select some text so the toolbar appears, then press `Tab`.
+
+**Expected:**
+- Real focus (and the VoiceOver cursor) lands on the **Bold** button; it's announced
+  as "Bold, button" (not silence, not "not pressed" appearing out of nowhere on the
+  wrong element).
+- Pressing `Tab` again moves to the next button (e.g. Italic, then Link); `Shift+Tab`
+  moves backward the same way. The automated case asserts the second Tab lands on another
+  of the toolbar's own buttons and is announced as one, and that `Shift+Tab` returns to
+  Bold — but not *which* tool is second, since tab order among the tools isn't asserted
+  anywhere and hardcoding it here would make reordering them a test failure.
+- The text selection itself may visually dim once focus leaves it (expected/normal —
+  this no longer causes the toolbar to close, see Case 9).
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 7 — Toolbar-available announcement (automated)
+
+New: since the toolbar can appear without moving focus or the VoiceOver cursor,
+nothing previously told a VoiceOver user it exists or that Tab now leads somewhere new.
+A live region now announces its appearance once per open.
+
+**Steps:** Select some text so the toolbar appears for the first time. Then, without
+letting the toolbar close, extend or shrink the selection by one character (e.g.
+`Shift+Right`/`Shift+Left`) a few times while it stays open.
+
+**Steps (continued):** finally, collapse the selection so the toolbar closes, then select
+text again.
+
+**Expected:**
+- On first appearance, VoiceOver announces something like "**Text formatting toolbar
+  available. Press Tab to enter.**"
+- Extending/shrinking the still-open selection does **not** repeat the announcement —
+  it should only fire once per genuine open, not on every selection tweak (which would
+  otherwise spam VoiceOver during a drag-select).
+- Closing and reopening the toolbar **does** announce it again. This is the half that the
+  "does not repeat" checks can't fail in: `InlineToolbarUI#show` only announces on a genuine
+  hidden-to-shown transition, so a regression that left its visibility state stuck would make
+  the toolbar silent for the rest of the session while every no-repeat assertion still passed.
+  Covered in both `voiceover.spec.ts` (Case 7) and `aria.spec.ts` (at the live-region level).
+
+**Regression to watch:** the live region must stay mounted across popover re-renders. It was
+originally re-inserted on every render (`replaceChildren`) right before being written to — a
+region that isn't already in the accessibility tree when its text changes is unreliable across
+assistive tech. The automated case asserts the announcement was *both* filled into the DOM and
+reached VoiceOver, so either half regressing is caught.
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 8 — Inline toolbar arrow-key navigation without losing the selection (automated, **passing**)
+
+DOM focus deliberately never moves onto the inline toolbar buttons via arrow keys (it
+would drop the text selection in WebKit), so the highlighted item is only exposed via
+`aria-activedescendant` on the blocks holder. Whether VoiceOver actually follows
+`aria-activedescendant` set on a `contenteditable` `role="group"` ancestor — rather
+than on the focused element itself in the way AT usually expects — is genuinely
+uncertain. This is now a **secondary** path (Case 6's Tab entry is the reliable one),
+so a gap here is lower-severity than it would otherwise be, but still worth recording.
+
+> **This case was never run, and while it sat unrun the markup it covers was broken.**
+> `aria-activedescendant` named an element that is not in the focused element's subtree —
+> `EditorjsUI` appends the inline toolbar as a *sibling* of the blocks holder — which makes
+> the reference invalid per ARIA and silently dropped rather than followed. It is fixed
+> (`aria-owns` now claims the popover; see design.md), but the fix is verified only at the
+> DOM level in `aria.spec.ts`. **Whether VoiceOver follows the reference once it resolves is
+> still exactly what this case is for, and is still unanswered.**
+>
+> Worth noting what this cost: the case was left manual because the question looked like one
+> only a screen reader could settle. It wasn't — the reference was invalid on structure alone,
+> checkable in any browser without VoiceOver running, and the automated suite asserted the
+> attribute's *value* instead of whether it resolved, so it passed throughout. When a case is
+> deferred to a screen reader, it is worth asking first whether some part of it is decidable
+> without one.
+
+**Steps:** With text selected and the inline toolbar visible, press arrow keys to move through the toolbar buttons (do **not** click or Tab — use the same arrow-key path the automated test uses).
+
+**Expected:**
+- VoiceOver's focus ring / announcement moves through "Bold", "Italic", etc. as you press arrow keys, *without* the browser's DOM focus actually leaving the text (the text selection should still be visibly highlighted throughout).
+- If VoiceOver does **not** announce the highlighted button at all (silence, or it just re-announces the paragraph/group), note it as a known gap rather than a regression — Case 6 (Tab) is the path that must work.
+
+**Precondition (automated, passing):** `aria.spec.ts` asserts on both engines that the element
+holding focus exposes `aria-owns` naming the popover, and that the item named by
+`aria-activedescendant` sits inside it — so the reference resolves before this case is run. If
+that assertion is failing, fix it first; there is nothing for VoiceOver to follow until it passes.
+
+**Result: ☑ Follows.** Settled by a real run, and now asserted in `voiceover.spec.ts` rather than
+left to a checklist. Measured output:
+
+| Arrow step | `aria-activedescendant` → | VoiceOver said |
+| --- | --- | --- |
+| 1 | `ce-popover-item-2` (Bold) | `Bold toggle button` |
+| 2 | `ce-popover-item-3` (Italic) | `Italic toggle button` |
+
+Selection `"Hello world"` before and after, unchanged.
+
+**VoiceOver does follow `aria-activedescendant` set on a contenteditable `role="group"`
+ancestor.** Each step is announced as the item the reference names, DOM focus never leaves the
+text, and the selection survives — which is the entire arrangement the inline toolbar depends on.
+The secondary path works, so it is no longer only Case 6's `Tab` entry carrying the toolbar.
+
+Three things this run also showed:
+
+- **"toggle button", not "button"** — `aria-pressed` reaches speech on this path too, from
+  ui-kit. Deliberately *not* asserted in Case 8: Case 5 & 6 owns the pressed state, and pinning it
+  here would make this case fail for a reason unrelated to its subject.
+- **Two arrow steps, not one, is what makes the result trustworthy.** `VO-Z` repeats the *last*
+  spoken phrase, so a single matching reading could have been VoiceOver echoing something said
+  before the arrow key arrived. Two steps naming different tools, each spoken in turn and neither
+  still mentioning the other, is what rules that out. The test keeps both steps for this reason.
+- **The announcement has to be waited for, not sampled once.** It is asynchronous and
+  unsignalled: the arrow key changes the reference, and VoiceOver speaks whenever its queue
+  reaches it. Asking `VO-Z` immediately after the keypress samples whatever was last *completed* —
+  on a loaded machine, still `"Hello world selected"` from the click that opened the toolbar,
+  which is how the first assertion-version of this case failed. It now polls `VO-Z` on a 1.5s
+  interval up to 20s, unhurried on purpose, since `VO-Z` is itself speech and hammering it would
+  interrupt the phrase being waited for.
+- **VoiceOver's cursor has to be put on the element first, and getting that wrong only shows up
+  in the full suite.** State is reported for the element VoiceOver's *own* cursor is on, and it
+  does not observe Playwright's synthesized events — so the click that made the selection left the
+  cursor wherever the previous case had it. Run alone, a fresh session's cursor was close enough
+  and the case passed; run after sixteen other cases it was not, and VoiceOver sat on
+  `"Hello world selected"` through the entire 20s poll. That failure is indistinguishable from
+  "the feature does not work" without knowing this. `syncCursorToFocus()` before the arrow presses
+  is the fix, and it is the rule the spec file's own header states; every other case that reads
+  VoiceOver back after a page-driven focus change already followed it. The failure message now
+  reports where the cursor was, so the next occurrence names its own cause.
+
+**How this case stayed open so long is the lesson worth keeping.** It was recorded as a genuinely
+unknowable question about screen reader behaviour. It wasn't: the reference named an element
+outside the focused subtree, so nothing could have followed it, and that was checkable in any
+browser with no screen reader running. The uncertainty was a broken-markup bug wearing the costume
+of an open question — and the automated suite reported success throughout, because it asserted the
+attribute's *value* instead of whether it resolved.
+
+## Case 9 — Link tool: activating opens the URL input, doesn't close the toolbar (automated)
+
+Originally reported as broken: activating the Link button just closed the whole
+toolbar instead of opening its URL input. Root cause was the toolbar tearing itself
+down when a button taking real focus collapsed the native text selection; fixed by
+not treating focus moving to the toolbar's own controls as "the user dismissed it".
+
+**Steps:** Select text, reach the **Link** button (via Tab, per Case 6, or click), and activate it.
+
+**Expected:**
+- A nested "**Add a link**" text input appears and the toolbar itself stays open — it
+  does not disappear.
+- The input is reachable/focusable and announced sensibly (e.g. "Add a link, text
+  field").
+- Typing a URL and pressing `Enter` applies the link and the toolbar/focus lands
+  somewhere sensible afterward (not lost/stuck, not silently reverted).
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 10 — After applying a tool, focus doesn't land on stray "invisible" content (automated)
+
+Originally reported as: after applying a tool, VoiceOver's focus seemed to jump to
+"the whole page", announcing something like "zero width space and 2 more items,
+group". Root cause was a workaround `<span>` (used to stop Safari deleting empty
+blocks) that was visually hidden but not hidden from the accessibility tree; combined
+with the toolbar-teardown bug from Case 9. Both are now fixed.
+
+**Steps:** Select text, apply Bold (via Tab + `Space`/`Return`, or click). Then explore
+around the block with VoiceOver (`VO+Right`/`VO+Left`) a few times.
+
+**Expected:**
+- VoiceOver never announces "zero width space" or reads out invisible placeholder
+  content as if it were part of the document.
+- After applying the tool, VoiceOver's cursor/focus lands somewhere coherent — back in
+  the paragraph text, or on the toolbar — not on the blocks holder as an undifferentiated
+  "group" with phantom extra items.
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 11 — Dismissing the inline toolbar (automated)
+
+**Steps:** Tab into the toolbar, then click elsewhere / collapse the selection to dismiss it. Then
+explore the editor with `VO+Right` from the top.
+
+**Expected:** The user is put back in their document — the cursor lands on the block's own content,
+not stranded on a control that no longer does anything — and nothing announces a phantom
+`aria-activedescendant` reference.
+
+**Observed — the tools stay reachable, and that is VoiceOver's residue, not the editor's.** A sweep
+of the editor after dismissal still reaches an item whose entire text is "bold". This was
+originally noted while writing Case 17, then mistakenly rewritten as "VoiceOver is answering from a
+stale tree" on the strength of the DOM being clean — and re-established by this case failing:
+
+| Checked | Result |
+| --- | --- |
+| Inline popover still in the DOM after dismissal? | **No** — `#hide()` destroys it, which detaches it |
+| Bold exposed to `getByRole` after dismissal (chromium + webkit)? | **No** — count 0, both engines, whether or not Tab moved focus into the toolbar first |
+| Bold reachable by VoiceOver's cursor after dismissal? | **Yes** |
+| Does `resetCursor()` (`navigateToWebContent()` + round trip) clear it? | **No** |
+
+The clean DOM is consistent with both explanations, which is what made the wrong one look settled.
+The editor has done everything available to it; there is no navigation that makes the absence
+observable from VoiceOver, so this case asserts where the user ends up instead. The DOM half is
+covered headlessly by `aria.spec.ts` ("takes its tools out of the accessibility tree when
+dismissed").
+
+**Consequence for Case 17, and for anything else scanning near a block:** bound the scan with
+`interact()`. Do not substitute "the toolbar is gone" for that — it's true and it doesn't help.
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 12 — Several blocks are separate text fields (automated)
+
+The first eleven cases all run against a document of exactly one block, where "the holder is not
+a second text field" (Case 1) is nearly vacuous. This is the case that actually exercises what
+per-block `role="textbox"` was added for.
+
+**Steps:** Mount a multi-block document — `http://localhost:4173/?text=Alpha&text=Beta&text=Gamma` —
+and `VO+Right` from the first block through the document.
+
+**Expected:**
+- Each block is announced as a text field of its own, named "Paragraph", carrying its own text.
+- You reach Alpha, then Beta, then Gamma, in document order.
+- No block is announced as inert text inside a larger editable region.
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 13 — An empty block says what belongs in it (automated)
+
+A `contenteditable` has no native `placeholder` attribute, so an empty block used to reach
+VoiceOver as an unlabelled empty field — nothing indicated the editor was ready for input or what
+to type. The paragraph tool now exposes its configured placeholder as `aria-placeholder`.
+
+**Steps:** Mount an empty document — `http://localhost:4173/?text=` — and put VoiceOver on the block.
+
+**Expected:** The block is announced as a "Paragraph" text field *and* the placeholder text
+("Type text or press Tab" in the fixture) is announced.
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 14 — Pressing Enter creates a block that is reachable (automated)
+
+**Steps:** Put the caret at the end of the paragraph and press `Enter`. Then explore forward with
+`VO+Right`.
+
+**Expected:** A second, empty text field exists and VoiceOver reaches and announces it separately
+from the first. The new block is empty, so what identifies it is the placeholder from Case 13 —
+"a text field that isn't the first one" would also be satisfied by the link tool's URL input or
+any other editable on the page, so the automated case matches on the placeholder instead.
+
+**Known gap — deliberately not asserted:** nothing announces the new block *at the moment it is
+created*. There is no live region for block creation and VoiceOver's cursor does not follow the
+caret, so a user pressing Enter hears nothing and only discovers the new block by exploring. Worth
+filing as follow-up work; the automated case asserts only that exploring finds it.
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 15 — Activating the plus-button takes you into the menu (automated)
+
+Originally written to check the other half of the `aria-expanded` round trip, which turned out not
+to be observable — see Observed.
+
+**Steps:** Reach the plus-button, activate it (`VO+Space`), then `VO+Left` back to the button while
+the menu is still open.
+
+**Expected:**
+- Activating the button lands the VoiceOver cursor inside the menu, on its search field.
+- The button stays reachable and named while the menu is open, so there is a way back to it.
+
+**Observed:** VoiceOver reads the button as "Add block menu pop-up button" whether the menu is open
+or closed — checked against both its item description and the phrase it actually speaks. The
+`aria-expanded` state never reaches speech. (The automated case pins the open announcement against
+the closed one on the **item description alone**: half of the fuller description is the last
+*spoken* phrase, which can still be describing the previous stop, so an exact match on it would
+fail on timing rather than on the state having changed.)
+
+**Why — resolved by experiment, not assumed.** `aria-haspopup` suppresses the state. Isolated on a
+scratch page varying one attribute at a time, five buttons deep:
+
+| Button | Markup | VoiceOver said |
+| --- | --- | --- |
+| Alpha | `aria-expanded="true"` | "Alpha **expanded** button" |
+| Bravo | `aria-expanded="false"` | "Bravo **collapsed** button" |
+| Charlie | `+ aria-haspopup="menu"` | "Charlie menu pop-up button" |
+| Delta | `+ aria-haspopup="menu" + aria-controls` → real `role="menu"` | "Delta menu pop-up button" |
+| Echo | `+ aria-haspopup="true"` (legacy) | "Echo menu pop-up button" |
+
+So VoiceOver supports `aria-expanded` perfectly well — it drops it the moment `aria-haspopup` is
+present, switching to the "pop-up button" role wording instead. **`aria-controls` does not restore
+it**, so the editor's missing button↔menu association is not the cause and adding one would not
+help here. This is a VoiceOver limitation, not a defect in our markup.
+
+**Not acted on, deliberately:** dropping `aria-haspopup` would make VoiceOver announce the state,
+but at the cost of the popup relationship — and other screen readers announce both correctly
+today, so optimising for VoiceOver would degrade them. The attributes stay as they are; the
+`aria-expanded` round trip is asserted in `aria.spec.ts` at the DOM level, on open and dismissal
+alike. If a future VoiceOver starts reporting state on pop-up buttons, this case can be tightened
+into the round-trip assertion it was originally meant to be.
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 16 — Dismissing the toolbox returns you to the plus-button (automated)
+
+Originally broken in Safari only: pressing `Escape` (or inserting a block) closed the toolbox and
+dropped DOM focus onto `<body>`, so the user lost their place in the editor. Safari does not focus
+a `<button>` when it is clicked, so the popover had captured `document.body` as the element to
+restore focus to. `ToolbarUI` now focuses the plus-button as it opens the toolbox.
+
+**Steps:** Open the toolbox from the plus-button, then press `Escape`.
+
+**Expected:**
+- The menu closes and focus is back on the plus-button, which is announced by name.
+- Its state reads collapsed again, not expanded.
+- Focus is never silently on the page body — nothing should feel like it "jumped to the whole page".
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 17 — Applied links sound like links (automated)
+
+Case 9 stops once the URL input is open. This covers the other end: a tool that changes how text
+*looks* has to change how it *sounds* too, or a screen-reader user has no way to know it's there.
+
+**Steps:** Select text, reach the Link button (Tab, per Case 6), activate it, type a URL and press
+`Enter`. Then move to the block and **interact with it** (`VO+Shift+Down`) before reading across
+it — reading it from outside with `VO+Right` will not do, see Observed.
+
+**Expected:** VoiceOver announces the formatted run as a link, not as plain text identical to
+before.
+
+**Observed — the path matters, and the reason is not our markup.** At the browse cursor VoiceOver
+reads an editable field's value flat and never announces roles inside it, so the block is read as
+"Hello world, Paragraph, text entry area" with no mention of a link. Interacting with the field
+reveals it. Isolated on a scratch page holding the same link in four containers, one per row:
+
+| Link inside | Announced at the browse cursor |
+| --- | --- |
+| ordinary `<p>` prose | yes |
+| non-editable `role="group"` | yes |
+| `role="textbox"` + `aria-multiline` + `contenteditable` (the editor's block) | no |
+| `contenteditable` with **no** explicit role | no |
+
+The last row is the one that matters: a plain `contenteditable` loses the link just as thoroughly,
+so **`role="textbox"` is not responsible and this change did not regress link announcement**. It is
+`contenteditable` itself, and it is VoiceOver's behavior for editable content rather than anything
+the editor can attribute its way out of.
+
+**Watch out when testing this by hand:** the inline toolbar's controls stay reachable to VoiceOver
+after the toolbar is dismissed (see Case 11 — the DOM is clean, VoiceOver's tree isn't, and
+re-navigating doesn't fix it), and their announcement is the bare tool name — the Link button reads
+as "link". Reading *past* the block will therefore find the word "link" from the control that
+applied the formatting rather than from the text. Interact with the block so the reading stays
+inside it.
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+## Case 18 — Filtered-out toolbox items are unreachable (automated)
+
+`@editorjs/ui-kit` 2.0.0 puts a `hidden` attribute on items the toolbox search filters out, not
+just a CSS class. This checks that the attribute does its job: a result the sighted user can no
+longer see must not still be reachable by the virtual cursor.
+
+**Steps:** Open the toolbox, type a query matching nothing into the search field, then explore the
+popover with `VO+Right`.
+
+**Expected:** No menu items are reachable while the query matches nothing (and they are, before you
+type — otherwise the check proves nothing).
+
+**Result:** ☐ Pass ☐ Fail
+**Notes:**
+
+---
+
+## Summary
+
+- **All 18 cases: passing in one run** against real VoiceOver, confirmed after the
+  modified-arrow-key fix. The run before it failed seven cases (1, 2, 7, 11, 12, 13, 15) on the
+  editor bug described in the fifth finding above; fixing it turned all seven green together,
+  which is what confirms the diagnosis — a harness-flakiness explanation would not have moved
+  them as a group. Cases 3, 11 and 15 reached the form recorded above during task 8.12, and
+  Case 8 was settled after the `aria-owns` fix. Re-run with `yarn test:e2e:voiceover`
+  (`packages/editorjs/e2e/tests/voiceover.spec.ts`).
+- **Case 8: ☑ Follows.** The last case with no result, now run and asserted. VoiceOver announces
+  each highlighted tool by name off `aria-activedescendant` alone, with the selection intact —
+  see the case above for the measured output.
+- Follow-ups outstanding before archiving:
+  - ~~**Publish `@editorjs/ui-kit` 2.0.0** and drop the local `link:` resolution~~ — done, see
+    tasks.md 5a.3. The lockfile resolves the published 2.0.0 and the suite was re-run against it.
+  - Per-block identity for `aria-label="Paragraph"` once more block types exist — design.md
+    Open Questions. Not blocking.
+  - Inline toolbar not scoped per editor on chromium. Pre-existing, pinned by a
+    per-engine `test.fail()`, wants its own change. Not blocking.
+- **Overall verdict: ☐ Needs follow-up work before archiving, ☑ Ship as-is.** Screen-reader
+  verification is complete: every case is automated, run, and passing in a single run, with no
+  manual checklist left. The dependency publish that was blocking has landed. The suite earned
+  its keep twice over — beyond settling Case 8, it caught a keyboard trap that no
+  attribute-level assertion could have seen.
diff --git a/openspec/specs/tools/spec.md b/openspec/specs/tools/spec.md
index 49482b2e..a6f7c8cb 100644
--- a/openspec/specs/tools/spec.md
+++ b/openspec/specs/tools/spec.md
@@ -96,3 +96,30 @@ The system SHALL have all inline tools (Bold, Italic, Link) implement the same c
 
 Cross-referenced across `packages/tools/bold/src/index.ts`, `packages/tools/italic/src/index.ts`, `packages/tools/inline-link/src/index.ts`, and validated indirectly by the generic facade test `packages/sdk/src/tools/facades/BaseToolFacade.spec.ts`.
 
+### Requirement: Accessible paragraph block
+`Paragraph` SHALL expose its contenteditable text element as an editable text field to assistive technology, via `role="textbox"`, `aria-multiline="true"`, and a non-empty `aria-label` identifying it as a paragraph block.
+
+#### Scenario: Paragraph contenteditable is an accessible textbox
+- **GIVEN** a `Paragraph` instance has lazily created its contenteditable `<div>`
+- **WHEN** the element is inspected
+- **THEN** it has `role="textbox"`, `aria-multiline="true"`, and a non-empty `aria-label`
+
+#### Scenario: Every block is exposed as a text field of its own
+- **GIVEN** the editor has rendered a document of several paragraph blocks
+- **WHEN** the accessibility tree is inspected
+- **THEN** each block exposes its own `role="textbox"` with its own accessible name
+- **AND** assistive technology can move between them in document order
+
+### Requirement: Paragraph placeholder is announced
+A contenteditable element has no native `placeholder`, so an empty block would otherwise be announced as an unlabelled empty field with no indication of what belongs in it. `Paragraph` SHALL expose the placeholder it is configured with (`config.placeholder`, which the editor fills from its own `placeholder` option for the default block tool) as `aria-placeholder` on its contenteditable element, and SHALL omit the attribute when no placeholder is configured.
+
+#### Scenario: Configured placeholder reaches assistive technology
+- **GIVEN** the editor is configured with a `placeholder` and `Paragraph` is the default block tool
+- **WHEN** an empty paragraph block's contenteditable element is inspected
+- **THEN** it has `aria-placeholder` set to the configured text
+
+#### Scenario: No placeholder configured
+- **GIVEN** the editor is configured without a `placeholder`
+- **WHEN** a paragraph block's contenteditable element is inspected
+- **THEN** it has no `aria-placeholder` attribute
+
diff --git a/openspec/specs/ui/spec.md b/openspec/specs/ui/spec.md
index cc8264a8..f62d03e7 100644
--- a/openspec/specs/ui/spec.md
+++ b/openspec/specs/ui/spec.md
@@ -106,3 +106,198 @@ The system SHALL provide `ToolboxUI`, a searchable popover of block tools popula
 
 Implemented in `src/Toolbox/Toolbox.ts`, `src/Toolbox/events/*`, `src/Toolbox/ToolboxConfigEntry.ts`.
 
+### Requirement: Accessible blocks holder
+`BlocksUI` SHALL expose its contenteditable blocks holder element as a structural container, via `role="group"` — the holder itself is not an editable region; each block owns its own `role="textbox"` and accessible name (see the `tools` spec's `Paragraph` requirement), which avoids nesting a `textbox` role inside another `textbox` role between the holder and its contenteditable block children.
+
+#### Scenario: Blocks holder exposes group role
+- **GIVEN** `BlocksUI` has rendered the blocks holder element
+- **WHEN** the element is inspected
+- **THEN** it has `role="group"`
+
+#### Scenario: Blocks holder does not nest an editable region
+- **GIVEN** the editor has rendered a single paragraph block
+- **WHEN** the accessibility tree beneath the blocks holder is inspected
+- **THEN** exactly one element exposes `role="textbox"` — the block's contenteditable element, not the holder
+
+### Requirement: Accessible floating toolbar
+`ToolbarUI` SHALL expose its actions container with `role="toolbar"` and an accessible name distinguishing it from the inline toolbar. Its plus-button control SHALL have an accessible name (`aria-label`) describing its action, and SHALL advertise the toolbox menu it controls via `aria-haspopup="menu"` and an `aria-expanded` state kept in sync with whether the toolbox is open.
+
+#### Scenario: Toolbar actions container has toolbar role
+- **GIVEN** `ToolbarUI` has rendered its actions container
+- **WHEN** the element is inspected
+- **THEN** it has `role="toolbar"` and a non-empty `aria-label`
+
+#### Scenario: Plus-button has an accessible name
+- **GIVEN** `ToolbarUI` has rendered the plus-button
+- **WHEN** the element is inspected
+- **THEN** it has a non-empty `aria-label`
+
+### Requirement: The block actions toolbar is a single tab stop
+`role="toolbar"` declares that the group is reached once by `Tab` and navigated internally with the arrow keys; a browser does not provide that on its own. `ToolbarUI` SHALL therefore maintain a roving tabindex over its own controls — exactly one in the tab order at a time, moved by the horizontal arrow keys — and SHALL declare its `aria-orientation`. Only the container's own controls take part: the toolbox popover renders *inside* the actions container, and its menu items are navigated by `@editorjs/ui-kit`, so keys arriving from within it are left alone.
+
+The pattern covers the **unmodified** arrow keys only. `ToolbarUI` SHALL ignore an arrow key pressed with any modifier held, and SHALL NOT call `preventDefault()` on it. A modified arrow always belongs to something else, and a screen reader is the case that matters here: VoiceOver moves its cursor with VO+Right and VO+Left, which reach the page as `Control`+`Option`+arrow. Swallowing those traps a VoiceOver user on whichever control their cursor reached, since Safari focuses a control when the cursor lands on it.
+
+#### Scenario: Modified arrow keys are left to their owner
+- **GIVEN** a control of the block actions toolbar holds focus
+- **WHEN** an arrow key is pressed with `Control`+`Option`, `Meta`, or `Shift` held
+- **THEN** the toolbar does not handle it and the event is not prevented
+- **AND** an unmodified arrow key is still handled by the toolbar
+
+#### Scenario: Only one control is in the tab order
+- **GIVEN** `ToolbarUI` has rendered its actions container
+- **WHEN** its controls are inspected
+- **THEN** exactly one of them has `tabindex="0"` and the rest have `tabindex="-1"`
+- **AND** the container declares `aria-orientation`
+
+#### Scenario: Toolbox keyboard navigation is not intercepted
+- **GIVEN** the toolbox has been opened from the plus-button
+- **WHEN** the user presses a vertical arrow key inside the menu
+- **THEN** the toolbox handles it and moves focus between menu items, unaffected by the toolbar's own arrow-key handling
+
+#### Scenario: Plus-button reports the toolbox state
+- **GIVEN** the toolbox is closed
+- **WHEN** the plus-button is inspected
+- **THEN** it has `aria-haspopup="menu"` and `aria-expanded="false"`
+- **WHEN** the plus-button is activated and the toolbox opens
+- **THEN** its `aria-expanded` becomes `"true"`
+- **WHEN** the toolbox is dismissed
+- **THEN** its `aria-expanded` returns to `"false"`
+
+### Requirement: Focus returns to the control that opened the toolbox
+Following the WAI-ARIA menu button pattern, dismissing the toolbox SHALL return DOM focus to the plus-button that opened it, so that keyboard and screen-reader users keep their place in the editor. `ToolbarUI` SHALL therefore move focus onto the plus-button when it opens the toolbox — Safari does not focus a button when it is clicked, which would otherwise leave the popover with `document.body` as the element to restore focus to.
+
+#### Scenario: Dismissing the toolbox restores focus
+- **GIVEN** the toolbox has been opened from the plus-button
+- **WHEN** the user presses `Escape`
+- **THEN** the toolbox closes and DOM focus is on the plus-button
+
+#### Scenario: Inserting a block does not lose focus
+- **GIVEN** the toolbox has been opened from the plus-button
+- **WHEN** the user activates a menu item and a block is inserted
+- **THEN** DOM focus is on a named control within the editor, not on the document body
+
+### Requirement: Toolbox search hides filtered-out items from assistive technology
+Filtering the toolbox by its search field SHALL remove non-matching items from the accessibility tree — not only hide them visually — so that assistive technology cannot reach a result the sighted user can no longer see. The `hidden` attribute that achieves this is applied by `@editorjs/ui-kit`.
+
+#### Scenario: Filtered-out items leave the accessibility tree
+- **GIVEN** the toolbox is open and exposes its block tools as menu items
+- **WHEN** the user types a query that matches none of them
+- **THEN** no `role="menuitem"` element remains exposed
+- **WHEN** the query is changed to one that matches again
+- **THEN** the matching item is exposed once more
+
+### Requirement: Accessible toolbox menu
+`ToolboxUI` SHALL name the menu its popover renders, so that the list of block types is announced as a named menu. The accessible names of the individual items and the `menu`/`menuitem` roles are produced by `@editorjs/ui-kit` from the `title` each tool is registered with.
+
+#### Scenario: Toolbox exposes a named menu of block types
+- **GIVEN** the toolbox has been opened
+- **WHEN** the accessibility tree is inspected
+- **THEN** a `role="menu"` element with a non-empty accessible name is exposed
+- **AND** each registered block tool is exposed as a `role="menuitem"` named after its toolbox title
+
+#### Scenario: Toolbox items are operable by keyboard
+- **GIVEN** the toolbox has been opened
+- **WHEN** the user presses `ArrowDown`
+- **THEN** DOM focus moves onto the first menu item
+- **WHEN** the user presses `Enter`
+- **THEN** the corresponding block is inserted
+
+### Requirement: Accessible inline toolbar
+`InlineToolbarUI` SHALL name the toolbar its popover renders, so that it is distinguishable from the block actions toolbar. The inline popover does not move DOM focus onto its buttons — doing so drops the text selection the inline tools operate on — so `InlineToolbarUI` SHALL mirror the item highlighted by keyboard navigation onto `aria-activedescendant` of the element that holds focus, and SHALL clear it once nothing is highlighted or the toolbar is dismissed.
+
+`aria-activedescendant` is only resolved when it names an element inside the focused element's subtree, or one the focused element claims via `aria-owns`. The toolbar is rendered as a *sibling* of the blocks holder, so setting the reference alone leaves it pointing outside the focused subtree, where assistive technology drops it. `InlineToolbarUI` SHALL therefore claim its popover via `aria-owns` on the same element, set and cleared together with the reference so the two cannot disagree. This re-parents the popover in the accessibility tree only — the DOM, and hence the text selection the inline tools operate on, is untouched.
+
+The element carrying the pair SHALL be one inside the editor this toolbar belongs to. On a page with more than one editor, a toolbar that has been raised for a selection in another instance would otherwise claim its own popover from that instance's holder, telling assistive technology that controls operating on one document belong to another.
+
+The accessible names of the individual buttons, their `button` role and their `aria-pressed` state are produced by `@editorjs/ui-kit` from the `title` and `isActive` each inline tool already provides.
+
+#### Scenario: Inline toolbar exposes named formatting buttons
+- **GIVEN** a range of text is selected
+- **WHEN** the accessibility tree is inspected
+- **THEN** a `role="toolbar"` element with a non-empty accessible name is exposed
+- **AND** each available inline tool is exposed as a `role="button"` named after its title
+
+#### Scenario: Inline tool reports whether it is applied
+- **GIVEN** a range of unformatted text is selected
+- **THEN** the bold button exposes `aria-pressed="false"`
+- **WHEN** the bold tool is applied and the text is selected again
+- **THEN** the bold button exposes `aria-pressed="true"`
+
+#### Scenario: Highlighted inline tool is announced without taking focus
+- **GIVEN** the inline toolbar is shown for a text selection
+- **WHEN** the user navigates the toolbar with the arrow keys
+- **THEN** the element holding focus exposes `aria-activedescendant` referencing the highlighted button
+- **AND** the text selection is preserved
+- **WHEN** the toolbar is dismissed
+- **THEN** `aria-activedescendant` is removed
+
+#### Scenario: The reference is not claimed from outside the editor
+- **GIVEN** the inline toolbar has an item highlighted by keyboard navigation
+- **WHEN** the element holding focus belongs to a different editor instance, or to no editor at all
+- **THEN** neither `aria-activedescendant` nor `aria-owns` is written onto it
+
+#### Scenario: The highlighted item is reachable from the element holding focus
+- **GIVEN** the inline toolbar is shown and an item has been highlighted by keyboard navigation
+- **WHEN** the reference is resolved from the element holding focus
+- **THEN** that element also exposes `aria-owns` naming the popover
+- **AND** the element named by `aria-activedescendant` is inside the popover so named
+- **AND** it is *not* a DOM descendant of the element holding focus, the relationship being an accessibility-tree one only
+- **WHEN** the toolbar is dismissed
+- **THEN** `aria-owns` is removed alongside `aria-activedescendant`, leaving no claim on a destroyed popover
+
+### Requirement: Inline toolbar announces its own availability
+The inline toolbar appears next to a text selection without moving DOM focus or the virtual cursor, so nothing otherwise tells a screen reader user that it exists or that `Tab` now leads somewhere new. `InlineToolbarUI` SHALL announce its appearance through a live region, which SHALL remain mounted across popover re-renders — a region that is not already in the accessibility tree when its text changes is unreliable across assistive tech.
+
+The announcement SHALL fire once per genuine open: not again while the toolbar stays open across selection changes, and again when the toolbar is dismissed and shown anew.
+
+The announcement is written on a short delay, so that an identical repeat still reads as a change to the region. A toolbar dismissed inside that delay SHALL NOT announce itself — the pending write is cancelled rather than allowed to describe a toolbar that is already gone.
+
+#### Scenario: A toolbar dismissed before the announcement lands stays silent
+- **GIVEN** the inline toolbar has just appeared and its announcement is scheduled but not yet written
+- **WHEN** the toolbar is dismissed before the delay elapses
+- **THEN** the live region is never filled with the announcement
+
+#### Scenario: Toolbar announces that it can be entered
+- **GIVEN** no inline toolbar is shown
+- **WHEN** a range of text is selected and the toolbar appears
+- **THEN** the toolbar's live region is filled with a message naming the toolbar and the key that enters it
+
+#### Scenario: Announcement does not repeat while the toolbar stays open
+- **GIVEN** the inline toolbar is shown for a text selection
+- **WHEN** the selection is extended or shrunk while remaining non-empty
+- **THEN** the toolbar's popover is rebuilt
+- **AND** no further announcement is made
+
+#### Scenario: Announcement repeats when the toolbar is genuinely reopened
+- **GIVEN** the inline toolbar has been shown and then dismissed
+- **WHEN** a range of text is selected again
+- **THEN** the announcement is made again
+
+### Requirement: The inline toolbar shown is the one built for the current selection
+Building the toolbar is asynchronous — every tool contributes an awaited `getToolbarConfig` — so two selection changes can be in flight at once and resolve in either order. `InlineToolbarUI` SHALL discard a build that was superseded while it was awaiting, rather than letting whichever finishes last take effect. A superseded build SHALL neither replace the popover nor reposition or re-announce the toolbar.
+
+This is an accessibility requirement and not only a rendering one: each tool's `isActive` and `onActivate` close over the range the build started from, so a stale build puts up buttons whose `aria-pressed` describes text the user has moved off, and which act on it when activated.
+
+Being dismissed counts as superseding: a build still awaiting when the toolbar is hidden SHALL NOT put it back up.
+
+#### Scenario: A superseded build does not take effect
+- **GIVEN** a toolbar build is awaiting its tools
+- **WHEN** a further selection change starts a build of its own and the first one resolves afterwards
+- **THEN** the popover in the document is the one built for the later selection
+- **AND** the earlier build neither repositions nor re-announces the toolbar
+
+#### Scenario: A build outstanding at dismissal does not resurrect the toolbar
+- **GIVEN** a toolbar build is awaiting its tools
+- **WHEN** the selection is dropped and the toolbar is hidden before the build resolves
+- **THEN** no popover is added to the document when it does
+
+### Requirement: Dismissed inline toolbar leaves the accessibility tree
+`InlineToolbarUI` SHALL remove its tools from the document when the toolbar is dismissed, rather than only hiding them visually. A control that is invisible but still exposed leaves a screen reader able to reach and activate a tool that is no longer available.
+
+Note that removal is the limit of what the editor controls: VoiceOver has been observed to keep reaching a dismissed tool after it has left the DOM, and no navigation clears it (recorded under Case 11 in `voiceover-verification.md`). The requirement is therefore stated over the document, which is verifiable, rather than over what any given screen reader will do with it.
+
+#### Scenario: Inline tools are removed once the toolbar is dismissed
+- **GIVEN** the inline toolbar is shown for a text selection
+- **WHEN** the selection is collapsed and the toolbar is dismissed
+- **THEN** no `role="button"` named after an inline tool remains exposed in the document's accessibility tree
+
diff --git a/packages/dom-adapters/package.json b/packages/dom-adapters/package.json
index 8fead328..da5c314b 100644
--- a/packages/dom-adapters/package.json
+++ b/packages/dom-adapters/package.json
@@ -34,7 +34,7 @@
     "typescript": "^5.5.4"
   },
   "dependencies": {
-    "@editorjs/dom": "^1.1.0",
+    "@editorjs/dom": "^1.2.0",
     "@editorjs/sdk": "workspace:^",
     "inversify": "^8.1.0",
     "reflect-metadata": "^0.2.2"
diff --git a/packages/editorjs/.gitignore b/packages/editorjs/.gitignore
index 854a697d..adc8b7e6 100644
--- a/packages/editorjs/.gitignore
+++ b/packages/editorjs/.gitignore
@@ -20,5 +20,11 @@ dist/*
 coverage/
 reports/
 
+# playwright
+/test-results/
+/playwright-report/
+/blob-report/
+/playwright/.cache/
+
 # stryker temp files
 .stryker-tmp
diff --git a/packages/editorjs/e2e/README.md b/packages/editorjs/e2e/README.md
new file mode 100644
index 00000000..2754bfb0
--- /dev/null
+++ b/packages/editorjs/e2e/README.md
@@ -0,0 +1,335 @@
+# e2e tests
+
+Playwright tests that drive a real Chromium instance against the fixture app in
+`e2e/fixtures/`, which mounts the actual `EditorJS` bundle (imported from `src/`,
+no build step required).
+
+Run with `yarn test:e2e` (or `yarn test:e2e:ui`). Vite serves the fixture; see
+`e2e/vite.config.ts` and `playwright.config.ts` for wiring. This runs
+`aria.spec.ts`, `editor.spec.ts`, and `axe.spec.ts` against chromium and
+webkit. It does **not** run `voiceover.spec.ts` — see below.
+
+## The suite tests `dist`, so it builds first
+
+The fixture imports this package's `src`, but that reaches `@editorjs/ui` and the
+tools through their package `exports` — which point at `dist`, not source. Editing
+`packages/ui/src` therefore changes nothing the suite can see until that package is
+rebuilt. Both playwright configs run `yarn build:dependencies` as part of their
+`webServer` command so this can't be got wrong, at the cost of a few seconds per run.
+
+This is worth knowing about rather than just relying on: it is a failure mode that
+lies in *both* directions. An unbuilt fix looks broken, and — more dangerously — an
+unbuilt regression looks fine. If you bypass the configs (`npx playwright test` against
+a server you started yourself, `reuseExistingServer` picking up a stale one), you are
+back to auditing whatever was built last.
+
+## Shared helpers (`e2e/support/`)
+
+`e2e/support/editor.ts` holds what every spec needs: `mountDocument`,
+`selectParagraphText`, `tabToInlineTool`, and the `PLACEHOLDER` the fixture
+configures. It sits outside `e2e/tests` so Playwright's default `testMatch`
+can't mistake it for a spec.
+
+## Fixture documents
+
+The fixture mounts one paragraph per `text` search param, so a test needing a
+document other than the default remounts with one:
+
+| URL | Document |
+| --- | --- |
+| `/` | a single `Hello world` block (the default every early test assumes) |
+| `/?text=Alpha&text=Beta` | two blocks, `Alpha` then `Beta` |
+| `/?text=` | a single empty block — how the placeholder tests get one |
+| `/?text=&placeholder=` | an empty block with **no** `placeholder` option set at all |
+| `/?editors=2` | two editors on one page, for anything that has to stay unique per instance |
+
+The fixture also configures the editor's `placeholder`, which reaches the
+paragraph tool as `config.placeholder` and is exposed as `aria-placeholder`.
+`?placeholder=` (empty) omits the option entirely, which is the only way to get a
+block that must *not* carry the attribute — `?placeholder=Something` overrides it.
+
+`?editors=2` is worth reaching for whenever the editor writes a document-wide
+`id`, since ARIA references (`aria-owns`, `aria-activedescendant`,
+`aria-labelledby`) resolve by `getElementById` across the *whole page*: an id
+that is unique within one editor but fixed across instances silently points the
+second editor's markup at the first editor's elements. Note this mode currently
+also exposes a scoping bug of its own — see the `test.fail()` on
+"gives each editor on a page its own inline toolbar" in `aria.spec.ts`.
+
+## Accessibility audits (`axe.spec.ts`)
+
+`@axe-core/playwright` runs a static WCAG-rule audit (missing accessible
+names, invalid roles, contrast, etc.) against the editor in its default,
+toolbox-open, and inline-toolbar-open states. It's part of the normal
+`test:e2e` run — no separate command. This catches a different class of bug
+than `aria.spec.ts`: axe flags anything that violates a rule regardless of
+whether a test happens to assert on it, but it can't tell you whether a
+screen reader announces the *right* thing — that's `voiceover.spec.ts`.
+
+Each audit waits for CSS animations to finish first. The popovers fade in over
+~100ms and axe samples computed styles when it runs, so an audit taken
+mid-animation measures a half-transparent panel and can report a contrast
+violation that isn't real. Violations are asserted as `id (impact): help`
+summaries rather than raw result objects, so a failure names the rule instead
+of burying it in serialised nodes.
+
+## Screen-reader tests (`voiceover.spec.ts`)
+
+`@guidepup/playwright` drives a real, running VoiceOver instance against
+Safari and exposes what it actually announced (`lastSpokenPhrase()`,
+`spokenPhraseLog()`) as assertable strings — this is the automated
+counterpart to `openspec/changes/add-editor-aria-semantics/voiceover-verification.md`.
+
+Run it with:
+
+```sh
+yarn test:e2e:voiceover
+```
+
+This needs its own config (`playwright.voiceover.config.ts`, `workers: 1`,
+headed) and is **macOS-only** — screen readers can't drive a headless
+browser and can't run more than one instance at a time, so it's excluded
+from `test:e2e` and isn't wired into CI (which doesn't run any of this
+package's e2e suite yet). Before the first run:
+
+```sh
+npx @guidepup/setup setup    # configure the machine for screen reader automation
+npx @guidepup/setup install  # install the screen reader assets Guidepup drives
+```
+
+### Settling an open question: measure first, then assert
+
+`Case 8` — whether VoiceOver follows `aria-activedescendant` on the blocks
+holder — sat unrun for the life of this change, on the grounds that a test
+asserting either outcome would just encode a guess. That reasoning is worth
+resisting, and the way out is a two-step one:
+
+1. **Land the case as a measurement.** Assert only the parts already known to
+   hold (the reference resolves, the selection survives), then *print* what
+   VoiceOver actually said. Such a test cannot fail for the wrong reason, and it
+   runs by command instead of by checklist.
+2. **Convert the reading into an assertion**, whichever way it landed — a
+   positive match, or a pinned absence in the style of Cases 3 and 15.
+
+Case 8 went through exactly this and came out positive: arrowing to Bold is
+announced `"Bold toggle button"`, arrowing on to Italic `"Italic toggle button"`,
+each naming the item the reference points at, with focus and selection untouched.
+
+Three details from that run worth reusing:
+
+- **Take two arrow steps, not one.** `VO-Z` repeats the *last* spoken phrase, so
+  a single match could be VoiceOver echoing something said before the key
+  arrived. Two steps naming different tools rules that out.
+- **Anchor to the name read off the element**, not to a hardcoded `"Bold"`.
+  Which tool a given press count lands on is ui-kit's business.
+- **Poll for the announcement; never sample it once.** Speech is asynchronous
+  and nothing signals its arrival, so a `VO-Z` issued straight after the action
+  returns whatever VoiceOver last *finished* saying — often the previous
+  announcement entirely. This case asserted correctly and still failed that way
+  once, reading back `"hello world selected"` from the click that opened the
+  toolbar. Poll `VO-Z` on a slow interval (1.5s here) so the repeat doesn't
+  interrupt the phrase you're waiting for, and let the timeout be what
+  distinguishes "never said it" from "hasn't said it yet".
+- **`syncCursorToFocus()` is not optional, and forgetting it fails only in the
+  full suite.** VoiceOver reports state — `aria-activedescendant` included — for
+  the element *its own cursor* is on, and it does not observe Playwright's
+  synthesized events, so a page-driven focus change leaves the cursor wherever
+  the previous test left it. Case 8 omitted the sync and passed in isolation,
+  where a fresh session's cursor happened to be close enough, then failed after
+  sixteen other cases had moved it: twenty seconds of polling with VoiceOver sat
+  on the stale phrase the whole time, which reads exactly like "the feature is
+  broken". **A VoiceOver case that passes alone and fails in the suite is a
+  cursor-position bug until proven otherwise.**
+
+That last rule has a limit, and the run after it found the limit. Seven cases
+failed at once, all of them stuck on the plus button, and none of it was the
+harness: the toolbar's roving tabindex handled `ArrowLeft`/`ArrowRight` with any
+modifiers held, and **VO+Right and VO+Left arrive as `Control`+`Option`+arrow**.
+Once VoiceOver's cursor reached the plus button — Safari focuses a control when
+the cursor lands on it — the editor swallowed every attempt to move off it. A
+VoiceOver user was trapped there. See "When the whole suite tilts" below.
+
+And the reason it stayed open so long: the markup was broken the whole time.
+`aria-activedescendant` named an element outside the focused subtree, which is
+invalid and unfollowable — checkable in any browser, with no screen reader
+running. Worth testing an "open question about AT behaviour" for the possibility
+that it is a bug in disguise.
+
+### Three VoiceOver behaviors the cases are built around
+
+Each was established by experiment, because the failing case had more than one
+available explanation and only some of them were the editor's fault. In all
+three the markup turned out to be correct and VoiceOver simply doesn't report
+the thing — which is the null hypothesis worth starting from when one of these
+fails. Full results are recorded per case in `voiceover-verification.md`.
+
+- **`aria-haspopup` suppresses `aria-expanded` in VoiceOver.** A plain button
+  announces "expanded"/"collapsed" fine; add `aria-haspopup` in any form and it
+  switches to "pop-up button" and drops the state. `aria-controls` does not
+  restore it. So Case 15 asserts what VoiceOver does expose instead of the state.
+- **`contenteditable` suppresses link announcement at the browse cursor** — not
+  `role="textbox"`, which a plain contenteditable proves innocent. Links inside a
+  block are only announced once you interact with the field (`VO+Shift+Down`),
+  which is why Case 17 calls `voiceOver.interact()`.
+- **Container names don't reach the browse cursor.** `VO+Right` steps from the
+  block straight onto the plus button without ever announcing the `role="toolbar"`
+  named "Block actions" that contains it. Naming a container is not what makes it
+  reachable — an unnamed group being transparent (Case 1) does not imply a named
+  one is announced. Case 3 pins the absence rather than asserting the name.
+
+Cases 3 and 15 assert these absences rather than skipping them, so a future
+VoiceOver that starts reporting the state or the container name fails the suite
+and prompts the case back into a positive assertion.
+
+### When the whole suite tilts
+
+One case failing is usually about that case. **Several unrelated cases failing
+the same way is a product bug, and the shape of the failure names it.** Seven
+cases failed together here — cases 1, 2, 7, 11, 12, 13 and 15 — with three
+different-looking symptoms: reading the plus button where the paragraph should
+be, not finding a block that is plainly in the document, and a forward walk that
+never reached anything. One thing explains all three: VoiceOver's cursor could
+get onto the plus button and never get off. The editor was calling
+`preventDefault()` on `Control`+`Option`+arrow.
+
+Two things made it look like flakiness rather than a bug, and both are worth
+recognising next time:
+
+- **It was intermittent across runs.** It only bites once the cursor has landed
+  on a toolbar control, and whether a given `next()` step goes there or onto the
+  live region depends on VoiceOver's tree state. A previous full run passed 16
+  of 17 with the same code.
+- **Nothing in the editor's markup was wrong.** Playwright's failure snapshot
+  showed a correct accessibility tree — `group > textbox "Paragraph"`, then
+  `status`, then `toolbar > button "Add block"`. The tree was right and the
+  keyboard was broken, which is not a distinction an ARIA-attribute assertion
+  can make.
+
+What settled it took no screen reader at all: the snapshot marked the plus
+button `[active]`, a headless mount proved focus is on `<body>` there, and a
+scratch spec pressing `Control+Alt+ArrowRight` at a focused plus button showed
+`defaultPrevented: true`. **Reach for a headless probe of the mechanism before
+another VoiceOver run** — a real run costs six minutes and answers a narrower
+question. The regression test that came out of it lives in `aria.spec.ts`
+("leaves modified arrow keys to their real owner") rather than here, because the
+defect is a swallowed key and asserting it needs no screen reader.
+
+### Two traps when writing VoiceOver assertions
+
+- **VoiceOver answers from a stale tree until it re-navigates.** A change driven
+  from `page` — a click, a `fill()`, anything Playwright synthesises — is
+  invisible to VoiceOver until it runs a navigation command of its own, so a
+  scan taken straight afterwards can describe the page as it was before. Always
+  go through `resetCursor()`, which pairs `navigateToWebContent()` with the round
+  trip that refreshes it; mid-test resets need it as much as the initial mount
+  does. This is what makes Case 18 deterministic.
+- **A detached element is not an unreachable one, and item text for a control is
+  the bare tool name.** The dismissed inline toolbar's buttons stay reachable to
+  VoiceOver — it retains nodes the document has already dropped, and
+  `resetCursor()` does **not** clear them. This is not a leak in the editor:
+  `InlineToolbarUI#hide` destroys the popover, and `aria.spec.ts` proves the DOM
+  is clean afterwards on both engines. The residue is VoiceOver's, and there is
+  no navigation that makes it go away.
+
+  Since a control's item text is just its name (Link announces as `"link"`, Bold
+  as `"bold"`), any scan that walks *past* a block can match a control instead of
+  the content and pass with the content unchanged — which is how Case 17 passed
+  twice in three runs while asserting nothing. Bound the scan to the block with
+  `interact()`. Do not substitute "the toolbar is gone from the DOM" for that;
+  it's true and it doesn't help.
+
+You'll also need to grant the terminal/IDE running the tests Accessibility
+permissions (System Settings → Privacy & Security → Accessibility) the first
+time it tries to control VoiceOver. Running it takes over your screen and
+speaks through your speakers for the duration of the suite — it's a real
+screen-reader session, not a simulation.
+
+## Gotcha: `locator.press()` / `locator.selectText()` break caret tracking
+
+Editor.js nests a `contenteditable="true"` block (e.g. `.editorjs-paragraph
+[contenteditable="true"]`) inside the outer `.ejs-blocks` contenteditable host.
+The editor's input handling relies on the browser's *native* selection/caret
+state on that structure.
+
+`locator.press(key)` and `locator.selectText()` both call `element.focus()`
+programmatically on the specific (inner) element before acting. That JS-driven
+focus call bypasses the native click-to-place-caret flow and desyncs the
+editor's tracked caret/selection — keystrokes and selection-based UI (e.g. the
+inline toolbar) silently stop working, with no error thrown.
+
+**Fix:** interact the way a real user would — a real mouse `click()` (or
+`click({ clickCount: 3 })` to select a line) on the locator, then drive
+follow-up keys through the page-level `page.keyboard`, not `locator.press()`:
+
+```ts
+// caret placement / typing
+await paragraph.click();
+await page.keyboard.press('End');
+await page.keyboard.type('!');
+
+// text selection (for e.g. the inline toolbar)
+await paragraph.click({ clickCount: 3 }); // triple-click selects the paragraph
+```
+
+Avoid `locator.press()` and `locator.selectText()` anywhere in this suite.
+
+## Locators
+
+Use `getByRole`/`getByLabel` — every surface the suite touches is reachable by
+role now, including the popovers rendered by `@editorjs/ui-kit` (2.0.0+).
+
+| What | Locator |
+| --- | --- |
+| Blocks host | `getByRole('group')` |
+| Paragraph text (contenteditable) | `getByRole('textbox', { name: 'Paragraph' })` |
+| Floating toolbar | `getByRole('toolbar', { name: 'Block actions' })` |
+| Plus button | `getByRole('button', { name: 'Add block' })` |
+| Toolbox menu | `getByRole('menu', { name: 'Add block' })` |
+| Toolbox item | `getByRole('menuitem', { name: '<toolbox title>' })` (e.g. `Text`) |
+| Toolbox search | `getByRole('searchbox', { name: 'Search' })` |
+| Inline toolbar | `getByRole('toolbar', { name: 'Text formatting' })` |
+| Inline tool button | `getByRole('button', { name: '<tool title>' })` (e.g. `Bold`) |
+
+Both toolbars need their name in the locator: the block actions toolbar and the
+inline toolbar are both `role="toolbar"`, and only the name tells them apart.
+
+`aria.spec.ts` asserts each of these directly, so it doubles as the regression
+test for the semantics the other specs rely on.
+
+### Notes on the popover surfaces
+
+The toolbox and inline toolbar are rendered by `@editorjs/ui-kit`, which derives
+item roles and accessible names from params the editor already passes it — the
+toolbox item's `toolbox.title`, the inline tool's `hint.title`. Nothing in the
+markup needs to be targeted by class anymore, and
+`.ce-popover-item[data-item-name="…"]` selectors should not be reintroduced.
+
+Two behaviors worth knowing when writing tests against them:
+
+- **The toolbox moves real DOM focus.** `ArrowDown` focuses the first
+  `menuitem`, so `toBeFocused()` is a valid assertion and `Enter` activates it.
+- **The inline toolbar does not.** Moving focus to a button drops the text
+  selection in WebKit, so navigating it only moves a highlight; which item is
+  current is exposed via `aria-activedescendant` on the element that holds focus
+  (the blocks holder, being the outermost contenteditable). Wait for the toolbar
+  to be visible before pressing an arrow key — until the popover is rendered its
+  key handler is not listening and the arrow just collapses the selection.
+
+  The holder also carries `aria-owns` naming the popover while an item is
+  highlighted, and that is load-bearing rather than decorative: the toolbar is a
+  *sibling* of the holder in the DOM, and `aria-activedescendant` is only resolved
+  when it names something inside the focused element's subtree or claimed by it via
+  `aria-owns`. **Asserting the attribute's value is not asserting that it resolves.**
+  Matching `aria-activedescendant` against the button's `id` passes identically
+  whether or not assistive tech can follow it — which is exactly how the missing
+  `aria-owns` survived a full suite. Assert over the resolved relationship instead;
+  `aria.spec.ts` has the pattern.
+- **Dismissing the toolbox returns focus to the plus button**, on both the
+  `Escape` and the insert-a-block path, so `toBeFocused()` on the plus button is
+  the right assertion afterwards. This only works because `ToolbarUI` focuses the
+  button itself when opening — Safari does not focus a `<button>` on click, and
+  without it the popover restores focus to `<body>`. Assert it on webkit; chromium
+  never reproduced the bug.
+- **Search filtering removes items from the accessibility tree.** Filtered-out
+  items get a `hidden` attribute alongside the CSS class, so
+  `getByRole('menuitem')` drops to zero rather than matching invisible items.
diff --git a/packages/editorjs/e2e/cypress-test-inventory.md b/packages/editorjs/e2e/cypress-test-inventory.md
new file mode 100644
index 00000000..8d74c652
--- /dev/null
+++ b/packages/editorjs/e2e/cypress-test-inventory.md
@@ -0,0 +1,604 @@
+# Editor.js Cypress Test Inventory with Expected Behavior (source: codex-team/editor.js @ 4ea9eb38)
+
+_Generated by re-reading each Cypress test's actual assertions in the v2 source repo. For every test, the description after the colon states the concrete triggering action and observable outcome, not just the test's English name._
+
+## block-ids.cy.ts
+
+- Block ids
+  - Should generate unique block ids for new blocks: Typing into two paragraph blocks and adding a Header block via the toolbox, then calling `editor.save()`, results in every block in the saved output having an `id` of type `string`.
+  - should preserve passed ids: Rendering the editor with two blocks that each have an explicit `id` (via `render()`), then calling `editor.save()`, returns blocks whose `id` values match the originally supplied ids in the same order.
+  - should preserve passed ids if blocks were added: After rendering two blocks with explicit ids and pressing Enter inside the first block to insert a new block in between (typing "Middle block" into it), `editor.save()` returns data where `blocks[0].id` still equals the first original id and `blocks[2].id` still equals the second original id (the new middle block takes index 1).
+  - should be stored at the Block wrapper's data-id attribute: After rendering two blocks with explicit ids, each `div.ce-block` element in the DOM has a `data-id` attribute equal to the corresponding block's id, in order.
+
+## copy-paste.cy.ts
+
+- Copy pasting from Editor
+  - pasting
+    - should paste plain text: Clicking into the first block and firing a paste event with `text/plain: 'Some plain text'` results in the block's content containing that plain text.
+    - should paste inline html data: Pasting a `text/html` payload of `<p><b>Some text</b></p>` into a block results in the block's HTML containing `<b>Some text</b>`.
+    - should paste several blocks if plain text contains new lines: Pasting `text/plain` content `'First block\n\nSecond block'` (blank-line-separated) splits it into two separate `div.ce-block` elements whose text contents are `'First block'` and `'Second block'` respectively.
+    - should paste several blocks if html contains several paragraphs: Pasting `text/html` `'<p>First block</p><p>Second block</p>'` produces two separate `div.ce-block` elements with text contents `'First block'` and `'Second block'`.
+    - should paste using custom data type: Pasting a custom `application/x-editor-js` MIME payload containing a JSON array of two paragraph block descriptors produces two blocks whose text contents match the pasted data (`'First block'`, `'Second block'`).
+    - should parse block tags: Pasting `text/html` `'<h2>First block</h2><p>Second block</p>'` (with the Header tool registered) creates an `h2.ce-header` element containing "First block" and a `div.ce-paragraph` containing "Second block"; `editor.save()` confirms `blocks[0]` is type `header` with `data.text === 'First block'` and `data.level === 2`, and `blocks[1]` is type `paragraph` with `data.text === 'Second block'`.
+    - should parse pattern: Pasting a bare image URL as `text/plain` (with the Image tool registered) auto-converts the pasted text into an image block, rendering an `img` element whose `src` attribute equals the pasted URL.
+    - should not prevent default behaviour if block's paste config equals false: For a custom tool with `pasteConfig = false` whose rendered element has a native `paste` listener, pasting text into that element results in the native paste event handler being called with `defaultPrevented: false` (i.e., Editor.js does not call `preventDefault()` on paste for that block).
+  - copying
+    - should copy inline fragment: Selecting all text within a single block (via `{selectall}`) and firing a copy event yields empty clipboard data, since Editor.js only intercepts copy for multi-block/cross-block selections and otherwise lets the browser handle it natively.
+    - should copy several blocks: After typing into two blocks and selecting from the second block's start up through the first block (Shift+Up), firing copy produces clipboard data where `text/html` matches two `<p>` elements containing "First block" and "Second block", `text/plain` equals `'First block\n\nSecond block'`, and (after a tick, since it's set asynchronously) `application/x-editor-js` is a JSON array of two paragraph-tool entries with matching text.
+  - cutting
+    - should cut inline fragment: Selecting all text in a single block and firing a cut event yields empty clipboard data (same native-behavior fallback as inline copy).
+    - should cut several blocks: With two pre-existing paragraph blocks, selecting from the end of the last block up through the first (Shift+Up) and firing cut produces clipboard data with the same `text/html`, `text/plain`, and async `application/x-editor-js` JSON payload as the copy case, and afterward the editor DOM no longer contains "First block" or "Second block" text (the selected blocks were removed).
+    - should cut lots of blocks: With 50 pre-existing paragraph blocks, selecting all (`{ctrl+A}` twice) and firing cut produces an `application/x-editor-js` clipboard payload whose parsed JSON array has exactly 50 entries.
+
+## i18n.cy.ts
+
+- Editor i18n
+  - Toolbox
+    - should translate tool title in a toolbox: With an `i18n.messages.toolNames` dictionary mapping `Heading` to a translated string, opening the toolbox (clicking the block, then the plus button) shows the header entry's popover item (`[data-item-name=header]`) containing the translated text instead of the English default.
+    - should translate titles of toolbox entries: For a custom tool exposing two toolbox entries (`Title1`, `Title2`) and an `i18n.messages.toolNames` dictionary translating both, opening the toolbox shows the first matching popover item containing the translation of `Title1` and the last matching popover item containing the translation of `Title2`.
+    - should use capitalized tool name as translation key if toolbox title is missing: For a tool whose `toolbox.title` is an empty string, with a `toolNames` dictionary keyed on the capitalized tool name (`TestTool`), the toolbox popover item for that tool displays the dictionary's translated value, confirming the capitalized tool name is used as the fallback translation key.
+    - should translate tool name in Convert To: With a `toolNames` dictionary translating `Heading`, opening a paragraph block's Block Tunes menu and then the nested "Convert To" popover shows the header conversion option (`.ce-popover-item[data-item-name=header]` inside `.ce-popover--nested`) displaying the translated "Heading" text.
+  - Inline Toolbar
+    - should translate tool name in Convert To: With a `toolNames` dictionary translating `Heading`, selecting text in a paragraph to open the Inline Toolbar and then opening its "Convert To" nested popover shows the header option displaying the translated "Heading" text.
+
+## initialization.cy.ts
+
+- Editor basic initialization
+  - Zero-config initialization
+    - should create a visible UI: Creating an editor with an empty (zero) config renders a `div.codex-editor` element that is visible in the DOM.
+  - Configuration
+    - readOnly
+      - should create editor without editing ability when true passed: Creating the editor with `readOnly: true` results in the rendered `div.ce-paragraph` block element having a `contenteditable` attribute equal to `'false'`.
+    - style
+      - nonce
+        - should add passed nonce as attribute to editor style tag: Creating the editor with `style: { nonce: 'test-nonce' }` results in the injected `#editor-js-styles` `<style>` tag carrying a `nonce` attribute equal to `'test-nonce'`.
+
+## onchange.cy.ts
+
+- onChange callback
+  - should batch events when several changes happened at once: Typing "change" into a prefilled paragraph block and then pressing Enter triggers a single `onChange` invocation whose batched events are `[block-changed (index 0), block-added (index 1)]`, i.e. the text change and new-block insertion are delivered together.
+  - should filter out similar events on batching: Typing "first change", waiting, then typing "second change" into the same block results in `onChange` being called exactly once, matched against a single `block-changed` event for index 0 with `target.name === 'paragraph'` — repeated changes to the same block within a batch collapse into one event.
+  - should be fired with correct index on block insertion above the current (by pressing Enter at the start): Pressing Enter at the very start of the (only, empty) block fires `onChange` with a `block-added` event whose `target.name === 'paragraph'` and `index === 0`.
+  - should be fired with only single "block-added" event by pressing Enter at the end of a block: Pressing Enter at the end of a prefilled paragraph's text fires `onChange` exactly once, matching a `block-added` event.
+  - should be fired with correct index on block insertion after the current (by pressing enter at the end): Pressing Enter at the end of a prefilled paragraph fires `onChange` with a `block-added` event at `index === 1` (the new block after the current one).
+  - should be fired on typing into block: Typing "some text" into an empty block fires `onChange` with a `block-changed` event at `index === 0`.
+  - should be fired on block insertion with save inside onChange: With an `onChange` handler that itself calls `api.saver.save()`, clicking the block and using the plus-button toolbox to insert a Delimiter block fires a single batched `onChange` call containing `block-removed` (index 0, paragraph), `block-added` (index 0, delimiter), and `block-added` (index 1, paragraph) — confirming saving from within the callback doesn't break batching.
+  - should be fired on block replacement for both of blocks: Converting the current paragraph block into a Header block via the plus-button toolbox fires a batched `onChange` call containing `block-removed` (index 0, paragraph) followed by `block-added` (index 0, header).
+  - should be fired on tune modifying: With a prefilled Header block, opening its Block Tunes settings and clicking the 4th tune item fires `onChange` with a `block-changed` event at `index === 0`, `target.name === 'header'`.
+  - should be fired when block is removed: Deleting the only (paragraph) block via Block Tunes' delete action (clicked twice to confirm) fires a batched `onChange` call with `block-removed` (index 0) followed by `block-added` (index 0), since deleting the last remaining block causes a fresh empty block to be auto-inserted.
+  - should be fired when block is moved: With two paragraph blocks, clicking the last block's Block Tunes "move-up" action fires `onChange` with a `block-moved` event where `fromIndex === 1` and `toIndex === 0`.
+  - should be fired if something changed inside native input: Typing into a `<textarea>` inside a Code tool block fires `onChange` with a `block-changed` event at `index === 0`.
+  - should not be fired on fake cursor adding and removing: Clicking a block to open Block Tunes (which inserts a temporary "fake cursor") and then clicking away to close it (removing the fake cursor) results in `onChange` never being called (call count 0) after waiting past the mutation-observer batch timeout.
+  - should be fired when the whole text inside block is removed: Backspacing the entire single-character text of a paragraph block fires `onChange` with a `block-changed` event at `index === 0`.
+  - should not be fired when element with the "data-mutation-free" mark changes some attribute: For a mock tool whose root element has `dataset.mutationFree = 'true'`, programmatically setting a new attribute on that element does not trigger `onChange` at all (call count 0) after the batch timeout.
+  - should not be fired when mutation happened in a child of element with the "data-mutation-free" mark: With the mutation-free root element containing a child div, setting an attribute on the *child* element also does not trigger `onChange` (call count 0), since mutation-free status propagates to descendants.
+  - should not be fired when "characterData" mutation happened in a child of element with the "data-mutation-free" mark: With a contenteditable child element inside a mutation-free-marked wrapper, typing text into that child (a characterData mutation) does not trigger `onChange` (call count 0).
+  - should be called on blocks.clear() with removed and added blocks: Calling `editor.blocks.clear()` on an editor with two paragraph blocks fires a batched `onChange` call containing two `block-removed` events followed by one `block-added` event (the cleared editor gets a fresh empty block).
+  - should not be called on blocks.render() on non-empty editor: Calling `editor.blocks.render(...)` with new block data on an editor that already has two blocks does not fire `onChange` at all (call count 0) — `render()` bypasses the change-tracking/onChange mechanism.
+  - should be called on blocks.update() with "block-changed" event: Calling `editor.blocks.update(block.id, { text: 'Updated text' })` fires `onChange` with a `block-changed` event at `index === 0` whose `target.id` equals the updated block's id.
+  - should be fired when the whole text inside some descendant of the block is removed: For a custom tool whose element contains a nested contenteditable descendant with text `'a'`, clicking and clearing that nested contenteditable's content fires `onChange` with a `block-changed` event at `index === 0`.
+  - should not be called when editor is initialized with readOnly mode: Creating the editor directly with `readOnly: true` and prefilled data results in `onChange` never being called (call count 0) after waiting past the batch timeout.
+  - should not be called when editor is switched to/from readOnly mode: Calling `editor.readOnly.toggle(true)` and then `editor.readOnly.toggle(false)` on a normal-mode editor results in `onChange`'s call count remaining 0 after each toggle (past the batch timeout) — toggling read-only mode itself is not treated as a content change.
+
+## readOnly.cy.ts
+
+- ReadOnly API spec
+  - should return correct value for readOnly.isEnabled when editor initialized in normal mode: Creating an editor with default config results in `editor.readOnly.isEnabled === false`.
+  - should return correct value for readOnly.isEnabled when editor initialized in read-only mode: Creating an editor with `readOnly: true` results in `editor.readOnly.isEnabled === true`.
+  - should return correct value for readOnly.isEnabled when read-only mode toggled: On a normal-mode editor, calling `editor.readOnly.toggle()` flips `isEnabled` from `false` to `true`, and calling `toggle()` again flips it back from `true` to `false`.
+
+## sanitisation.cy.ts
+
+- Sanitizing
+  - Output should save inline formatting
+    - should save initial formatting for paragraph: Initializing the editor with a paragraph block whose data text is `'<b>Bold text</b>'` and calling `editor.save()` returns that block's `data.text` unchanged as `'<b>Bold text</b>'` (allowed inline tag is preserved, not stripped).
+    - should save formatting for paragraph: Typing "This text should be bold." into a block, selecting all, and clicking the inline toolbar's `[data-item-name="bold"]` button, then calling `editor.save()`, returns the block's `data.text` matching `<b>This text should be bold.(<br>)?</b>` — the applied bold formatting is preserved in saved output.
+    - should save formatting for paragraph on paste: Pasting `text/html` `'<p>Text</p><p><b>Bold text</b></p>'` and calling `editor.save()` returns `blocks[1].data.text` equal to `'<b>Bold text</b>'` — inline bold formatting from pasted HTML is preserved.
+  - should sanitize unwanted html on blocks merging: With two paragraph blocks, the second containing an unsanitized `<span id="taint-html">` (a tag not in the paragraph tool's sanitization config), placing the cursor at the start of the second block and pressing Backspace merges it into the first block; `editor.save()` then shows the merged block's `data.text` as `'First blockSecond XSS block'` — the merged text is sanitized and the disallowed `<span>` tag is stripped.
+
+## selection.cy.ts
+
+- Blocks selection
+  - should remove block selection on click: After typing into two blocks and selecting from the second block's start up through the first (Shift+Up, producing a cross-block selection), clicking elsewhere in the editor results in no `div.ce-block` element having the `.ce-block--selected` class — the selection is cleared.
+
+## utils.cy.ts
+
+- isFunction function
+  - should recognize sync functions: Calling `isFunction` on a normal `function` declaration and on a synchronous arrow function both return `true`.
+  - should recognize async functions: Calling `isFunction` on an `async function` declaration and on an async arrow function both return `true`.
+  - should return false if it isn't a function: Calling `isFunction` on a plain object, a number, and a string all return `false`.
+
+## api/block.cy.ts
+
+- BlockAPI
+  - .dispatchChange()
+    - should trigger onChange with corresponded block: after creating an editor with a mocked `onChange` spy and one paragraph block, calling `block.dispatchChange()` on the Block API obtained via `editor.blocks.getById(firstBlock.id)` causes the `onChange` spy to be called with the editor API and an event matching `{ type: BlockChangedMutationType, detail: { index: 0 } }`.
+
+## api/blocks.cy.ts
+
+- api.blocks
+  - .getById()
+    - should return Block API for existed id: `editor.blocks.getById(firstBlock.id)` returns a defined Block API object whose `.id` equals `firstBlock.id`.
+    - should return null for not-existed id: `editor.blocks.getById('not-existed-id')` returns `null`.
+  - .update()
+    - should update block in DOM: after `editor.blocks.update(idToUpdate, { text: 'Updated text' })`, the rendered `div.ce-block` element's text content in the DOM becomes `'Updated text'`.
+    - should update block in saved data: after calling `editor.blocks.update(...)` and waiting 100ms, `editor.save()`'s output has `blocks[0].data.text` equal to the new text.
+    - should update tune data when it is provided: creating an editor with a custom `exampleTune` tune and a block whose `tunes.exampleTune` is `'citation'`, calling `editor.blocks.update(blockId, null, { exampleTune: 'test' })` (data left `null`) results in `editor.save()` output's `blocks[0].tunes` JSON-equalling `{ exampleTune: 'test' }`.
+    - shouldn't update any block if not-existed id passed: calling `editor.blocks.update('wrong-id-123', { text: 'Updated text' })` rejects with an error whose `.message` is `Block with id "wrong-id-123" not found"`, and the original block's DOM text remains unchanged (`firstBlock.data.text`).
+  - .insert()
+    - should preserve block id if it is passed: calling `editor.blocks.insert('paragraph', { text: 'codex' }, undefined, undefined, undefined, undefined, 'test-id-123')` returns a defined Block API whose `.id` equals the explicitly passed `'test-id-123'`.
+  - .insertMany()
+    - should insert several blocks to passed index: `editor.blocks.insertMany([block1, block2], 0)` inserts both new blocks starting at index 0, so the resulting `.ce-block` DOM elements appear in order: "inserting block #1", "inserting block #2", then the pre-existing "first block".
+  - .convert()
+    - should convert a Block to another type if original Tool has "conversionConfig.export" and target Tool has "conversionConfig.import". Should return BlockAPI as well.: calling `editor.blocks.convert(existingBlock.id, 'convertableTool')` (target tool has `conversionConfig.import: 'text'`) results, after `editor.save()`, in exactly one block whose `type` is `'convertableTool'` and `data.text` matches the original text; the value returned by `convert()` itself matches a subset `{ name: 'convertableTool', id: <newBlockId> }`.
+    - should throw an error if nonexisting Block id passed: calling `editor.blocks.convert('WRNG_ID', 'convertableTool')` rejects with an error whose `.message` is `Block with id "WRNG_ID" not found`.
+    - should throw an error if nonexisting Tool name passed: calling `editor.blocks.convert(existingBlock.id, 'WRNG_TOOL_NAME')` rejects with an error whose `.message` is `Block Tool with type "WRNG_TOOL_NAME" not found`.
+    - should throw an error if some tool does not provide "conversionConfig": converting to a registered tool (`nonConvertableTool`) that doesn't define `conversionConfig` rejects with an error whose `.message` is `Conversion from "paragraph" to "nonConvertableTool" is not possible. NonConvertableTool tool(s) should provide a "conversionConfig"`.
+    - should pass tool config to the conversionConfig.import method of the tool: converting to a tool configured with `config: conversionTargetToolConfig`, whose `conversionConfig.import` returns `{ text: JSON.stringify(config) }`, results in `editor.save()` output's `blocks[0].data.text` equalling `JSON.stringify(conversionTargetToolConfig)`, proving the tool's static config object was passed into `import()`.
+
+## api/caret.cy.ts
+
+- Caret API
+  - .setToBlock()
+    - first argument
+      - should set caret to a block (and return true) if block index is passed as argument: after blurring focus by clicking the editor wrapper, calling `editor.caret.setToBlock(0)` returns `true` and the browser selection's range `startContainer` is contained within the first `.ce-block` element.
+      - should set caret to a block (and return true) if block id is passed as argument: calling `editor.caret.setToBlock(paragraphDataMock.id)` returns `true` and places the selection range inside the first `.ce-block` element.
+      - should set caret to a block (and return true) if Block API is passed as argument: calling `editor.caret.setToBlock(block)` with a Block API instance (from `editor.blocks.getById(...)`) returns `true` and places the selection range inside the first `.ce-block` element.
+    - offset
+      - should set caret at specific offset in text content: for plain text `'Plain text content.'`, calling `editor.caret.setToBlock(block, 'default', 5)` results in the selection range's `startOffset` equal to `5`.
+      - should set caret at correct offset when text contains HTML elements: for content `'1234<b>567</b>!'`, calling `setToBlock(block, 'default', 6)` results in the selection range's `startContainer.textContent` being `'567'` and `startOffset` equal to `2` (i.e., caret lands inside the bold text node, 2 chars in).
+      - should handle offset beyond content length: requesting an offset 10 chars past the end of the block's text content (`'1234567890'`) clamps the selection range's `startOffset` to the actual content length rather than throwing or overflowing.
+      - should handle offset in nested HTML structure: for nested content `'123<b>456<i>789</i></b>!'`, calling `setToBlock(block, 'default', 8)` results in the selection range's `startContainer.textContent` being `'789'` and `startOffset` equal to `2`, i.e., caret correctly resolves through nested `<b>`/`<i>` elements.
+
+## api/toolbar.cy.ts
+
+- api.toolbar
+  - *.toggleToolbox()
+    - should open the toolbox: calling `editor.toolbar.toggleToolbox(true)` makes the `div.ce-toolbox` element visible in the DOM.
+    - should close the toolbox: after `toggleToolbox(true)` makes the toolbox visible, calling `editor.toolbar.toggleToolbox(false)` hides it again (`div.ce-toolbox` not `:visible`).
+    - should toggle the toolbox: calling `editor.toolbar.toggleToolbox()` with no argument first makes the toolbox visible, and calling it again with no argument toggles it back to not visible.
+
+## api/tools.cy.ts
+
+- Editor Tools Api
+  - Toolbox
+    - should render a toolbox entry for tool if configured: for a tool with a single `toolbox` entry `{ title, icon }`, clicking a block then the `.ce-toolbar__plus` button renders exactly one `.ce-popover-item[data-item-name=testTool]`, whose `.ce-popover-item__icon` HTML contains the configured icon SVG.
+    - should render several toolbox entries for one tool if configured: for a tool whose `toolbox` is an array of two entries, opening the toolbox renders two `.ce-popover-item[data-item-name=testTool]` elements, with the first and last showing the respective entries' `title` text.
+    - should insert block with overridden data on entry click in case toolbox entry provides data overrides: clicking a toolbox entry configured with `data: dataOverrides` inserts a new block using that tool; after typing text into it and calling `editor.save()`, the resulting block's `data` deep-equals the override object merged with `{ text: <typed text> }` (overriding the tool's own default data).
+  - Tunes — renderSettings()
+    - should contain a single block tune configured in tool's renderSettings() method: for a tool whose `renderSettings()` returns a single `TunesMenuConfig` object (`name: 'testToolTune'`), inserting the tool's block, typing text, and clicking `.ce-toolbar__settings-btn` results in `[data-item-name=testToolTune]` existing in the tunes popover.
+    - should contain multiple block tunes if configured in tool's renderSettings() method: for a tool whose `renderSettings()` returns an array of two tune configs, opening block settings shows both `[data-item-name=testToolTune1]` and `[data-item-name=testToolTune2]` in the popover.
+    - should contain block tunes represented as custom html if so configured in tool's renderSettings() method: for a tool whose `renderSettings()` returns a raw `HTMLElement` containing `sampleText`, opening block settings results in `.ce-popover` containing that sample text.
+    - should support label alias: for tune config entries using either a `title` property or a `label` property to specify display text, opening block settings shows `[data-item-name=testToolTune1]` containing `'Test tool tune 1'` (from `title`) and `[data-item-name=testToolTune2]` containing `'Test tool tune 2'` (from `label`).
+  - Paste — pasteConfig()
+    - tags
+      - should use corresponding tool when the array of tag names specified: for a tool with `pasteConfig.tags: ['img']`, pasting HTML `'<img>'` into a block calls the tool's `onPaste` handler (verified via spy).
+      - should sanitize all attributes from tag, if only tag name specified: for `pasteConfig.tags: ['img']` (bare tag name, no sanitizer config), pasting `'<img src="foo" onerror="alert(123)"/>'` results in the `onPaste` event's `detail.data` being an `<img>` element with `attributes.length === 0` (all attributes, including `src`, stripped).
+      - should sanitize all attributes from tags, even if tag names specified in uppercase: for `pasteConfig.tags: ['OL', 'LI']` (uppercase names), pasting `'<ol start="50"><li>...</li><li>...</li></ol>'` yields a pasted `<ol>` element with zero attributes and exactly 2 `<li>` children, each also with zero attributes.
+      - should leave attributes if entry specified as a sanitizer config: for `pasteConfig.tags: [{ img: { src: true } }]`, pasting `'<img src="foo" onerror="alert(123)"/>'` yields a pasted `<img>` with only the `src` attribute retained (value `'foo'`) and `attributes.length === 1` (`onerror` stripped).
+      - should support mixed tag names and sanitizer config: for `pasteConfig.tags: ['video', { source: { src: true } }]`, pasting `'<video width="100"><source src="movie.mp4" type="video/mp4"></video>'` yields a pasted `<video>` with zero attributes and a nested `<source>` child retaining only its `src` attribute (`'movie.mp4'`).
+      - should support config with several keys as the single entry: for a single `tags` entry object `{ video: { width: true }, source: { src: true } }`, pasting the same video/source HTML yields a pasted element whose `<source>` child retains its `src` attribute value `'movie.mp4'`.
+      - should correctly sanitize Table structure (test for HTMLJanitor bug): for `pasteConfig.tags: ['table', 'tbody', { td: { width: true }, tr: { height: true } }]`, pasting `'<table><tr height="50"><td width="300">Ho-Ho-Ho</td></tr></table>'` yields a pasted `<table>` whose `<tr>` retains `height="50"` and whose `<td>` retains `width="300"` (regression test for an HTMLJanitor bug mis-sanitizing nested table markup).
+
+## api/tunes.cy.ts
+
+- Editor Tunes Api
+  - should render a popover entry for block tune if configured: for a Tune (`isTune = true`) whose `render()` returns a single `TunesMenuConfig` object (`name: 'testTune'`), typing text into a block and clicking `.ce-toolbar__settings-btn` results in `[data-item-name=testTune]` existing in the DOM.
+  - should render several popover entries for block tune if configured: for a Tune whose `render()` returns an array of two config entries, opening block settings shows both `[data-item-name=testTune1]` and `[data-item-name=testTune2]`.
+  - should display custom html returned by tune's render() method inside tunes menu: for a Tune whose `render()` returns a raw `HTMLElement` containing `sampleText`, opening block settings results in `.ce-popover` containing that sample text.
+  - should support label alias: for tune entries specifying text via either `title` or `label`, opening block settings shows `[data-item-name=testTune1]` containing `'Tune entry 1'` (from `title`) and `[data-item-name=testTune2]` containing `'Tune entry 2'` (from `label`).
+  - should display installed tunes above default tunes: for a custom tune registered via the `tunes` config option, opening block settings places the custom tune (`data-item-name="test-tune"`) as the first (`eq(0)`) item under `.ce-settings .ce-popover-item`, with the built-in `move-up` tune appearing immediately after it at index 1.
+
+## inline-tools/link.cy.ts
+
+- Inline Tool Link
+  - should create a link by Enter keydown in input: creates an editor with one paragraph block, selects all its text, presses Ctrl+K to open the inline link tool, types `https://codex.so` into the inline link input and presses Enter; asserts the block now contains an `a` element with `href="https://codex.so"`.
+  - should remove fake background on selection change: creates an editor with two paragraph blocks, selects all text in the first block and opens the link tool via Ctrl+K (which applies a fake selection background), then clicks into and selects text in the second block; asserts no `span[style]` (the fake-selection highlight element) remains anywhere in the paragraphs, confirming it's cleared when the selection moves elsewhere.
+  - should preserve link when applying bold to linked text: selects paragraph text, applies a link via the inline toolbar and URL input (confirming the resulting `a[href]`), then reselects the linked text and clicks the bold inline-toolbar button; asserts the block's `a` element still has the original `href` and now contains a nested `b` element wrapping the same text, i.e. bold nests inside the link without destroying it.
+  - should preserve bold and italic when applying link: selects paragraph text and applies bold (asserts a `b` containing the text), reselects that bold text and applies italic (asserts nested `b > i` containing the text), then reselects the bold+italic text and applies a link via the inline toolbar and URL input; asserts the final DOM is `b > i > a[href]` containing the original text, i.e. the link wraps innermost while both prior inline formats are preserved.
+  - should open a link if it is wrapped in another formatting: selects paragraph text and applies a link via the inline toolbar and URL input, then reselects the linked text and applies italic so the link is wrapped in an `i`; stubs `window.open`, then ctrl-clicks the italicized link text; asserts `window.open` was called with the link's original href, i.e. ctrl+click still opens the link even when it's nested inside other inline formatting.
+
+
+## modules/InlineToolbar.cy.ts
+
+- Inline Toolbar
+  - should appear aligned with left coord of selection rect: selects the entire text of a single-paragraph block, then asserts the visible inline toolbar's `offset().left` is within 1px of the current selection range's `getBoundingClientRect().left`.
+  - should appear aligned with right side of text column when toolbar's width is not fit at right: finds line-wrap positions in a long paragraph and selects the last 5 characters of the first wrapped line; asserts the toolbar's right edge (`offset().left + width()`) is within 10px of the paragraph wrapper's right edge, i.e. the toolbar flips to right-alignment instead of overflowing.
+  - should be displayed in read-only mode if at least one inline tool of block supports it: in `readOnly: true` mode with a header block whose `inlineToolbar` includes `bold` and a custom tool with `isReadOnlySupported = true`; selecting text opens the inline toolbar, and asserts it contains exactly one popover item, `data-item-name="test-tool"` (bold is excluded since it doesn't support read-only).
+  - should not submit form nesting editor when inline tool clicked: moves the editor DOM node inside a `<form>` with a stubbed `onsubmit`; selects text in a paragraph and clicks the `bold` inline-tool button, then asserts the form's `onsubmit` stub was never called.
+  - Conversion toolbar
+    - should restore caret after converting of a block: selects all text of a paragraph, clicks "convert-to" in the inline toolbar, then clicks the `header` option; asserts the block becomes a `.ce-header` with the same text, and that the current selection range's `startContainer` is contained within that new header element (caret preserved through conversion).
+  - Nested Editor instance inline toolbar
+    - should not close inline toolbar of the nested Editor instance when clicking within that toolbar: inside a nested Editor.js instance block, selects text and clicks the `link` inline tool, then clicks and (after a delay) types a URL into the resulting inline-tool input field; asserts the nested instance's `.ce-popover__container` inline toolbar remains visible instead of closing.
+
+## modules/Renderer.cy.ts
+
+- Renderer module
+  - should not cause onChange firing during initial rendering: creates an editor with two prefilled paragraph blocks and a spied `onChange`; asserts `onChange` was never called purely from initial rendering.
+  - should show Stub block if block tool is not registered: renders 3 blocks where the middle one has an unregistered type (`'non-existing tool'`); asserts 3 `.ce-block`s render and the middle block contains a `.ce-stub` whose `.ce-stub__title` text equals `'non-existing tool'`.
+  - should show Stub block if block tool throws error during construction: registers a tool (`failedTool`) whose constructor throws; asserts 3 blocks render and the middle one renders as a `.ce-stub` with title text `'failedTool'`.
+  - should insert default empty block when [] passed as data.blocks: creates an editor with `data.blocks: []`; asserts exactly 1 `.ce-block` is rendered (the auto-inserted default empty block).
+  - should insert default empty block when [] passed via blocks.render() API: creates an empty editor, then calls `editor.blocks.render({ blocks: [] })`; asserts exactly 1 `.ce-block` is present afterward.
+
+## modules/Saver.cy.ts
+
+- Saver module
+  - save()
+    - should correctly save block if there are some 3rd party (eg. browser extensions) nodes inserted into the layout: appends an arbitrary `<extension-node>` element directly into a paragraph block's `.ce-block__content` (simulating a browser extension), then calls `editor.save()`; asserts the result still has exactly 1 block whose `data.text` is unchanged (`'The block with some text'`).
+    - should correctly save block data if block's main container element have been changed: clicks a `header` block, opens its block tunes, and clicks the 3rd settings popover item to change the heading level (mutating the tool's root element); asserts `editor.save()` still returns type `'header'` with the original text but `data.level` updated to `3`.
+
+## modules/Tools.cy.ts
+
+- Tools module
+  - .prepare()
+    - should return Promise resolved to void: calling `prepare()` on a module built from an empty tools config resolves without throwing (caught error is `undefined`).
+    - should throw an error if tools config is corrupted: a tool entry set to the plain string `'value'` (invalid shape) causes `prepare()` to throw; the caught error is asserted to be an instance of `Error`.
+    - should call Tools prepare method with user config: registers a tool class with a stubbed static `prepare` and a `config` object; after `module.prepare()`, asserts the stub was called with exactly `{ toolName: 'withSuccessfulPrepare', config }`.
+  - collection accessors
+    - .available
+      - should return Map instance: `module.available` is an instance of `Map`.
+      - should contain only ready to use Tools: asserts `withSuccessfulPrepare` and `withoutPrepare` are present, while `withFailedPrepare` (prepare throws) and `unavailableInlineTool` (missing required inline-tool methods) are absent.
+    - .unavailable
+      - should return Map instance: `module.unavailable` is an instance of `Map`.
+      - should contain unavailable Tools: asserts `withFailedPrepare` and `unavailableInlineTool` are present, while `withSuccessfulPrepare` and `withoutPrepare` are absent.
+    - .inlineTools
+      - should return Map instance: `module.inlineTools` is an instance of `Map`.
+      - should contain only available Inline Tools: asserts `inlineTool` is present, `unavailableInlineTool` is absent, and every entry in the map reports `isInline()` true.
+    - .blockTools
+      - should return Map instance: `module.blockTools` is an instance of `Map`.
+      - should contain only available Block Tools: asserts `withSuccessfulPrepare`/`withoutPrepare` are present, `withFailedPrepare` is absent, and every entry reports `isBlock()` true.
+      - Block Tools should contain default tunes if no settings is specified: for `blockToolWithoutSettings` (registered as a bare class with no config object), its `.tunes` map contains `delete`, `moveUp`, and `moveDown`.
+      - Block Tools should contain default tunes: for `blockTool` (registered with only `inlineToolbar: true`), its `.tunes` map likewise contains `delete`, `moveUp`, `moveDown`.
+      - Block Tools should contain tunes in correct order: for `blockTool` (global tunes config `['blockTune2','blockTune']`), asserts its tunes map key order is exactly `['blockTune2','blockTune','moveUp','delete','moveDown']`; also checks `withSuccessfulPrepare` (own `tunes: ['blockTune2']`) has `blockTune2` but not `blockTune`, and `withoutPrepare` (`tunes: false`) has neither.
+      - Block Tools should contain inline tools in correct order: for `blockTool`, asserts its `.inlineTools` map key order is exactly `['inlineTool2','inlineTool']`; `withSuccessfulPrepare` (own `inlineToolbar: ['inlineTool2']`) has only `inlineTool2`, and `withoutPrepare` (`inlineToolbar: false`) has neither.
+    - .blockTunes
+      - should return Map instance: `module.blockTunes` is an instance of `Map`.
+      - should contain only available Block Tunes: asserts `blockTune` is present and `unavailableBlockTune` (prepare throws) is absent.
+    - .internal
+      - should return Map instance: `module.internal` is an instance of `Map`.
+      - should contain only internal tunes: every entry in `module.internal` has `isInternal` true.
+    - .defaultTools
+      - should return BlockTool instance: `module.defaultTool` (configured via `defaultBlock: 'withoutPrepare'`) is an instance of `BlockToolAdapter`.
+      - should return default Tool: `module.defaultTool.isDefault` is `true`.
+
+## modules/Ui.cy.ts
+
+- Ui module
+  - documentKeydown
+    - Backspace
+      - should remove selected blocks: with two paragraph blocks, clicks the first, extends selection to both via `{shift+downArrow}`, then presses Backspace; asserts `editor.save()` returns 0 blocks (the remaining single empty block is omitted from save output).
+    - Delete
+      - should remove selected blocks: same two-block setup and multi-block selection via `{shift+downArrow}`, then presses Delete (`{del}`); asserts `editor.save()` again returns 0 blocks.
+  - mousedown
+    - should update current block by click on block: with three paragraph blocks, clicks the second one; asserts `editor.blocks.getCurrentBlockIndex()` equals `1`.
+    - (in readonly) should update current block by click on block: same three-block setup but editor created with `readOnly: true`; clicking the second block still updates `getCurrentBlockIndex()` to `1`.
+
+## modules/BlockEvents/ArrowLeft.cy.ts
+
+- Arrow Left
+  - starting whitespaces handling
+    - &nbsp;| — should natively move caret over the visible space. Then move to the prev block: blocks are `'1'` and `'&nbsp;2'`; clicks the second block and presses `{leftArrow}` three times (before "2", across the nbsp, then into the previous block); asserts the final selection is inside the first `.ce-paragraph` with `startOffset` 1 (end of "1").
+    -  | — should ignore invisible space before caret and move caret to the prev block: blocks are `'1'` and `' 2'` (regular leading space); two `{leftArrow}` presses skip the invisible space entirely and land directly in the previous block; caret ends at offset 1 in the first paragraph.
+    - <b></b>| — should ignore empty tags before caret and move caret to the prev block: blocks are `'1'` and `'<b></b>2'`; two `{leftArrow}` presses skip the empty `<b>` tag and move into the previous block; caret ends at offset 1 in the first paragraph.
+    - <b></b>&nbsp;| — should move caret over the visible space and then to the prev block: blocks are `'1'` and `'<b></b>&nbsp;2'`; three `{leftArrow}` presses (before "2", over the nbsp, then into the previous block); caret ends at offset 1 in the first paragraph.
+    - &nbsp;<b></b>| — should ignore empty tag and move caret over the visible space. Then move to the prev block: **duplicate test bug in v2 source** — despite its title implying blocks `'1'` / `'&nbsp;<b></b>2'` (space before empty tag), the fixture is actually `['1', '<b></b>&nbsp;2']`, byte-for-byte identical to the preceding test. It performs the same three `{leftArrow}` presses (before "2", over the nbsp, into the previous block) and ends at offset 1 in the first paragraph — a copy-pasted duplicate, not a distinct case; the space-before-empty-tag ordering the title describes is never actually tested anywhere in this file.
+    -  &nbsp;| — should move caret over the visible space. Then move to the prev block: blocks are `'1'` and `' &nbsp;2'` (space then nbsp); three `{leftArrow}` presses (before "2", across the nbsp, then ignoring the regular space to land in the previous block); caret ends at offset 1 in the first paragraph.
+  - should move caret to the prev block if currently focused block is contentless (Delimiter): with paragraph "1", a contentless mock "delimiter" block, and paragraph "2"; clicks into the third block, moves caret to its start, and presses Left once — asserts the delimiter block gains class `ce-block--selected`; presses Left again — asserts the delimiter loses that class and the caret is now inside the first paragraph at offset 1 (end of "1").
+
+## modules/BlockEvents/ArrowRight.cy.ts
+
+- Arrow Right
+  - starting whitespaces handling
+    - |&nbsp; — should natively move caret over the visible space. Then move to the next block: blocks are `'1&nbsp;'` and `'2'`; clicks the first block, moves to its start, then presses `{rightArrow}` three times (after "1", across the nbsp, then into the next block); asserts the final selection is inside the last `.ce-paragraph` with `startOffset` 0.
+    - "| " — should ignore invisible space after caret and move caret to the next block: blocks are `'1 '` (trailing regular space) and `'2'`; moves to start then two `{rightArrow}` presses skip the invisible space and land in the next block at offset 0.
+    - |<b></b> — should ignore empty tags after caret and move caret to the next block: blocks are `'1<b></b>'` and `'2'`; moves to start then two `{rightArrow}` presses skip the empty tag and land in the next block at offset 0.
+    - |&nbsp;<b></b> — should move caret over the visible space and then to the next block: blocks are `'1&nbsp;<b></b>'` and `'2'`; moves to start then three `{rightArrow}` presses (after "1", over the nbsp, then next block); caret ends at offset 0 of the last paragraph.
+    - |<b></b>&nbsp; — should ignore empty tag and move caret over the visible space. Then move to the next block: blocks are `'1<b></b>&nbsp;'` and `'2'`; moves to start then three `{rightArrow}` presses (after "1", ignoring the empty tag and crossing the nbsp, then next block); caret ends at offset 0 of the last paragraph.
+    - "|&nbsp; " — should move caret over the visible space. Then ignore a trailing space and move to the next block: blocks are `'1&nbsp; '` (nbsp then trailing space) and `'2'`; moves to start then three `{rightArrow}` presses (after "1", over the nbsp, then ignoring the trailing space to land in the next block); caret ends at offset 0 of the last paragraph.
+  - should move caret to the next block if currently focused block is contentless (Delimiter): paragraph "1", a contentless mock "delimiter" block, and paragraph "2"; clicks into the first block (caret lands at its end) and presses Right once — asserts the delimiter block gains class `ce-block--selected`; presses Right again — asserts the delimiter loses that class and the caret moves to offset 0 of the last paragraph (start of "2").
+
+## modules/BlockEvents/Backspace.cy.ts
+
+- Backspace keydown
+  - starting whitespaces handling
+    - &nbsp;| — should delete visible space: blocks `'1'`/`'&nbsp;2'`; clicks last block, `{leftArrow}` (before "2"), one Backspace; asserts the last block's text becomes `'2'` (only the nbsp is deleted, blocks stay separate).
+    -  | — should ignore invisible space before caret and handle it like regular backspace case (merge with previous): blocks `'1'`/`' 2'`; leftArrow then one Backspace; asserts the remaining (merged) block's text is `'12'` — the invisible leading space is discarded as part of a block merge rather than deleted on its own.
+    - <b></b>| — should ignore empty tags before caret and handle it like regular backspace case (merge with previous): blocks `'1'`/`'<b></b>2'`; leftArrow then one Backspace; asserts merged text `'12'` (empty tag ignored, blocks merge).
+    - <b></b>&nbsp;| — should remove visible space and ignore empty tag: blocks `'1'`/`'<b></b>&nbsp;2'`; leftArrow then two Backspaces (first deletes the nbsp, second ignores the now-adjacent empty tag and merges with the previous block); asserts final merged text `'12'`.
+    - &nbsp;<b></b>| — should remove visible space and ignore empty tag: **duplicate test bug in v2 source** — despite its title implying blocks `'1'` / `'&nbsp;<b></b>2'` (space before empty tag), this test is byte-for-byte identical to the preceding one: same fixture `['1', '<b></b>&nbsp;2']`, same leftArrow + two-Backspace sequence, same asserted merged text `'12'`. It's a copy-pasted duplicate, not a distinct case — the space-before-empty-tag ordering the title describes is never actually tested anywhere in this file.
+    -  &nbsp;| — should remove visible space and ignore space: blocks `'1'`/`' &nbsp;2'`; leftArrow then two Backspaces (first removes the nbsp, second ignores the leading regular space and merges); asserts merged text `'12'`.
+    - &nbsp; &nbsp;| — should delete visible and invisble whitespaces in the abscence of any non whitespace characters: blocks `'1'` and `'&nbsp; &nbsp;'` (only whitespace, no real characters); clicks last block, `{downArrow}` to place caret at its end, then four Backspaces; asserts the sole remaining block's text ends up as `'1'` — all whitespace-only content is deleted and the (now empty) second block merges away, leaving just the first block's text.
+  - should just delete chars (native behaviour) when some fragment is selected: two blocks `'The first block'`/`'The second block'`; in the last block, selects `'The '` then Backspace; asserts the last block's text becomes `'second block'` (ordinary in-block deletion, no merge logic).
+  - should just delete chars (native behaviour) when Caret is not at the start of the Block: clicks the last block (caret lands at its end) then one Backspace; asserts the last character is removed, text becomes `'The second bloc'`.
+  - should navigate previous input when Caret is not at the first input: a mock tool renders two `contenteditable` inputs in one block; clicks into the second (empty) input and presses Backspace; asserts the selection's `startContainer` is now contained within the first input (focus moves back instead of deleting/merging blocks).
+  - should remove previous Block if Caret at the start of the Block and previous Block is empty. Also, should close the Toolbox: blocks are an empty paragraph (`block1`) and `'Not empty block'` (`block2`); clicks block2, `{home}`, Backspace; asserts `editor.save()` returns 1 block whose `id` is `block2` (the empty previous block was removed).
+  - should remove current Block if it is empty, but previous is not. Also, should close the Toolbox and set Caret to the end of the prev Block: blocks are `'Not empty block'` (`block1`) and an empty paragraph (`block2`); clicks block2 then Backspace; asserts `editor.save()` returns 1 block with `id` `block1`; asserts the caret lands inside that remaining paragraph at `startOffset` equal to its full text length (end of block1); asserts `.ce-toolbar` lacks class `ce-toolbar--opened`.
+  - should merge current Block with the previous one if Caret at the start of the Block and both Blocks are mergeable. Also, should close the Toolbox. Caret should be places in a place of glue: blocks `'First block'` (`block1`) / `'Second block'` (`block2`); clicks block2, `{home}`, Backspace; asserts `editor.save()` returns 1 block with `id` `block1` and `data.text` `'First blockSecond block'`; asserts (after normalizing text nodes) the caret offset equals `'First block'.length`; asserts the toolbar is not opened.
+  - should merge blocks of different types (Paragraph -> Header) if they have a valid conversion config. Also, should close the Toolbox. Caret should be places in a place of glue: `block1` is type `header` (`'First block heading'`), `block2` is type `paragraph` (`'Second block paragraph'`) using the `SimpleHeader` tool with a conversion config; clicks the `.ce-paragraph` (block2), `{home}`, Backspace; asserts `editor.save()` returns 1 block with `id` `block1` and merged `data.text` `'First block headingSecond block paragraph'`; asserts caret offset (after normalize) equals `'First block heading'.length`; asserts the toolbar is not opened.
+  - should merge blocks of different types (Header -> Paragraph) if they have a valid conversion config. Also, should close the Toolbox. Caret should be places in a place of glue: `block1` is type `paragraph` (`'First block paragraph'`), `block2` is type `header` (`'Second block heading'`); clicks block2 via `[data-cy="block-wrapper"][data-id="block2"]`, `{home}`, Backspace; asserts `editor.save()` returns 1 block with `id` `block1` and merged text `'First block paragraphSecond block heading'`; asserts caret offset (after normalize) equals `'First block paragraph'.length`; asserts the toolbar is not opened.
+  - should simply set Caret to the end of the previous Block if Caret at the start of the Block but Blocks are not mergeable (target Bock is lack of merge() and conversionConfig). Also, should close the Toolbox.: first block is a custom tool lacking both `merge()` and `conversionConfig`, second is paragraph `'Second block'`; clicks the paragraph, `{home}`, Backspace; asserts the caret ends up inside the first (unmergeable) block's element — no merge occurs, caret simply relocates.
+  - should simply set Caret to the end of the previous Block if Caret at the start of the Block but Blocks are not mergeable (target Bock is lack of merge() but has the conversionConfig).: same scenario but the unmergeable tool now also defines a `conversionConfig` (still no `merge()`); same assertion — caret moves into the previous block's element without merging, showing `conversionConfig` alone is insufficient without `merge()`.
+  - at the start of the first Block
+    - should do nothing if Block is not empty: single non-empty paragraph block; `{home}` then Backspace; asserts there is still exactly 1 `.ce-paragraph` with its original, unchanged text.
+
+## modules/BlockEvents/Delete.cy.ts
+
+- Delete keydown
+  - ending whitespaces handling
+    - |&nbsp; — should delete visible space: blocks `'1&nbsp;'`/`'2'`; moves to start, `{rightArrow}` (after "1"), then two Del presses (first deletes the nbsp, second merges with the next block); asserts final text `'12'`.
+    - "| " — should ignore invisible space after caret and handle it like regular delete case (merge with next): blocks `'1 '` (trailing regular space)/`'2'`; moves to start, rightArrow, then a single Del; asserts the last block's text becomes `'1 2'` — one Delete press both crosses the invisible space and merges the blocks, preserving the space character in the result.
+    - |<b></b> — should ignore empty tags after caret and handle it like regular delete case (merge): blocks `'1<b></b>'`/`'2'`; moves to start, rightArrow, one Del; asserts merged text `'12'`.
+    - |&nbsp;<b></b> — should remove visible space and ignore empty tag: blocks `'1&nbsp;<b></b>'`/`'2'`; moves to start, rightArrow, two Del presses (first removes the nbsp, second ignores the empty tag and merges); asserts merged text `'12'`.
+    - |<b></b>&nbsp; — should remove visible space and ignore empty tag: blocks `'1<b></b>&nbsp;'`/`'2'`; moves to start, rightArrow, two Del presses; asserts merged text `'12'`.
+    - "|&nbsp; " — should remove visible space and ignore space: blocks `'1&nbsp; '` (nbsp then trailing space)/`'2'`; moves to start, rightArrow, two Del presses (first removes the nbsp, second ignores the trailing space and merges); asserts the resulting text matches either `'12'` or `'1 2'` via regex, explicitly accommodating a documented Firefox-vs-Chrome/Safari merge-behavior difference.
+  - should just delete chars (native behaviour) when some fragment is selected: two blocks; in the first block selects `'The '` then Del; asserts the first block's text becomes `'first block'`.
+  - should just delete chars (native behaviour) when Caret is not at the end of the Block: clicks the first block (caret at end), `{leftarrow}`, then Del; asserts the last character is removed, text becomes `'The first bloc'`.
+  - should navigate next input when Caret is not at the last input: a mock tool renders two `contenteditable` inputs; clicks the first input then presses Del; asserts the selection's `startContainer` is now contained within the second input (focus moves forward instead of deleting/merging blocks).
+  - should remove next Block if Caret at the end of the Block and next Block is empty. Also, should close the Toolbox: `block1` `'Not empty block'`, `block2` empty; clicks block1 (caret at its end) then Del; asserts `editor.save()` returns 1 block with `id` `block1` (the empty next block was removed).
+  - should remove current Block if it is empty, but next is not. Also, should close the Toolbox and set Caret to the start of the next Block: `block1` `'1'`, `block2` `'Not empty block'`; clicks block1, Backspace (clears the `'1'` to make it empty), then Del; asserts `editor.save()` returns 1 block with `id` `block2` (the now-empty current block was removed); asserts caret lands at offset 0 of the remaining paragraph; asserts the toolbar is not opened.
+  - should merge current Block with the next one if Caret at the end of the Block and both Blocks are mergeable. Also, should close the Toolbox.: `block1` `'First block'`, `block2` `'Second block'`; clicks block1 (caret at its end) then Del; asserts `editor.save()` returns 1 block with `id` `block1` and merged text `'First blockSecond block'`; asserts caret offset (after normalize) equals `'First block'.length`; asserts the toolbar is not opened.
+  - should simply set Caret to the start of the next Block if Caret at the end of the Block but Blocks are not mergeable. Also, should close the Toolbox.: `block1` is paragraph `'Second block'`, `block2` is a custom tool lacking `merge()`; clicks the paragraph then Del; asserts the caret ends up inside the second (unmergeable) block's element, with no text merge asserted.
+  - at the end of the last Block
+    - should do nothing: single non-empty paragraph; clicks (caret at end) then Del; asserts there is still exactly 1 `.ce-paragraph` with its original, unchanged text.
+
+## modules/BlockEvents/Enter.cy.ts
+
+- Enter keydown
+  - should split block and remove selected fragment if some text fragment selected: single paragraph `'The block with some text'`; selects the substring `'with so'` then presses Enter; asserts there are now 2 blocks, with the first block's text `'The block '` and the second block's text `'me text'` (the selected fragment is removed and the block splits at the selection boundaries).
+  - should set caret to the new block if it was created after Enter key press at very end of the block: same initial single paragraph text; clicks into the block (caret placed, no selection) then presses Enter; asserts the resulting last `.ce-block` contains the current selection range's `startContainer`, i.e. the caret moved into the newly created block.
+
+## modules/BlockEvents/Slash.cy.ts
+
+- Slash keydown
+  - pressed in empty block
+    - should add "/" in a block and open Toolbox: an empty paragraph block; clicks in and types `'/'`; asserts the paragraph's text becomes `'/'` and the toolbox popover (`[data-cy="toolbox"] .ce-popover__container`) is visible.
+    - should not open Toolbox if Slash pressed with ${key} (parameterized for `'ctrl'` and `'cmd'`): an empty paragraph block; clicks in and types the modifier+slash combo (e.g. `{ctrl}/` or `{cmd}/`); asserts the toolbox popover is not visible (the modifier suppresses the slash-toolbox shortcut).
+  - pressed in non-empty block
+    - should not open Toolbox and just add the / char: a paragraph containing `'Hello'`; clicks in and types `'/'`; asserts the toolbox popover is not visible and the paragraph's text becomes `'Hello/'` (slash is treated as a literal character since the block isn't empty).
+  - pressed outside editor
+    - should not modify any text outside editor when text block is selected: opens the toolbox via the plus button and selects the "Text" option (establishing an active editor selection context), then makes a page `<h1>` element temporarily `contenteditable`, selects all its text, and dispatches a raw `keydown` event with key `/` directly on that `<h1>`; asserts the `<h1>`'s text remains unchanged (`'Editor.js test page'`), confirming the editor's slash handling doesn't affect elements outside the editor.
+- CMD+Slash keydown
+  - should open Block Tunes: an empty paragraph block; clicks in and types `{cmd}/`; asserts the block-tunes popover (`[data-cy="block-tunes"] .ce-popover__container`) becomes visible.
+
+## modules/BlockEvents/Tab.cy.ts
+
+- Tab keydown
+  - should focus next Block if Block contains only one input: two paragraph blocks; clicks the first, dispatches a raw `keydown` with `keyCode: 9` (Tab), waits 100ms; asserts the resulting selection range's container's parent element is the second paragraph block (caret/focus moved to the next block).
+  - should focus next input if Block contains several inputs: a mock tool renders two `contenteditable` inputs followed by a paragraph block; clicks the tool's first input, dispatches Tab keydown, waits; asserts the selection range's `startContainer` equals the tool's second input element directly (Tab moves between the tool's own inputs before leaving the block).
+  - should highlight next Block if it does not contain any inputs (contentless Block): a paragraph, then a contentless mock tool block (renders `'***'`, no inputs), then another paragraph; clicks the first paragraph, dispatches Tab keydown, waits; asserts the contentless tool's parent `.ce-block` gains class `ce-block--selected`.
+  - should focus next input after Editor when pressed in last Block: a default single-block editor plus a manually appended `<input data-cy=regular-input>` placed after the editor in the page; clicks the paragraph and performs a real `cy.tab()`; asserts the external input receives focus (Tab exits the editor to the next focusable element on the page).
+- Shift+Tab keydown
+  - should focus previous Block if Block contains only one input: two paragraph blocks; clicks the last, dispatches `keydown` with `keyCode: 9, shiftKey: true`, waits; asserts the selection range's container's parent element is the first paragraph block.
+  - should focus previous input if Block contains several inputs: a paragraph followed by a two-input mock tool block; clicks the tool's last input, dispatches Shift+Tab keydown, waits; asserts the selection range's `startContainer` equals the tool's first input element directly.
+  - should highlight previous Block if it does not contain any inputs (contentless Block): a paragraph, a contentless mock tool, and another paragraph; clicks the last paragraph, dispatches Shift+Tab keydown, waits; asserts the contentless tool's parent `.ce-block` gains class `ce-block--selected`.
+  - should focus previous input before Editor when pressed in first Block: a default single-block editor plus a manually inserted `<input data-cy=regular-input>` placed before the editor in the page; clicks the paragraph and performs `cy.tab({ shift: true })`; asserts the external input receives focus.
+
+## tools/BlockTool.cy.ts
+
+- BlockTool
+  - .type should return ToolType.Block: constructs a `BlockToolAdapter` from a mock Tool class/config; asserts `tool.type` strictly equals `ToolType.Block`.
+  - .name should return correct value: asserts `tool.name` strictly equals the `name` passed in the adapter options (`'blockTool'`).
+  - .isDefault should return correct value: builds one adapter with `isDefault: false` (default options) and another with `isDefault: true`; asserts the first tool's `isDefault` is `false` and the second's is `true`.
+  - .isInternal should return correct value: builds one adapter with default (`false`) `isInternal` and another with `isInternal: true`; asserts each tool's `isInternal` reflects the value passed.
+  - .settings
+    - should return correct value: asserts `tool.settings` deep-equals `options.config.config`, the user-supplied tool settings object.
+    - should add default placeholder if Tool is default: builds an adapter with `isDefault: true`; asserts `tool.settings` has a `placeholder` property equal to the adapter's `defaultPlaceholder` option.
+  - .sanitizeConfig
+    - should return correct value: asserts `tool.sanitizeConfig` deep-equals the static `sanitize` object defined on the mock Tool class.
+    - should return composed config if there are enabled inline tools: attaches an `InlineToolAdapter` (with its own static sanitize rule `{ b: true }`) to `tool.inlineTools` via a `ToolsCollection`; asserts `tool.sanitizeConfig` merges `b: true` into every rule of the block tool's own sanitize config.
+    - should return inline tools config if block one is not set: uses a Tool class with no static `sanitize`, and sets `tool.inlineTools` to two inline tools with different sanitize rules (`b: true` and `a: true`); asserts `tool.sanitizeConfig` deep-equals the merged sanitizeConfig objects of both inline tools (falls back entirely to inline tools' rules).
+    - should return empty object by default: uses an empty Tool class with no sanitize and no inline tools set; asserts `tool.sanitizeConfig` deep-equals `{}`.
+  - .isBlock() should return true: asserts `tool.isBlock()` is `true`.
+  - .isInline() should return false: asserts `tool.isInline()` is `false`.
+  - .isTune() should return false: asserts `tool.isTune()` is `false`.
+  - .isReadOnlySupported should return correct value: asserts `tool.isReadOnlySupported` strictly equals the Tool class's static `isReadOnlySupported` (`true`).
+  - .isLineBreaksEnabled should return correct value: asserts `tool.isLineBreaksEnabled` strictly equals the Tool class's static `enableLineBreaks` (`true`).
+  - .conversionConfig should return correct value: asserts `tool.conversionConfig` deep-equals the Tool class's static `conversionConfig` object.
+  - .pasteConfig
+    - should return correct value: asserts `tool.pasteConfig` deep-equals the Tool class's static `pasteConfig` object (`{ tags: ['div'] }`).
+    - should return false if `false` value was provided: uses a Tool subclass with static `pasteConfig = false`; asserts `tool.pasteConfig` deep-equals `false`.
+    - should return empty object if getter isn't provided: uses a Tool subclass with static `pasteConfig = undefined`; asserts `tool.pasteConfig` deep-equals `{}`.
+  - .enabledInlineTools
+    - should return correct value: asserts `tool.enabledInlineTools` deep-equals the user config's `inlineToolbar` array (`['link', 'bold']`).
+    - should return false by default: builds an adapter with `config.inlineToolbar` set to `undefined`; asserts `tool.enabledInlineTools` is `false`.
+  - .enabledBlockTunes should return correct value: asserts `tool.enabledBlockTunes` deep-equals the user config's `tunes` array (`['anchor', 'favorites']`).
+  - .prepare()
+    - should call Tool prepare method: stubs the Tool class's static `prepare`, calls `tool.prepare()`; asserts the stub was called with an object matching `{ toolName: tool.name, config: tool.settings }`.
+    - should not fail if Tool prepare method is not exist: builds an adapter whose `constructable` is `{}` (no `prepare`); asserts calling `tool.prepare` does not throw.
+  - .reset()
+    - should call Tool reset method: stubs the Tool class's static `reset`, calls `tool.reset()`; asserts the stub was called exactly once.
+    - should not fail if Tool reset method is not exist: builds an adapter with empty `constructable`; asserts calling `tool.reset` does not throw.
+  - .shortcut
+    - should return user provided shortcut: asserts `tool.shortcut` equals the user config's `shortcut` (`'CMD+SHIFT+B'`).
+    - should return Tool provided shortcut if user one is not specified: sets `config.shortcut` to `undefined`; asserts `tool.shortcut` falls back to the Tool class's static `shortcut` (`'CTRL+N'`).
+  - .toolbox
+    - should return user provided toolbox config wrapped in array: asserts `tool.toolbox` deep-equals `[options.config.toolbox]`, the user-provided toolbox object wrapped in a single-element array.
+    - should return Tool provided toolbox config wrapped in array if user one is not specified: sets `config.toolbox` to `undefined`; asserts `tool.toolbox` deep-equals `[options.constructable.toolbox]`, the Tool's static toolbox wrapped in an array.
+    - should merge Tool provided toolbox config and user one and wrap result in array in case both are objects: builds two adapters, each with a partial user toolbox object (title-only, icon-only); asserts each `tool.toolbox` is a single-element array containing the Tool's static toolbox merged with the corresponding user override.
+    - should replace Tool provided toolbox config with user defined config in case the first is an array and the second is an object: Tool's static `toolbox` is an array of entries while the user config's `toolbox` is a plain object; asserts `tool.toolbox` deep-equals `[userDefinedToolboxConfig]`, i.e. the user's object entirely replaces the Tool's array.
+    - should replace Tool provided toolbox config with user defined config in case the first is an object and the second is an array: Tool's static toolbox stays an object while user config's `toolbox` is an array; asserts `tool.toolbox` deep-equals that user array directly (replacement, not merge).
+    - should merge Tool provided toolbox config with user defined config in case both are arrays: both Tool's static toolbox and user config's toolbox are arrays; asserts `tool.toolbox` equals an array where each user entry is shallow-merged over the Tool's entry at the same index, with extra user entries passed through unchanged.
+    - should return undefined if user specifies false as a value: sets user `config.toolbox` to `false`; asserts `tool.toolbox` is `undefined`.
+    - should return undefined if Tool specifies false as a value: sets Tool's static `toolbox` to `false`; asserts `tool.toolbox` is `undefined`.
+    - should return undefined if Tool provides empty config: sets Tool's static `toolbox` to `{}`; asserts `tool.toolbox` is `undefined`.
+  - .create()
+    - should return Tool instance: calls `tool.create(data, blockAPI, false)`; asserts the result is an `instanceof` the mock Tool constructable.
+    - should return Tool instance with passed data: asserts the created instance's `.data` deep-equals the `data` object passed to `create()`.
+    - should return Tool instance with passed BlockAPI object: asserts the created instance's `.block` deep-equals the `blockAPI` object passed to `create()`.
+    - should return Tool instance with passed readOnly flag: calls `create()` once with `readOnly=false` and once with `readOnly=true`; asserts each instance's `.readonly` matches the flag passed.
+    - should return Tool instance with passed API object: asserts the created instance's `.api` deep-equals the adapter's configured `options.api`.
+    - should return Tool instance with passed config: asserts the created instance's `.config` deep-equals `options.config.config`.
+
+## tools/BlockTune.cy.ts
+
+- BlockTune
+  - .type should return ToolType.Tune: constructs a `BlockTuneAdapter` from a mock Tool class/config; asserts `tool.type` strictly equals `ToolType.Tune`.
+  - .name should return correct value: asserts `tool.name` strictly equals the `name` passed in options.
+  - .isInternal should return correct value: builds one adapter with default `isInternal: false` and another with `isInternal: true`; asserts each tool's `isInternal` reflects the passed value.
+  - .settings should return correct value: asserts `tool.settings` deep-equals `options.config.config`.
+  - .isBlock() should return false: asserts `tool.isBlock()` is `false`.
+  - .isInline() should return false: asserts `tool.isInline()` is `false`.
+  - .isTune() should return true: asserts `tool.isTune()` is `true`.
+  - .prepare()
+    - should call Tool prepare method: stubs the Tune class's static `prepare`, calls `tool.prepare()`; asserts the stub was called with an object matching `{ toolName: tool.name, config: tool.settings }`.
+    - should not fail if Tool prepare method is not exist: builds an adapter with empty `constructable`; asserts calling `tool.prepare` does not throw.
+  - .reset()
+    - should call Tool reset method: stubs the Tune class's static `reset`, calls `tool.reset()`; asserts the stub was called exactly once.
+    - should not fail if Tool reset method is not exist: builds an adapter with empty `constructable`; asserts calling `tool.reset` does not throw.
+  - .create()
+    - should return Tool instance: calls `tool.create(data, blockAPI)`; asserts the result is an `instanceof` the mock Tune constructable.
+    - should return Tool instance with passed data: asserts the created instance's `.data` deep-equals the `data` object passed to `create()`.
+    - should return Tool instance with passed BlockAPI object: asserts the created instance's `.block` deep-equals the `blockAPI` object passed to `create()`.
+    - should return Tool instance with passed API object: asserts the created instance's `.api` deep-equals `options.api`.
+    - should return Tool instance with passed settings: asserts the created instance's `.config` deep-equals `options.config.config`.
+
+## tools/InlineTool.cy.ts
+
+- InlineTool
+  - .type should return ToolType.Inline: constructs an `InlineToolAdapter` from a mock Tool class/config; asserts `tool.type` strictly equals `ToolType.Inline`.
+  - .name should return correct value: asserts `tool.name` strictly equals the `name` passed in options.
+  - .title should return correct title: asserts `tool.title` strictly equals the Tool class's static `title` (`'Title'`).
+  - .isInternal should return correct value: builds one adapter with default `isInternal: false` and another with `isInternal: true`; asserts each tool's `isInternal` reflects the passed value.
+  - .settings should return correct value: asserts `tool.settings` deep-equals `options.config.config`.
+  - .sanitizeConfig should return correct value: asserts `tool.sanitizeConfig` deep-equals the Tool class's static `sanitize` object.
+  - .isBlock() should return false: asserts `tool.isBlock()` is `false`.
+  - .isInline() should return true: asserts `tool.isInline()` is `true`.
+  - .isTune() should return false: asserts `tool.isTune()` is `false`.
+  - .prepare()
+    - should call Tool prepare method: stubs the Tool class's static `prepare`, calls `tool.prepare()`; asserts the stub was called with an object matching `{ toolName: tool.name, config: tool.settings }`.
+    - should not fail if Tool prepare method is not exist: builds an adapter with empty `constructable`; asserts calling `tool.prepare` does not throw.
+  - .reset()
+    - should call Tool reset method: stubs the Tool class's static `reset`, calls `tool.reset()`; asserts the stub was called exactly once.
+    - should not fail if Tool reset method is not exist: builds an adapter with empty `constructable`; asserts calling `tool.reset` does not throw.
+  - .shortcut
+    - should return user provided shortcut: asserts `tool.shortcut` equals the user config's `shortcut` (`'CMD+SHIFT+B'`).
+    - should return Tool provided shortcut if user one is not specified: sets `config.shortcut` to `undefined`; asserts `tool.shortcut` falls back to the Tool class's static `shortcut` (`'CTRL+N'`).
+  - .create()
+    - should return Tool instance: calls `tool.create()`; asserts the result is an `instanceof` the mock Tool constructable.
+    - should return Tool instance with passed API object: asserts the created instance's `.api` deep-equals `options.api`.
+    - should return Tool instance with passed config: asserts the created instance's `.config` deep-equals `options.config.config`.
+  - .isReadOnlySupported
+    - should return Tool provided value: asserts `tool.isReadOnlySupported` strictly equals the Tool class's static `isReadOnlySupported` (`true`).
+    - should return false if Tool provided value is not exist: builds an adapter with empty `constructable` (no static `isReadOnlySupported`); asserts `tool.isReadOnlySupported` defaults to `false`.
+
+## tools/ToolsCollection.cy.ts
+
+- ToolsCollection
+  - should be instance of Map: constructs a `ToolsCollection` from an array of fake block/inline/tune tool entries; asserts `collection instanceof Map` is `true`.
+  - .blockTools
+    - should return new instance of ToolsCollection: asserts `collection.blockTools` is an `instanceof ToolsCollection`.
+    - result should contain only block tools: asserts every tool value in `collection.blockTools` returns `true` from `.isBlock()`.
+  - .inlineTools
+    - should return new instance of ToolsCollection: asserts `collection.inlineTools` is an `instanceof ToolsCollection`.
+    - result should contain only inline tools: asserts every tool value in `collection.inlineTools` returns `true` from `.isInline()`.
+  - .blockTunes
+    - should return new instance of ToolsCollection: asserts `collection.blockTunes` is an `instanceof ToolsCollection`.
+    - result should contain only block tools: asserts every tool value in `collection.blockTunes` returns `true` from `.isTune()` (label in the suite says "block tools" but the assertion checks tune-ness).
+  - .internalTools
+    - should return new instance of ToolsCollection: asserts `collection.internalTools` is an `instanceof ToolsCollection`.
+    - result should contain only internal tools: asserts every tool value in `collection.internalTools` has `isInternal === true`.
+  - .externalTools
+    - should return new instance of ToolsCollection: asserts `collection.externalTools` is an `instanceof ToolsCollection`.
+    - result should contain only external tools: asserts every tool value in `collection.externalTools` has `isInternal === false`.
+  - mixed access
+    - .blockTunes.internalTools
+      - should return only internal tunes: chains `collection.blockTunes.internalTools`; asserts every resulting tool returns `true` from `.isTune()` and has `isInternal === true`.
+    - .externalTools.blockTools
+      - should return only external block tools: chains `collection.externalTools.blockTools`; asserts every resulting tool returns `true` from `.isBlock()` and has `isInternal === false`.
+
+## tools/ToolsFactory.cy.ts
+
+- ToolsFactory
+  - .get
+    - should return appropriate tool object: calls `factory.get('link')` (configured with the real `LinkInlineTool`); asserts the returned tool's `.name` equals `'link'`.
+    - should return InlineTool object for inline tool: calls `factory.get('link')`; asserts the result is an `instanceof InlineToolAdapter`.
+    - should return BlockTool object for block tool: calls `factory.get('paragraph')` (configured with the real `Paragraph` tool); asserts the result is an `instanceof BlockToolAdapter`.
+    - should return BlockTune object for tune: calls `factory.get('moveUp')` (configured with the real `MoveUpTune`); asserts the result is an `instanceof BlockTuneAdapter`.
+
+## ui/BlockTunes.cy.ts
+
+- BlockTunes
+  - Search
+    - should be focused after popover opened: Creates an editor with one paragraph block, clicks into it, and types Cmd+/ to open the Block Tunes popover; after the selection-change debounce wait, asserts the window's current selection range is contained within the block-tunes `.cdx-search-field` element, confirming caret/focus moved into the search input.
+  - Keyboard only
+    - should not delete the currently selected block when Enter pressed on a search input (or any block tune): With one paragraph block ("Some text"), opens Block Tunes via Cmd+/ then dispatches a keydown with keyCode 13 (Enter); asserts the block wrapper's text is still "Some text", i.e. the block was not deleted by Enter.
+    - should not unselect currently selected block when Enter pressed on a block tune: Same setup and Cmd+/ + Enter keydown sequence; asserts the first block wrapper still has the `ce-block--selected` class, i.e. Enter on a focused tune does not deselect the block.
+  - Convert to
+    - should display Convert to inside Block Tunes: With the Header tool registered and one paragraph block, clicks the block then the toolbar settings button to open Block Tunes; asserts a popover item containing "Convert to" exists, and clicking it reveals a `.ce-popover--nested` popover containing a `[data-item-name=header]` item.
+    - should not display Convert to inside Block Tunes if there is nothing to convert to: With only the default paragraph tool installed, opens Block Tunes and asserts no popover item containing "Convert to" exists.
+    - should not display the ConvertTo control if block has no conversionConfig.export specified: Uses `ToolWithoutConversionExport` (has `conversionConfig.import` but no `export`); opens Block Tunes for a block of that type and asserts no popover item with `data-item-name=convert-to` exists.
+    - should not display tool with the same data in "Convert to" menu: Defines a TestTool with two toolbox entries (Title 1/level 1, Title 2/level 2) and a `conversionConfig`; creates a block of that type with data `{text: 'Some text', level: 1}`, opens Block Tunes then "Convert to"; asserts the nested popover item matching "Title 1" (identical data to the current block) does not exist, while "Title 2" (different data) does exist.
+    - should convert block to another type and set caret to the new block: With Header tool and a paragraph block, opens Block Tunes, clicks "Convert to", then clicks the "header" nested item; asserts the block now renders as `.ce-header` with the original text, and that the current selection range is contained within that new header element (caret restored to the converted block).
+  - Tunes order
+    - should display block specific tunes before common tunes: Defines a TestTool with a `renderSettings()` returning a tune titled "Tune"; creates a block of that type and opens Block Tunes; asserts there is more than one popover item and that the first-child popover item contains the text "Tune", confirming the tool-specific tune is listed before the common (default) tunes.
+
+## ui/DataEmpty.cy.ts
+
+- inputs [data-empty] mark
+  - should be added to inputs of editor on initialization: Creates an editor with two paragraph blocks ("First" and an empty string); immediately after init, asserts the first (non-empty) block's input has `data-empty="false"` and the last (empty) block's input has `data-empty="true"`.
+  - should be added as "false" to the input on typing: With blocks "First" and empty, types "Some text" into the last (empty) block; asserts its input's `data-empty` attribute becomes "false".
+  - should be added as "true" to the input on chars removal: With blocks empty and "Some text", selects all and backspaces in the last block; asserts its input's `data-empty` attribute becomes "true" once emptied.
+  - should be added to the new block inputs: With blocks "First" and empty, presses Enter in the last block to create a new block; asserts the new last block's input has `data-empty="true"`.
+
+## ui/InlineToolbar.cy.ts
+
+- Inline Toolbar
+  - Separators
+    - should have a separator after the first item if it has children: With Header tool configured (default inline toolbar includes "convert-to", which has children), selects text in a paragraph to open the Inline Toolbar; asserts the first child of the popover items list has `data-item-name="convert-to"` and the second child has class `ce-popover-item-separator`, i.e. a separator directly follows an item with children.
+    - should have separators from both sides of item if it is in the middle and has children: Configures a Header block whose inline toolbar is `['bold', 'testTool', 'link']`, where `testTool` renders a MenuConfig with `children`; selects text to open the Inline Toolbar; asserts item index 3 is a separator, index 4 is the `test-tool` item, and index 5 is also a separator, confirming an item with children in the middle of the list is surrounded by separators on both sides.
+    - should have separator before the item with children if it is the last of all items: Configures a Header block whose inline toolbar is `['bold', 'testTool']` (testTool has children and is last); selects text to open the Inline Toolbar; asserts index 3 is a separator and index 4 is the `test-tool` item, confirming a separator precedes the last item since it has children.
+  - Shortcuts
+    - should work in read-only mode: Registers a custom inline `Marker` tool (`isReadOnlySupported = true`, shortcut CMD+SHIFT+M) whose `onActivate` calls a stub; creates a read-only editor, selects text, then dispatches a native `keydown` KeyboardEvent for Cmd+Shift+M on the document; asserts the stub was called, confirming inline-tool shortcuts still fire in read-only mode for tools that support it.
+
+## ui/Placeholders.cy.ts
+
+- Placeholders
+  - should be shown near first block if passed via editor config: Creates an editor with a `placeholder` config string; asserts the first paragraph's `::before` pseudo-element content equals the placeholder text.
+  - should be shown when editor is autofocusable: Creates an editor with `placeholder` and `autofocus: true`; asserts the first paragraph's `::before` pseudo-element content still equals the placeholder text even though the block is auto-focused.
+  - should be shown event if input is focused: Creates an editor with a placeholder, clicks into the first paragraph (giving it focus); asserts the `::before` pseudo-element content still equals the placeholder text while the empty block is focused.
+  - should be shown event when user removes all text by cmd+a and delete: Creates an editor with a placeholder, types "aaa" then does select-all + backspace; asserts the `::before` pseudo-element content equals the placeholder text again once the block is emptied.
+  - should be hidden when user starts typing: Creates an editor with a placeholder, confirms it is initially shown, then types a single "a"; asserts the `::before` pseudo-element content becomes "none" once the block has content.
+  - should be hidden when user adds trailing whitespace characters: Creates an editor with a placeholder, confirms it is initially shown, then types three space characters; asserts the `::before` pseudo-element content becomes "none", confirming whitespace-only content still counts as non-empty for placeholder purposes.
+
+## ui/toolbox.cy.ts
+
+- Toolbox
+  - Shortcuts
+    - should convert current Block to the Shortcuts's Block if both tools provides a "conversionConfig". Caret should be restored after conversion.: Registers `convertableTool` (has `conversionConfig.import` and a toolbox) with shortcut CMD+SHIFT+H; types "Some text" into the default paragraph then triggers the shortcut; via `editor.save()` asserts there is still 1 block, now of type `convertableTool` with the same text, and that the current selection range is contained in the DOM block matching the new block's id, confirming the caret is preserved/restored after in-place conversion.
+    - should insert a Shortcuts's Block below the current if some (original or target) tool does not provide a "conversionConfig": Registers `nonConvertableTool` (no `conversionConfig`) with shortcut CMD+SHIFT+H; types text into the paragraph then triggers the shortcut; via `editor.save()` asserts there are now 2 blocks and the second is of type `nonConvertableTool`, confirming a new block is appended (rather than converted in place) when conversion isn't possible.
+    - should display shortcut only for the first toolbox item if tool exports toolbox with several items: Registers a tool whose `toolbox` is an array of two items, with shortcut CMD+SHIFT+L; types text then presses `/` to open the toolbox; asserts the first popover item for that tool has a `.ce-popover-item__secondary-title` (shortcut hint) while the second (eq(1)) item for the same tool does not.
+    - should display shortcut for the item if tool exports toolbox as an one item object: Registers a tool whose `toolbox` is a single object (not an array), with shortcut CMD+SHIFT+L; opens the toolbox via `/`; asserts the tool's single popover item has a `.ce-popover-item__secondary-title` shortcut hint displayed.
+
+## utils/flipper.cy.ts
+
+*(Imports no Flipper class directly; both tests exercise Flipper's keyboard-navigation behavior indirectly through a full `cy.createEditor` instance and its Block Tunes / Inline Toolbar popovers, which use the Flipper utility internally for arrow-key/Tab focus traversal.)*
+
+- Flipper
+  - should prevent plugins event handlers from being called while keyboard navigation: Registers a `SomePlugin` block tool whose rendered contenteditable attaches its own native `keydown` listener (spied via `cy.spy`); focuses the plugin's editable area, types text, opens Block Tunes with Ctrl+/, sends two ArrowDown keydowns to navigate to the "delete" tune (asserting it gets the `ce-popover-item--focused` class), then two Enter keydowns (activate delete, confirm delete); asserts the plugin's own internal keydown handler was never called, confirming Flipper's keyboard-navigation handling prevents those keydown events from also reaching the underlying plugin.
+  - should not flip when shift key is pressed: Creates an editor with one autofocused paragraph, selects a text range by offset, then triggers an ArrowDown keydown with `shiftKey: true` on the paragraph; asserts the Inline Toolbar popover exists but no popover item has the `ce-popover-item--focused` class, confirming Shift+ArrowDown does not trigger Flipper's focus-flipping.
+
+## utils/popover.cy.ts
+
+*(Imports `PopoverDesktop as Popover` and `PopoverItemType` directly from `src/components/utils/popover`. The first several tests instantiate `new Popover({items})` standalone and append `popover.getElement()` to the document, testing the Popover component in isolation. Later tests — from "should display item with custom html" onward, including the "Inline Popover" nested describe — use `cy.createEditor` to exercise Popover as integrated into Block Tunes / Inline Toolbar, since those cases need real tool `render()` output or the Editor's toolbar wiring.)*
+
+- Popover
+  - should support confirmation chains: Instantiates a standalone Popover with one item that has a `confirmation` sub-item (its own `onActivate` stub); appends it to the document; clicking the item once swaps its displayed icon/title to the confirmation's icon/title, and clicking again asserts the confirmation's `onActivate` stub was called once.
+  - should render the items with true isActive property value as active: Instantiates a standalone Popover with one item having `isActive: true`; asserts the rendered item has the `ce-popover-item--active` class immediately, without any interaction.
+  - should not execute item's onActivate callback if the item is disabled: Instantiates a standalone Popover with one item having `isDisabled: true` and a stubbed `onActivate`; asserts the item has the `ce-popover-item--disabled` class, then clicks it and asserts the stub was never called.
+  - should close once item with closeOnActivate property set to true is activated: Instantiates a standalone Popover with one item having `closeOnActivate: true`; spies on `popover.hide`; clicks the item and asserts `hide` was called.
+  - should highlight as active the item with toggle property set to true once activated: Instantiates a standalone Popover with one item having `toggle: true`; clicks it and asserts it then has the `ce-popover-item--active` class.
+  - should perform radiobutton-like behavior among the items that have toggle property value set to the same string value: Instantiates a standalone Popover with two items sharing `toggle: 'group-name'` (first initially `isActive: true`); asserts the first is active and the second is not, clicks the second and asserts it becomes active while the first loses its active class, confirming mutually-exclusive toggle-group behavior.
+  - should toggle item if it is the only item in toggle group: Instantiates a standalone Popover with a single item having `toggle: 'key'`; clicks it and asserts it gains the `ce-popover-item--active` class.
+  - should display item with custom html: Creates a full editor with a Block Tune (`TestTune`) whose `render()` returns a raw HTMLElement button; opens Block Tunes for a paragraph block; asserts an element with class `ce-popover-item-html` containing text "Tune" is visible.
+  - should support flipping between custom content items: Creates an editor with two custom-html tunes (`TestTool1`/`TestTool2` rendering "Tune1"/"Tune2" buttons); opens Block Tunes and presses Tab three times; asserts focus lands first on the "Tune1" custom item, then "Tune2", then the built-in `move-up` popover item, confirming Tab-based flipping traverses custom HTML items alongside default items in order.
+  - should display nested popover (desktop): Creates an editor with a tune whose `render()` returns a MenuConfig with nested `children.items`; opens Block Tunes; asserts the parent item shows a chevron-right icon, and clicking it reveals `.ce-popover--nested .ce-popover__container` containing the nested child item.
+  - should display children items, back button and item header and correctly switch between parent and child states (mobile): Sets viewport to `iphone-6+`, creates an editor with a nested-children tune; opens Block Tunes and clicks the parent item; asserts the nested child item is visible, the popover header shows the parent's title ("Tune"), and a back button is visible; clicking the back button then asserts the child item, back button, and header are all no longer present, i.e. it returns to the parent state.
+  - should display default (non-separator) items without specifying type: default: Creates an editor with a tune returning a single MenuConfig item that omits an explicit `type`; opens Block Tunes; asserts the item renders and is visible, confirming items default to the "default" popover item type when `type` is unset.
+  - should display separator: Creates an editor with a tune whose `render()` returns an array of one item plus `{ type: PopoverItemType.Separator }`; opens Block Tunes; asserts both the item and a `.ce-popover-item-separator` element are visible.
+  - should perform keyboard navigation between items ignoring separators: Creates an editor with a tune rendering two items with a separator entry between them; opens Block Tunes and presses Tab twice; asserts focus moves directly from item 1 to item 2, confirming Tab-flipping skips over separator entries.
+  - should perform keyboard navigation between items ignoring separators when search query is applied: Same two-items-plus-separator tune; after opening Block Tunes, types "Tune" into the block-tunes search field first (asserting the separator becomes not visible/filtered), then Tabs twice; asserts focus still moves correctly from item 1 to item 2, confirming separator-skipping logic holds under an active search filter.
+  - shoould support i18n in nested popover: Creates an editor with a nested-children (`searchable: true`) tune and an `i18n.messages.ui.popover` config translating "Filter" and "Nothing found" into Russian; opens Block Tunes, clicks the parent item to reveal the nested popover; asserts the nested search input's placeholder equals the translated "Искать", and after typing a non-matching query, the nested popover's "nothing found" message reads the translated "Ничего не найдено".
+  - Inline Popover
+    - should open nested popover on click instead of hover: Creates an editor with the Header tool (giving a "convert-to" item with nested children) and a paragraph block; selects text to open the Inline Toolbar, triggers `mouseover` on the "convert-to" item and asserts no nested popover container exists yet; then clicks it and asserts the nested popover container now exists, confirming inline (as opposed to desktop block-tunes) nested popovers open on click rather than hover.
+    - should support keyboard nevigation between items: Creates an editor with Header tool and a paragraph; selects text to open the Inline Toolbar; asserts "convert-to" is not initially focused, presses Tab and asserts it becomes focused, asserts "link" is not focused, presses Tab again and asserts "link" becomes focused, confirming Tab-based flipping moves focus sequentially between Inline Toolbar items.
+    - should allow to reach nested popover via keyboard: Creates an editor with Header tool and a paragraph; selects text to open the Inline Toolbar, Tabs to focus "convert-to", presses Enter on it (opening its nested popover) and asserts the nested container becomes visible; asserts the nested "header" item isn't focused yet, Tabs again, and asserts the "header" item becomes focused, confirming keyboard users can Tab into a nested popover after activating its parent item with Enter.
diff --git a/packages/editorjs/e2e/fixtures/constants.ts b/packages/editorjs/e2e/fixtures/constants.ts
new file mode 100644
index 00000000..d33eec42
--- /dev/null
+++ b/packages/editorjs/e2e/fixtures/constants.ts
@@ -0,0 +1,14 @@
+/**
+ * Values the fixture is built around, shared with the specs that assert on them.
+ *
+ * Kept apart from `main.ts` so a spec can import one without mounting an editor, and apart from
+ * `e2e/support/` so the fixture doesn't drag Playwright into the browser bundle. The fixture is
+ * the source of truth: a spec asserting a value the fixture doesn't actually use is a test that
+ * passes for the wrong reason.
+ */
+
+/** Placeholder the fixture configures unless `?placeholder=` overrides it. */
+export const DEFAULT_PLACEHOLDER = 'Type text or press Tab';
+
+/** Text of the single block the fixture mounts when no `?text=` param is given. */
+export const DEFAULT_BLOCK_TEXT = 'Hello world';
diff --git a/packages/editorjs/e2e/fixtures/index.html b/packages/editorjs/e2e/fixtures/index.html
new file mode 100644
index 00000000..dfad75b3
--- /dev/null
+++ b/packages/editorjs/e2e/fixtures/index.html
@@ -0,0 +1,12 @@
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="UTF-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
+    <title>Editor.js e2e fixture</title>
+  </head>
+  <body>
+    <div id="editorjs"></div>
+    <script type="module" src="./main.ts"></script>
+  </body>
+</html>
diff --git a/packages/editorjs/e2e/fixtures/main.ts b/packages/editorjs/e2e/fixtures/main.ts
new file mode 100644
index 00000000..3355a248
--- /dev/null
+++ b/packages/editorjs/e2e/fixtures/main.ts
@@ -0,0 +1,72 @@
+import EditorJS from '../../src/index.js';
+import { DEFAULT_BLOCK_TEXT, DEFAULT_PLACEHOLDER } from './constants.js';
+
+/**
+ * Block texts to mount. `?text=Alpha&text=Beta` gives a multi-block document; with no
+ * `text` param at all the fixture keeps its original single "Hello world" block, so
+ * every existing test sees exactly what it did before. An empty value (`?text=`) mounts
+ * an empty block, which is how the placeholder tests get one.
+ */
+const params = new URLSearchParams(window.location.search);
+const texts = params.getAll('text');
+
+/**
+ * Reaches the paragraph tool as `config.placeholder` (it is the default block tool),
+ * which the tool exposes to assistive tech as `aria-placeholder`.
+ *
+ * `?placeholder=` (empty) mounts the editor with no `placeholder` option at all — the only way
+ * to get a block that must *not* carry the attribute, which is what the tool spec requires when
+ * nothing is configured. Omitting the param keeps the default every other test is written against.
+ */
+const placeholder = params.get('placeholder') ?? DEFAULT_PLACEHOLDER;
+
+/**
+ * `?editors=2` mounts a second editor on the same page, the way a host with two fields would.
+ * Anything the editor puts a document-wide `id` on has to stay unique across instances, so this
+ * is what makes that testable — the default stays a single editor.
+ *
+ * Anything that isn't a positive whole number is rejected rather than coerced: `Number('abc')`
+ * is `NaN`, which every comparison below is false against, so a typo would silently mount one
+ * editor and let a two-editor test pass without ever having had two
+ */
+const requestedEditors = Number(params.get('editors') ?? 1);
+
+if (!Number.isInteger(requestedEditors) || requestedEditors < 1) {
+  /**
+   * Recorded on the body as well as thrown: nothing else reads a module-level throw, and a
+   * spec would otherwise just time out waiting for `data-editor-ready` with no clue why
+   */
+  document.body.dataset.editorError = `"editors" must be a positive whole number, got "${params.get('editors')}"`;
+
+  throw new Error(document.body.dataset.editorError);
+}
+
+const holders = [document.getElementById('editorjs') as HTMLElement];
+
+for (let index = 1; index < requestedEditors; index++) {
+  const extraHolder = document.createElement('div');
+
+  extraHolder.id = `editorjs-${index + 1}`;
+  document.body.appendChild(extraHolder);
+  holders.push(extraHolder);
+}
+
+const editors = holders.map(holder => new EditorJS({
+  holder,
+  ...(placeholder !== '' ? { placeholder } : {}),
+  data: {
+    blocks: (texts.length > 0 ? texts : [DEFAULT_BLOCK_TEXT]).map(text => ({
+      type: 'paragraph',
+      data: { text },
+    })),
+  },
+}));
+
+Promise.all(editors.map(editor => editor.isReady))
+  .then(() => {
+    document.body.dataset.editorReady = 'true';
+  })
+  .catch((error: unknown) => {
+    console.error('Editor.js failed to initialize', error);
+    document.body.dataset.editorError = String(error);
+  });
diff --git a/packages/editorjs/e2e/support/editor.ts b/packages/editorjs/e2e/support/editor.ts
new file mode 100644
index 00000000..7ed9ced3
--- /dev/null
+++ b/packages/editorjs/e2e/support/editor.ts
@@ -0,0 +1,63 @@
+import { expect } from '@playwright/test';
+import type { Locator, Page } from '@playwright/test';
+import { DEFAULT_PLACEHOLDER } from '../fixtures/constants.js';
+
+/**
+ * Helpers shared by every spec in this suite. They live outside `e2e/tests` so Playwright's
+ * default `testMatch` can't mistake them for a spec file.
+ */
+
+/**
+ * The placeholder the fixture configures; the paragraph tool exposes it as `aria-placeholder`.
+ *
+ * Re-exported from the fixture's own constants rather than repeated here, so that changing what
+ * the fixture mounts can't leave the specs asserting a string it no longer uses
+ */
+export const PLACEHOLDER = DEFAULT_PLACEHOLDER;
+
+/**
+ * Mounts the fixture and waits until the editor reports itself ready.
+ *
+ * The fixture builds one paragraph per `text` search param (see e2e/fixtures/main.ts), so
+ * `search` is how a test gets a document other than the default single "Hello world" block:
+ * `?text=Alpha&text=Beta` for several, `?text=` for an empty one.
+ * @param page - Playwright page to mount the editor on
+ * @param search - query string to mount with, e.g. `?text=Alpha&text=Beta`
+ */
+export async function mountDocument(page: Page, search = ''): Promise<void> {
+  await page.goto(`/${search}`);
+  await page.waitForSelector('body[data-editor-ready="true"]');
+}
+
+/**
+ * Selects the whole text of the paragraph the way a user would, so that the editor's own
+ * caret tracking sees it. `locator.selectText()` bypasses that and the inline toolbar never
+ * appears - see the gotcha section of e2e/README.md.
+ * @param page - Playwright page the editor is mounted on
+ */
+export async function selectParagraphText(page: Page): Promise<void> {
+  await page.getByRole('textbox', { name: 'Paragraph' }).click({ clickCount: 3 });
+}
+
+/** Upper bound on Tab presses when reaching a tool, so a missing one fails fast. */
+const MAX_TAB_PRESSES = 5;
+
+/**
+ * Tabs from the current position until `button` holds real DOM focus.
+ *
+ * Tab order among the inline tools is deliberately not asserted anywhere, so tests reach a
+ * specific one by Tabbing until the DOM confirms it rather than hardcoding a press count.
+ * @param page - Playwright page the editor is mounted on
+ * @param button - locator for the inline tool button to land on
+ */
+export async function tabToInlineTool(page: Page, button: Locator): Promise<void> {
+  for (
+    let presses = 0;
+    presses < MAX_TAB_PRESSES && !(await button.evaluate(el => el === document.activeElement));
+    presses++
+  ) {
+    await page.keyboard.press('Tab');
+  }
+
+  await expect(button).toBeFocused();
+}
diff --git a/packages/editorjs/e2e/tests/aria.spec.ts b/packages/editorjs/e2e/tests/aria.spec.ts
new file mode 100644
index 00000000..96db06bf
--- /dev/null
+++ b/packages/editorjs/e2e/tests/aria.spec.ts
@@ -0,0 +1,574 @@
+import { test, expect } from '@playwright/test';
+import { PLACEHOLDER, mountDocument, selectParagraphText, tabToInlineTool } from '../support/editor.js';
+
+test.beforeEach(async ({ page }) => {
+  await mountDocument(page);
+});
+
+/** Test-only channel for the arrow keys the block actions toolbar called preventDefault() on. */
+interface ArrowKeyWindow extends Window {
+  /** Keys seen already prevented by the time the event reached document, in order. */
+  swallowedArrowKeys?: string[];
+}
+
+test('exposes the blocks holder as a structural group', async ({ page }) => {
+  const holder = page.getByRole('group');
+
+  await expect(holder).toBeVisible();
+  await expect(holder).toHaveClass(/ejs-blocks/);
+});
+
+test('exposes a paragraph block as a multiline textbox', async ({ page }) => {
+  const paragraph = page.getByRole('textbox', { name: 'Paragraph' });
+
+  await expect(paragraph).toBeVisible();
+  await expect(paragraph).toHaveAttribute('aria-multiline', 'true');
+  await expect(paragraph).toHaveText('Hello world');
+});
+
+test('exposes every block as a textbox of its own, in document order', async ({ page }) => {
+  const texts = ['Alpha', 'Beta', 'Gamma'];
+
+  await mountDocument(page, `?${texts.map(text => `text=${text}`).join('&')}`);
+
+  const blocks = page.getByRole('group').getByRole('textbox', { name: 'Paragraph' });
+
+  // One textbox per block, none nested and none merged: this is what lets assistive tech
+  // move between blocks at all, and it's the reason the holder had to stop being a textbox.
+  await expect(blocks).toHaveCount(texts.length);
+  await expect(blocks).toHaveText(texts);
+
+  const count = await blocks.count();
+
+  for (let index = 0; index < count; index++) {
+    await expect(blocks.nth(index)).toHaveAttribute('aria-multiline', 'true');
+  }
+});
+
+test('describes the expected input of an empty block with aria-placeholder', async ({ page }) => {
+  await mountDocument(page, '?text=');
+
+  const paragraph = page.getByRole('textbox', { name: 'Paragraph' });
+
+  // A contenteditable has no native placeholder attribute, so without this an empty block
+  // announces as an empty field with no indication of what belongs in it.
+  await expect(paragraph).toHaveText('');
+  await expect(paragraph).toHaveAttribute('aria-placeholder', PLACEHOLDER);
+});
+
+test('omits aria-placeholder entirely when none is configured', async ({ page }) => {
+  await mountDocument(page, '?text=&placeholder=');
+
+  const paragraph = page.getByRole('textbox', { name: 'Paragraph' });
+
+  await expect(paragraph).toHaveText('');
+
+  // The attribute has to be absent rather than empty: `aria-placeholder=""` is still an
+  // exposed property, and the positive test above passes either way, so nothing else pins
+  // that the tool skips the attribute instead of writing a blank one.
+  await expect(paragraph).not.toHaveAttribute('aria-placeholder');
+});
+
+test('splits into a second, separately exposed textbox on Enter', async ({ page }) => {
+  const paragraph = page.getByRole('textbox', { name: 'Paragraph' });
+
+  await paragraph.click();
+  await page.keyboard.press('End');
+  await page.keyboard.press('Enter');
+
+  const blocks = page.getByRole('textbox', { name: 'Paragraph' });
+
+  await expect(blocks).toHaveCount(2);
+  await expect(blocks).toHaveText(['Hello world', '']);
+  await expect(blocks.nth(1)).toHaveAttribute('aria-placeholder', PLACEHOLDER);
+});
+
+test('does not nest a textbox inside a textbox', async ({ page }) => {
+  // The blocks holder is itself contenteditable, which HTML-AAM maps to an
+  // implicit role="textbox". The explicit role="group" overrides that, so the
+  // block is the only textbox exposed rather than one nested inside another.
+  await expect(page.getByRole('group').getByRole('textbox')).toHaveCount(1);
+});
+
+test('exposes the floating toolbar and names its plus button', async ({ page }) => {
+  // Named, because the inline toolbar is a `role="toolbar"` too once a selection exists.
+  const toolbar = page.getByRole('toolbar', { name: 'Block actions' });
+
+  await expect(toolbar).toBeVisible();
+
+  // The plus button is icon-only, so its name comes entirely from aria-label.
+  await expect(toolbar.getByRole('button', { name: 'Add block' })).toBeVisible();
+});
+
+test('exposes the block actions toolbar as a single tab stop', async ({ page }) => {
+  const toolbar = page.getByRole('toolbar', { name: 'Block actions' });
+
+  await expect(toolbar).toHaveAttribute('aria-orientation', 'horizontal');
+
+  // role="toolbar" is a promise that the group is one tab stop navigated with the arrow keys.
+  // Asserted structurally rather than behaviourally because there is exactly one control today,
+  // which makes an arrow-key assertion pass whether or not anything handles the key. This
+  // assertion does not: it fails the moment a second control is added to the container without
+  // the roving tabindex being maintained, which is the regression actually worth catching.
+  expect(await toolbar.locator(':scope > button').count()).toBeGreaterThan(0);
+  expect(await toolbar.locator(':scope > button[tabindex="0"]').count()).toBe(1);
+});
+
+test('leaves modified arrow keys to their real owner', async ({ page }) => {
+  // Regression test for a bug the VoiceOver suite found the hard way. The roving tabindex above
+  // handles ArrowLeft/ArrowRight and calls preventDefault(), and it used to do so whatever
+  // modifiers were held - but VO+Right and VO+Left, the commands a VoiceOver user moves their
+  // cursor with, reach the page as Control+Option+Arrow. So once the VoiceOver cursor reached
+  // the plus button (Safari focuses a control when the cursor lands on it), the toolbar ate
+  // every attempt to move off it and the user was trapped there.
+  //
+  // Asserted through defaultPrevented rather than through where focus ends up: with one control
+  // in the toolbar the handler's focus move is a no-op on itself, so focus looks correct in both
+  // the fixed and the broken version. Swallowing the key is the whole defect.
+  // Recorded on document, which sees the event after the toolbar's own listener has run.
+  await page.evaluate(() => {
+    const swallowed: string[] = [];
+
+    (window as ArrowKeyWindow).swallowedArrowKeys = swallowed;
+
+    document.addEventListener('keydown', (event) => {
+      if (event.defaultPrevented) {
+        swallowed.push(event.key);
+      }
+    });
+  });
+
+  await page.getByRole('button', { name: 'Add block' }).focus();
+
+  // Plain arrows are the toolbar's own, per the WAI-ARIA toolbar pattern. Everything modified
+  // belongs to someone else: the screen reader, the OS, or text selection.
+  await page.keyboard.press('ArrowRight');
+  await page.keyboard.press('Control+Alt+ArrowRight');
+  await page.keyboard.press('Control+Alt+ArrowLeft');
+  await page.keyboard.press('Meta+ArrowRight');
+  await page.keyboard.press('Shift+ArrowRight');
+
+  const swallowed = await page.evaluate(() => (window as ArrowKeyWindow).swallowedArrowKeys ?? []);
+
+  // Exactly one entry, from the unmodified press. Asserted as the whole list rather than as four
+  // separate negatives, so a handler that stops swallowing the plain arrow too - which would make
+  // every negative pass - fails here instead of quietly disabling the pattern.
+  expect(swallowed).toEqual(['ArrowRight']);
+});
+
+test.describe('toolbox', () => {
+  test('the plus button advertises the menu it controls', async ({ page }) => {
+    const plusButton = page.getByRole('button', { name: 'Add block' });
+
+    await expect(plusButton).toHaveAttribute('aria-haspopup', 'menu');
+    await expect(plusButton).toHaveAttribute('aria-expanded', 'false');
+
+    await plusButton.click();
+
+    await expect(plusButton).toHaveAttribute('aria-expanded', 'true');
+  });
+
+  test('opens a named menu listing the available block types', async ({ page }) => {
+    await page.getByRole('button', { name: 'Add block' }).click();
+
+    const menu = page.getByRole('menu', { name: 'Add block' });
+
+    await expect(menu).toBeVisible();
+
+    // 'Text' is the paragraph tool's toolbox title, which ui-kit turns into the
+    // item's accessible name.
+    await expect(menu.getByRole('menuitem', { name: 'Text' })).toBeVisible();
+  });
+
+  test('names the toolbox search field', async ({ page }) => {
+    await page.getByRole('button', { name: 'Add block' }).click();
+
+    await expect(page.getByRole('searchbox', { name: 'Search' })).toBeVisible();
+  });
+
+  test('moves focus onto a menu item with the arrow keys', async ({ page }) => {
+    await page.getByRole('button', { name: 'Add block' }).click();
+
+    await page.keyboard.press('ArrowDown');
+
+    // The desktop popover moves real DOM focus, so assistive tech follows along
+    // instead of only seeing a CSS class change.
+    await expect(page.getByRole('menuitem', { name: 'Text' })).toBeFocused();
+  });
+
+  test('inserts a block when a menu item is activated by keyboard', async ({ page }) => {
+    await page.getByRole('button', { name: 'Add block' }).click();
+    await page.keyboard.press('ArrowDown');
+    await page.keyboard.press('Enter');
+
+    await expect(page.getByRole('textbox', { name: 'Paragraph' })).toHaveCount(2);
+  });
+
+  test('hides filtered-out items from the accessibility tree while searching', async ({ page }) => {
+    await page.getByRole('button', { name: 'Add block' }).click();
+
+    const menu = page.getByRole('menu', { name: 'Add block' });
+
+    await expect(menu.getByRole('menuitem', { name: 'Text' })).toBeVisible();
+
+    await page.getByRole('searchbox', { name: 'Search' }).fill('no such tool');
+
+    // Filtering hides items with a CSS class; the `hidden` attribute alongside it is what
+    // takes them out of the accessibility tree, so a screen reader can't land on a result
+    // the sighted user can no longer see.
+    await expect(menu.getByRole('menuitem')).toHaveCount(0);
+
+    await page.getByRole('searchbox', { name: 'Search' }).fill('Te');
+
+    await expect(menu.getByRole('menuitem', { name: 'Text' })).toBeVisible();
+  });
+
+  test('returns focus to the plus button when dismissed with Escape', async ({ page }) => {
+    const plusButton = page.getByRole('button', { name: 'Add block' });
+
+    await plusButton.click();
+    await expect(page.getByRole('menu', { name: 'Add block' })).toBeVisible();
+
+    await page.keyboard.press('Escape');
+
+    await expect(page.getByRole('menu', { name: 'Add block' })).toBeHidden();
+
+    // Focus must come back to the control that opened the menu, per the WAI-ARIA menu button
+    // pattern. Safari doesn't focus a button on click, so without ToolbarUI focusing it
+    // explicitly the popover restores focus to <body> and a keyboard user loses their place.
+    await expect(plusButton).toBeFocused();
+    await expect(plusButton).toHaveAttribute('aria-expanded', 'false');
+  });
+
+  test('does not drop focus out of the editor after inserting a block', async ({ page }) => {
+    await page.getByRole('button', { name: 'Add block' }).click();
+    await page.keyboard.press('ArrowDown');
+    await page.keyboard.press('Enter');
+
+    await expect(page.getByRole('textbox', { name: 'Paragraph' })).toHaveCount(2);
+
+    // Deliberately does not pin *which* element holds focus: where it should land is the
+    // subject of the test below, which currently fails. This asserts only the invariant that
+    // holds either way — focus is on something real, not on the document body.
+    const focusedTag = await page.evaluate(() => document.activeElement?.tagName ?? 'NONE');
+
+    expect(['BODY', 'HTML', 'NONE']).not.toContain(focusedTag);
+  });
+
+  test('puts the caret in the block it just inserted', async ({ page }) => {
+    // Expected to fail: `ToolboxUI#addTool` passes `focus: true` to `blocks.insert`, but the
+    // caret does not follow, so focus falls back to the menu button the popover restores it to.
+    // Written as the behavior that *should* hold rather than the one that does — a passing
+    // assertion on the current behavior would turn fixing the todo into a test regression.
+    // Playwright fails the run if this ever starts passing, which is the signal to remove
+    // `test.fail()` and the todo together.
+    test.fail();
+
+    await page.getByRole('button', { name: 'Add block' }).click();
+    await page.keyboard.press('ArrowDown');
+    await page.keyboard.press('Enter');
+
+    const blocks = page.getByRole('textbox', { name: 'Paragraph' });
+
+    await expect(blocks).toHaveCount(2);
+    await expect(blocks.nth(1)).toBeFocused();
+  });
+});
+
+test.describe('inline toolbar', () => {
+  test('exposes the inline tools as a named toolbar of buttons', async ({ page }) => {
+    await selectParagraphText(page);
+
+    const inlineToolbar = page.getByRole('toolbar', { name: 'Text formatting' });
+
+    await expect(inlineToolbar).toBeVisible();
+    await expect(inlineToolbar.getByRole('button', { name: 'Bold' })).toBeVisible();
+    await expect(inlineToolbar.getByRole('button', { name: 'Italic' })).toBeVisible();
+  });
+
+  test('reports the applied formatting through aria-pressed', async ({ page }) => {
+    await selectParagraphText(page);
+
+    const boldButton = page.getByRole('button', { name: 'Bold' });
+
+    await expect(boldButton).toHaveAttribute('aria-pressed', 'false');
+
+    await boldButton.click();
+
+    // The popover is rebuilt on every selection change, so re-selecting the now-bold
+    // text is what produces the updated state.
+    await selectParagraphText(page);
+
+    await expect(page.getByRole('button', { name: 'Bold' })).toHaveAttribute('aria-pressed', 'true');
+  });
+
+  test('mirrors the highlighted tool onto aria-activedescendant of the focused editable', async ({ page }) => {
+    await selectParagraphText(page);
+
+    const boldButton = page.getByRole('button', { name: 'Bold' });
+
+    // Wait for the toolbar before navigating it: until the popover is rendered its keyboard
+    // handler is not listening yet, and ArrowDown would just collapse the selection.
+    await expect(boldButton).toBeVisible();
+
+    // The blocks holder is the outermost contenteditable, so the browser keeps focus there
+    // rather than on the individual block. aria-activedescendant is only honoured on the
+    // element that actually holds focus, which is what the toolbar points at.
+    const focusedEditable = page.getByRole('group');
+
+    await expect(focusedEditable).toBeFocused();
+
+    // The inline toolbar deliberately never takes focus itself — moving it to a button drops
+    // the text selection the tools operate on — so this is the only way the highlighted
+    // button reaches assistive tech.
+    await expect(focusedEditable).not.toHaveAttribute('aria-activedescendant');
+
+    await page.keyboard.press('ArrowDown');
+
+    const boldId = await boldButton.getAttribute('id');
+
+    expect(boldId).not.toBeNull();
+    await expect(focusedEditable).toHaveAttribute('aria-activedescendant', boldId as string);
+  });
+
+  test('claims the popover via aria-owns so the activedescendant resolves', async ({ page }) => {
+    await selectParagraphText(page);
+
+    const boldButton = page.getByRole('button', { name: 'Bold' });
+
+    await expect(boldButton).toBeVisible();
+    await page.keyboard.press('ArrowDown');
+
+    // aria-activedescendant is only honoured when it names an element inside the focused
+    // element's subtree, or one claimed by it via aria-owns. The inline toolbar is rendered as
+    // a *sibling* of the blocks holder, so the attribute matching the button's id proves
+    // nothing on its own — asserted here over the resolved relationship instead, which is what
+    // actually decides whether assistive tech follows the reference or silently drops it.
+    const resolution = await page.evaluate(() => {
+      const focused = document.activeElement as HTMLElement | null;
+      const itemId = focused?.getAttribute('aria-activedescendant') ?? null;
+      const ownsId = focused?.getAttribute('aria-owns') ?? null;
+      const item = itemId !== null ? document.getElementById(itemId) : null;
+      const owned = ownsId !== null ? document.getElementById(ownsId) : null;
+
+      return {
+        itemFound: item !== null,
+        ownedFound: owned !== null,
+        // The DOM stays untouched — this is an accessibility-tree relationship only.
+        itemIsDomDescendantOfFocused: item !== null && focused !== null && focused.contains(item),
+        itemIsInsideOwned: item !== null && owned !== null && owned.contains(item),
+      };
+    });
+
+    expect(resolution).toEqual({
+      itemFound: true,
+      ownedFound: true,
+      itemIsDomDescendantOfFocused: false,
+      itemIsInsideOwned: true,
+    });
+  });
+
+  test('gives each editor on a page its own inline toolbar', async ({ page, browserName }) => {
+    // Passes on webkit, fails on chromium, on a pre-existing bug that has nothing to do with
+    // ARIA: there, the inline toolbar is not scoped to its editor instance. Two editors mount
+    // two toolbars, but selecting text in the second one raises the *first* one's — positioned
+    // over the first editor, operating on the first editor's selection. Located directly to be
+    // sure of it: the popover that appears sits inside editor 0's wrapper whichever editor was
+    // clicked. Webkit raises the right one, so this is engine behaviour the selection pipeline
+    // depends on rather than a flat missing feature.
+    //
+    // Pinned per engine rather than skipped, so that fixing chromium trips the test instead of
+    // leaving it quietly asserting the bug, and so a webkit regression is caught meanwhile.
+    //
+    // What chromium fails on is the *first* assertion below, not the scoping one: because the
+    // raised toolbar belongs to another editor, `InlineToolbarUI` declines to claim its popover
+    // from this editor's holder at all (see #activeDescendantTarget), so `aria-owns` is absent
+    // rather than pointing at the wrong editor. That is deliberate — a missing claim is safer
+    // for a screen reader than a confident wrong one — but it means the symptom here is a null
+    // id, which on its own reads like the reference is broken rather than the toolbar misrouted.
+    test.fail(browserName === 'chromium', 'inline toolbar is not scoped per editor on chromium');
+
+    await mountDocument(page, '?editors=2');
+
+    // What only a multi-editor page can cover: `aria-owns` resolves by document-wide id lookup,
+    // so each toolbar's popover id has to be per instance. A single fixed id would point the
+    // second editor's blocks holder at the first editor's controls.
+    const claims: string[] = [];
+
+    for (const index of [0, 1]) {
+      await page.getByRole('textbox', { name: 'Paragraph' })
+        .nth(index)
+        .click({ clickCount: 3 });
+      await expect(page.getByRole('button', { name: 'Bold' })).toBeVisible();
+      await page.keyboard.press('ArrowDown');
+
+      const owned = await page.evaluate(() => {
+        const focused = document.activeElement as HTMLElement | null;
+        const ownsId = focused?.getAttribute('aria-owns') ?? null;
+        const target = ownsId !== null ? document.getElementById(ownsId) : null;
+
+        return {
+          ownsId,
+          /** The claimed popover has to belong to the editor whose text is being formatted */
+          isInSameEditor: target !== null && focused?.closest('.ejs-editor')?.contains(target) === true,
+        };
+      });
+
+      expect(owned.ownsId).not.toBeNull();
+      expect(owned.isInSameEditor).toBe(true);
+
+      claims.push(owned.ownsId as string);
+    }
+
+    expect(claims[0]).not.toBe(claims[1]);
+  });
+
+  test('releases the popover it claimed once the toolbar is dismissed', async ({ page }) => {
+    await selectParagraphText(page);
+
+    await expect(page.getByRole('button', { name: 'Bold' })).toBeVisible();
+    await page.keyboard.press('ArrowDown');
+
+    const focusedEditable = page.getByRole('group');
+
+    await expect(focusedEditable).toHaveAttribute('aria-owns', /.+/);
+
+    // A stale aria-owns would keep a destroyed popover claimed by the editable, leaving the
+    // accessibility tree pointing at a subtree the document no longer has.
+    await page.getByRole('textbox', { name: 'Paragraph' }).click();
+
+    await expect(focusedEditable).not.toHaveAttribute('aria-owns');
+    await expect(focusedEditable).not.toHaveAttribute('aria-activedescendant');
+  });
+
+  test('is reachable from the text by Tab', async ({ page }) => {
+    await selectParagraphText(page);
+
+    const boldButton = page.getByRole('button', { name: 'Bold' });
+
+    await expect(boldButton).toBeVisible();
+
+    await page.keyboard.press('Tab');
+
+    await expect(boldButton).toBeFocused();
+  });
+
+  test('exposes applied links as links in the text', async ({ page }) => {
+    await selectParagraphText(page);
+
+    const linkButton = page.getByRole('button', { name: 'Link' });
+
+    await expect(linkButton).toBeVisible();
+
+    await tabToInlineTool(page, linkButton);
+
+    await page.keyboard.press('Enter');
+    await page.keyboard.type('https://example.com');
+    await page.keyboard.press('Enter');
+
+    // The applied formatting has to reach the accessibility tree as a real link, otherwise a
+    // screen reader reads the text with no indication that part of it is navigable.
+    const link = page.getByRole('textbox', { name: 'Paragraph' }).getByRole('link');
+
+    await expect(link).toHaveCount(1);
+    await expect(link).toHaveAttribute('href', 'https://example.com');
+    await expect(link).toHaveText('Hello world');
+  });
+
+  test('announces its own appearance once via a live region', async ({ page }) => {
+    await selectParagraphText(page);
+
+    // ui-kit's own popover also carries a role="status" region (search/confirmation
+    // announcements), so this targets the toolbar's own by its test id, not by role alone.
+    const status = page.getByTestId('inline-toolbar-announcer');
+
+    await expect(status).toHaveText('Text formatting toolbar available. Press Tab to enter.');
+
+    // Shrinking the selection by one character keeps it non-empty throughout, so the toolbar
+    // stays continuously open and its popover is rebuilt (see the "reports the applied
+    // formatting" test above) without ever passing through a hidden state. It must not
+    // re-announce here - otherwise every character of a dragged selection would retrigger it.
+    await status.evaluate((el) => {
+      el.textContent = 'sentinel';
+    });
+
+    await page.keyboard.press('Shift+ArrowLeft');
+
+    await expect(page.getByRole('button', { name: 'Bold' })).toBeVisible();
+    await expect(status).toHaveText('sentinel');
+  });
+
+  test('announces again when the toolbar is genuinely reopened', async ({ page }) => {
+    const message = 'Text formatting toolbar available. Press Tab to enter.';
+    const status = page.getByTestId('inline-toolbar-announcer');
+
+    await selectParagraphText(page);
+
+    await expect(status).toHaveText(message);
+
+    // The other half of "once per open". `InlineToolbarUI#show` only announces on a genuine
+    // hidden-to-shown transition, so a regression that left its visibility state stuck would
+    // make the toolbar silent for the rest of the session - and the no-repeat test above would
+    // still pass, since it only ever proves the announcement *doesn't* fire.
+    await page.getByRole('textbox', { name: 'Paragraph' }).click();
+
+    await expect(page.getByRole('toolbar', { name: 'Text formatting' })).toBeHidden();
+
+    await status.evaluate((el) => {
+      el.textContent = 'sentinel';
+    });
+
+    await selectParagraphText(page);
+
+    await expect(page.getByRole('toolbar', { name: 'Text formatting' })).toBeVisible();
+    await expect(status).toHaveText(message);
+  });
+
+  test('announces again when reopened after being dismissed with Escape', async ({ page }) => {
+    const message = 'Text formatting toolbar available. Press Tab to enter.';
+    const status = page.getByTestId('inline-toolbar-announcer');
+    const inlineToolbar = page.getByRole('toolbar', { name: 'Text formatting' });
+
+    await selectParagraphText(page);
+
+    await expect(status).toHaveText(message);
+
+    // Escape is handled by the popover itself, not by the editor collapsing the selection,
+    // so the toolbar closes while the text stays selected.
+    await page.keyboard.press('Escape');
+
+    await expect(inlineToolbar).toBeHidden();
+
+    await status.evaluate((el) => {
+      el.textContent = 'sentinel';
+    });
+
+    // Shrinking the selection keeps it non-empty throughout, so the toolbar comes back without
+    // the editor ever hiding it on its own - only the popover's Closed event can have told it
+    // that the toolbar was gone in between.
+    await page.keyboard.press('Shift+ArrowLeft');
+
+    await expect(inlineToolbar).toBeVisible();
+    await expect(status).toHaveText(message);
+  });
+
+  test('takes its tools out of the accessibility tree when dismissed', async ({ page }) => {
+    await selectParagraphText(page);
+
+    const boldButton = page.getByRole('button', { name: 'Bold' });
+
+    await expect(boldButton).toBeVisible();
+
+    // Collapses the selection, which dismisses the toolbar.
+    await page.getByRole('textbox', { name: 'Paragraph' }).click();
+
+    await expect(page.getByRole('toolbar', { name: 'Text formatting' })).toBeHidden();
+
+    // Hidden isn't enough on its own: a control that is merely invisible can still be reachable
+    // by a virtual cursor, which would leave a screen reader able to land on tools that are no
+    // longer there. `#hide()` destroys the popover, which detaches it - this pins that, because
+    // switching to a plain `hide()` would look identical to a visibility assertion.
+    await expect(boldButton).toHaveCount(0);
+    await expect(page.getByRole('button', { name: 'Italic' })).toHaveCount(0);
+  });
+});
diff --git a/packages/editorjs/e2e/tests/axe.spec.ts b/packages/editorjs/e2e/tests/axe.spec.ts
new file mode 100644
index 00000000..e3d4decb
--- /dev/null
+++ b/packages/editorjs/e2e/tests/axe.spec.ts
@@ -0,0 +1,78 @@
+import AxeBuilder from '@axe-core/playwright';
+import { test, expect } from '@playwright/test';
+import type { Page } from '@playwright/test';
+import { mountDocument, selectParagraphText } from '../support/editor.js';
+
+test.beforeEach(async ({ page }) => {
+  await mountDocument(page);
+});
+
+/** Upper bound on waiting for the popovers' show animation, so a stuck one fails rather than hangs. */
+const ANIMATION_TIMEOUT = 5_000;
+
+/**
+ * Runs the audit over the editor once the UI has stopped moving.
+ *
+ * Structural/static accessibility checks (missing names, invalid roles, contrast, etc.). These
+ * catch a different class of bug than aria.spec.ts: axe flags anything that violates WCAG rules
+ * regardless of whether a test happens to assert on it, but it can't tell us whether a screen
+ * reader announces the *right* thing - that's what voiceover.spec.ts is for.
+ *
+ * The wait is not incidental. The popovers fade and grow in over ~100ms, and axe samples computed
+ * styles at the moment it runs, so an audit taken mid-animation measures a half-transparent panel
+ * and can report a violation that doesn't exist once it has settled. This suite failed exactly
+ * once that way, under a loaded parallel run, and never reproduced in isolation - so waiting for
+ * animations is a fix for the likeliest cause rather than a confirmed one, which is why the
+ * assertion below also names the offending rule.
+ * @param page - Playwright page the editor is mounted on
+ * @returns axe violations found, as `id (impact)` summaries
+ */
+async function auditEditor(page: Page): Promise<string[]> {
+  await page.waitForFunction(
+    () => document.getAnimations().every(animation => animation.playState !== 'running'),
+    undefined,
+    { timeout: ANIMATION_TIMEOUT }
+  );
+
+  const results = await new AxeBuilder({ page }).include('#editorjs')
+    .analyze();
+
+  // Summarised rather than asserted on the raw objects: a failure on the full result prints a
+  // wall of serialised nodes with the rule id buried in it, which is how the one failure this
+  // suite has had went unexplained.
+  return results.violations.map(violation => `${violation.id} (${violation.impact ?? 'unknown'}): ${violation.help}`);
+}
+
+test('has no automatically detectable accessibility violations on load', async ({ page }) => {
+  expect(await auditEditor(page)).toEqual([]);
+});
+
+test('has no automatically detectable accessibility violations with the toolbox open', async ({ page }) => {
+  await page.getByRole('button', { name: 'Add block' }).click();
+  await expect(page.getByRole('menu', { name: 'Add block' })).toBeVisible();
+
+  expect(await auditEditor(page)).toEqual([]);
+});
+
+test('has no automatically detectable accessibility violations with the inline toolbar open', async ({ page }) => {
+  await selectParagraphText(page);
+  await expect(page.getByRole('toolbar', { name: 'Text formatting' })).toBeVisible();
+
+  expect(await auditEditor(page)).toEqual([]);
+});
+
+test('has no automatically detectable accessibility violations while the inline toolbar is navigated', async ({ page }) => {
+  await selectParagraphText(page);
+  await expect(page.getByRole('toolbar', { name: 'Text formatting' })).toBeVisible();
+
+  // A separate state rather than a step in the case above: `aria-owns` and
+  // `aria-activedescendant` only exist once an item is highlighted, so the open-but-unnavigated
+  // audit never sees either of them. Axe checks that both resolve to real elements, which is
+  // the cheap half of what makes the reference followable at all (the other half - that the
+  // named item sits inside the owned subtree - is asserted in aria.spec.ts).
+  await page.keyboard.press('ArrowDown');
+
+  await expect(page.getByRole('group')).toHaveAttribute('aria-activedescendant', /.+/);
+
+  expect(await auditEditor(page)).toEqual([]);
+});
diff --git a/packages/editorjs/e2e/tests/editor.spec.ts b/packages/editorjs/e2e/tests/editor.spec.ts
new file mode 100644
index 00000000..4a85279d
--- /dev/null
+++ b/packages/editorjs/e2e/tests/editor.spec.ts
@@ -0,0 +1,79 @@
+import { test, expect } from '@playwright/test';
+import { mountDocument, selectParagraphText } from '../support/editor.js';
+
+test.beforeEach(async ({ page }) => {
+  await mountDocument(page);
+});
+
+test('renders the initial paragraph block', async ({ page }) => {
+  const paragraph = page.getByRole('textbox', { name: 'Paragraph' });
+
+  await expect(paragraph).toBeVisible();
+  await expect(paragraph).toHaveText('Hello world');
+});
+
+test('types into a paragraph block', async ({ page }) => {
+  const paragraph = page.getByRole('textbox', { name: 'Paragraph' });
+
+  // A real click places the caret via the browser's native selection instead
+  // of `locator.press`, which re-focuses the element programmatically and
+  // drops the editor's tracked caret position.
+  await paragraph.click();
+  await page.keyboard.press('End');
+  await page.keyboard.type('!');
+
+  await expect(paragraph).toHaveText('Hello world!');
+});
+
+test('bolds selected text via the inline toolbar', async ({ page }) => {
+  const paragraph = page.getByRole('textbox', { name: 'Paragraph' });
+
+  await selectParagraphText(page);
+
+  const boldButton = page.getByRole('button', { name: 'Bold' });
+
+  await expect(boldButton).toBeVisible();
+  await boldButton.click();
+
+  await expect(paragraph.locator('b')).toHaveText('Hello world');
+});
+
+test('keeps the inline toolbar open when its own control holds focus and the native selection drops', async ({ page }) => {
+  await selectParagraphText(page);
+
+  const boldButton = page.getByRole('button', { name: 'Bold' });
+
+  await expect(boldButton).toBeVisible();
+  await boldButton.focus();
+
+  /**
+   * Real Safari drops the text selection as a side effect once VoiceOver moves focus onto a
+   * button (see the `PopoverInline` class comment in ui-kit) - not reproducible through a
+   * plain Playwright click/focus on either engine, since `getSelection()` stays intact here.
+   * Simulating the resulting native selectionchange directly exercises the same code path:
+   * without the fix, the toolbar reads this as the user dismissing it and tears itself down.
+   */
+  await page.evaluate(() => window.getSelection()?.removeAllRanges());
+
+  await expect(page.getByRole('toolbar', { name: 'Text formatting' })).toBeVisible();
+});
+
+test('opens the link tool\'s URL input instead of closing the toolbar', async ({ page }) => {
+  const paragraph = page.getByRole('textbox', { name: 'Paragraph' });
+
+  await selectParagraphText(page);
+
+  const linkButton = page.getByRole('button', { name: 'Link' });
+
+  await expect(linkButton).toBeVisible();
+  await linkButton.click();
+
+  const linkInput = page.getByPlaceholder('Add a link');
+
+  await expect(linkInput).toBeVisible();
+
+  await linkInput.fill('https://editorjs.io');
+  await linkInput.press('Enter');
+
+  await expect(paragraph.locator('a[href="https://editorjs.io"]')).toHaveText('Hello world');
+});
diff --git a/packages/editorjs/e2e/tests/voiceover.spec.ts b/packages/editorjs/e2e/tests/voiceover.spec.ts
new file mode 100644
index 00000000..93e7ed21
--- /dev/null
+++ b/packages/editorjs/e2e/tests/voiceover.spec.ts
@@ -0,0 +1,1174 @@
+import { voiceOverTest as test } from '@guidepup/playwright';
+import { expect } from '@playwright/test';
+import type { Page } from '@playwright/test';
+import type { VoiceOverPlaywright } from '@guidepup/playwright';
+import { PLACEHOLDER, mountDocument, selectParagraphText, tabToInlineTool } from '../support/editor.js';
+
+/**
+ * Automates the manual checklist in openspec/changes/add-editor-aria-semantics/voiceover-verification.md
+ * against a real, running VoiceOver instance via Guidepup. macOS + Safari only - screen readers can't
+ * drive a headless browser, so this suite has its own config (playwright.voiceover.config.ts) and is
+ * excluded from the main `test:e2e` run. See e2e/README.md for how to run it locally.
+ *
+ * All 18 cases assert. Case 8 was the last one open - whether VoiceOver follows aria-activedescendant
+ * set on a contenteditable role="group" ancestor - and a real run settled it: **it does**, naming each
+ * highlighted tool in turn while DOM focus and the text selection stay put. It was never runnable
+ * before `aria-owns` landed, since the reference named an element outside the focused subtree and
+ * nothing could have followed it; it had been recorded as unknowable when the markup was simply broken.
+ *
+ * Every case mounts its own document rather than sharing a `beforeEach`: two of them need a document
+ * other than the default, and every VoiceOver command costs a real second or so, so a mount thrown
+ * away by the next line is not free the way it would be in the headless suite.
+ *
+ * Things learned from real runs shape the interaction pattern below:
+ *
+ * - Reaching and activating an item via VoiceOver's own commands (`.next()`/`.previous()`/`.act()`)
+ *   reliably produces correct, fresh announcements - confirmed by Case 3 and Case 4. But
+ *   `voiceOver.press()` for raw keys (Tab, Enter, Shift+Arrow) does not reliably deliver as a real
+ *   keypress in this environment - it left `toBeFocused()` assertions timing out on elements that a
+ *   `page.keyboard.press()` Tab reaches every time (proven separately by `aria.spec.ts`). So: use
+ *   `voiceOver.next()`/`.previous()`/`.act()` to navigate and activate by VoiceOver's own cursor, and
+ *   `page.keyboard`/`.click()` for anything that specifically needs to move real DOM focus (the Tab
+ *   path itself is what Case 6 is testing) - then read the result back through `voiceOver`.
+ * - Reading it back requires one extra step: VoiceOver does not observe Playwright's synthesized
+ *   events at all, so after a `page`-driven focus change its cursor is still on the previous item
+ *   and describes that instead. `syncCursorToFocus()` points it at the focused element first.
+ * - The same staleness applies to the *page*, not just the cursor: until VoiceOver runs a navigation
+ *   command of its own it keeps answering from the accessibility tree it had before, so a scan taken
+ *   straight after a page-driven DOM change can describe elements that are already gone. Anything
+ *   reading the page back after such a change has to go through `resetCursor()` first, which pairs
+ *   `navigateToWebContent()` with the navigation command that refreshes it - mid-test resets need it
+ *   just as much as the initial mount does. This is what makes Cases 11 and 18 deterministic.
+ * - A focus change caused by VoiceOver's *own* command is the opposite - it does follow that one.
+ *   `act()` on the plus button lands the cursor in the toolbox's search field, not on the button
+ *   it just activated, so anything that wants the activated control back has to walk backward.
+ * - `spokenPhraseLog()` is not a live tap on VoiceOver's speech. Guidepup samples the last spoken
+ *   phrase only while executing one of its own commands and appends it to a store; the getter just
+ *   returns that store. So polling it in a loop can never observe anything - without a command
+ *   nothing is ever sampled - and speech triggered by the page alone (a live region, say) has to be
+ *   pulled in by issuing a command afterwards, e.g. VO-Z (`repeatLastSpokenPhrase`).
+ */
+
+/**
+ * How VoiceOver names the textbox role. It says "text entry area" for the editor's
+ * `role="textbox"` + `aria-multiline="true"` contenteditable in Safari; the other two wordings
+ * are what it uses for single-line and legacy cases, kept so a verbosity or OS difference
+ * doesn't read as a regression.
+ */
+const TEXTBOX_ROLE = /text field|edit text|text entry area/;
+
+/**
+ * How far after a tool's name its pressed state can appear before the match stops counting.
+ * Wide enough for the shortcut VoiceOver reads in between ("Bold ⌘+B selected"), narrow enough
+ * that the two have to belong to the same announcement.
+ */
+const STATE_PROXIMITY = 40;
+
+/**
+ * How VoiceOver reports `aria-pressed="true"` for the tool named `name`.
+ *
+ * It maps the ARIA pressed state onto its own toggle vocabulary - a pressed toolbar button reads
+ * as "Bold selected, toggle button", not "pressed" - so the literal word never appears; it's kept
+ * in the pattern only so a verbosity or OS difference doesn't read as a regression.
+ *
+ * Anchored to the tool's own name rather than matching the bare word, because the toolbar only
+ * exists while text is *selected*: an unanchored /selected/ can be satisfied by VoiceOver
+ * describing the selection instead of the button, which would make the positive assertion pass
+ * without the state being exposed at all and the negative one fail without it being exposed either.
+ * @param name - the tool's accessible name, lowercased
+ */
+function pressedState(name: string): RegExp {
+  return new RegExp(`${name}[\\s\\S]{0,${STATE_PROXIMITY}}?(selected|pressed)`);
+}
+
+/**
+ * Inline tool names, for asserting that no tool is reachable anymore.
+ *
+ * Bold and Italic only: they can't occur in the fixture's text, where "link" is a common enough
+ * word that a future fixture change could make a genuine absence look like a leftover control.
+ */
+const INLINE_TOOL_NAME = /\bbold\b|\bitalic\b/;
+
+/**
+ * VoiceOver's spoken-phrase log mixes in caret/typing chatter, and itemText() alone doesn't
+ * necessarily carry every bit of state VoiceOver announces (e.g. popup/pressed state) - so
+ * assertions check both combined rather than betting on one or the other.
+ * @param voiceOver - Guidepup VoiceOver controller
+ */
+async function describeCurrentItem(voiceOver: VoiceOverPlaywright): Promise<string> {
+  const [item, phrase] = await Promise.all([voiceOver.itemText(), voiceOver.lastSpokenPhrase()]);
+
+  return `${item} ${phrase}`.toLowerCase();
+}
+
+/** Test-only channel for the recorded live-region announcements. */
+interface AnnouncementWindow extends Window {
+  /** Messages the inline toolbar's live region has been filled with, in order. */
+  inlineToolbarAnnouncements?: string[];
+}
+
+/**
+ * Starts recording every message the inline toolbar's live region is filled with.
+ *
+ * The region is emptied and refilled on each announcement, so one announcement is one
+ * non-empty fill - which makes a repeat countable at the source, where VoiceOver's spoken
+ * phrase log only shows identical text twice.
+ * @param page - Playwright page the editor is mounted on
+ * @returns getter for the messages recorded so far, in order
+ */
+async function trackAnnouncements(page: Page): Promise<() => Promise<string[]>> {
+  await page.evaluate(() => {
+    const recorded: string[] = [];
+
+    (window as AnnouncementWindow).inlineToolbarAnnouncements = recorded;
+
+    const announcerSelector = '[data-testid="inline-toolbar-announcer"]';
+
+    new MutationObserver((mutations) => {
+      // The observer has to watch the whole body - the toolbar (and its live region) is created
+      // and destroyed per selection - so mutations from anywhere else have to be filtered out.
+      // Without this, any unrelated DOM change while the region held a message would record a
+      // phantom repeat.
+      const touchedAnnouncer = mutations.some((mutation) => {
+        const target = mutation.target instanceof Element ? mutation.target : mutation.target.parentElement;
+
+        return target?.closest(announcerSelector) != null;
+      });
+
+      if (!touchedAnnouncer) {
+        return;
+      }
+
+      const message = document.querySelector(announcerSelector)?.textContent?.trim();
+
+      if (message !== undefined && message !== '') {
+        recorded.push(message);
+      }
+    }).observe(document.body, {
+      subtree: true,
+      childList: true,
+      characterData: true,
+    });
+  });
+
+  return async () => page.evaluate(() => (window as AnnouncementWindow).inlineToolbarAnnouncements ?? []);
+}
+
+/**
+ * Points VoiceOver's cursor at whatever currently holds real DOM focus (VO-Shift-F4).
+ *
+ * Playwright's synthesized key events move real focus - `toBeFocused()` confirms it - but
+ * VoiceOver doesn't observe them, so it keeps describing wherever its own cursor was left.
+ * This is VoiceOver's own command, delivered through the same channel as `next()`/`act()`
+ * (which are reliable here), unlike `voiceOver.press()` for plain keys (which isn't).
+ * @param voiceOver - Guidepup VoiceOver controller
+ */
+async function syncCursorToFocus(voiceOver: VoiceOverPlaywright): Promise<void> {
+  await voiceOver.perform(voiceOver.keyboardCommands.moveCursorToKeyboardFocus);
+}
+
+/** Upper bound when looking for a specific item, so a missing one fails fast instead of hanging. */
+const FIND_MAX_STEPS = 40;
+
+/**
+ * Moves VoiceOver's own cursor - not Playwright's DOM focus - until the current item's text
+ * matches `pattern`, mirroring how a VoiceOver user explores the page (VO+Right repeatedly)
+ * rather than jumping straight to a known element.
+ *
+ * Returns what was announced at every stop along the way, including the matching one, so a case
+ * that cares about what a user meets *en route* (Case 3, reaching the plus button through its
+ * toolbar) doesn't have to walk the same ground twice.
+ * @param voiceOver - Guidepup VoiceOver controller
+ * @param pattern - matched against the current item's text after each step
+ * @param direction - `next` (VO+Right) or `previous` (VO+Left)
+ * @param maxSteps - upper bound so a missing item fails fast instead of hanging
+ */
+async function walkTo(
+  voiceOver: VoiceOverPlaywright,
+  pattern: RegExp,
+  direction: 'next' | 'previous' = 'next',
+  maxSteps = FIND_MAX_STEPS
+): Promise<string[]> {
+  const descriptions: string[] = [];
+
+  for (let step = 0; step < maxSteps; step++) {
+    const item = await voiceOver.itemText();
+
+    descriptions.push(`${item} ${await voiceOver.lastSpokenPhrase()}`.toLowerCase());
+
+    // Matched against the item text alone: the fuller description folds in the last *spoken*
+    // phrase, which can still be describing the previous stop and would stop the walk short.
+    if (pattern.test(item)) {
+      return descriptions;
+    }
+
+    if (direction === 'next') {
+      await voiceOver.next();
+    } else {
+      await voiceOver.previous();
+    }
+  }
+
+  throw new Error(`VoiceOver did not reach an item matching ${pattern.toString()} within ${maxSteps} ${direction} steps`);
+}
+
+/**
+ * Moves VoiceOver's cursor to the first item matching `pattern`, discarding the route.
+ * @param voiceOver - Guidepup VoiceOver controller
+ * @param pattern - matched against the current item's text after each step
+ * @param direction - `next` (VO+Right) or `previous` (VO+Left)
+ */
+async function findItem(
+  voiceOver: VoiceOverPlaywright,
+  pattern: RegExp,
+  direction: 'next' | 'previous' = 'next'
+): Promise<void> {
+  await walkTo(voiceOver, pattern, direction);
+}
+
+/**
+ * Sends VoiceOver's cursor back to the start of the web content, ready to be read from.
+ *
+ * `navigateToWebContent()` on its own is not enough: it leaves VoiceOver latched onto whatever it
+ * first landed on, so the next `itemText()` can still describe the page as it was before the last
+ * DOM change - anything driven from `page` is invisible to VoiceOver until it runs a navigation
+ * command of its own. Round-tripping forward and back is that command, and leaves the logical
+ * cursor position unchanged. Anything that resets the cursor mid-test has to do this too, not just
+ * the initial mount; sampling straight after the reset is what made Case 18 non-deterministic.
+ * @param voiceOver - Guidepup VoiceOver controller
+ */
+async function resetCursor(voiceOver: VoiceOverPlaywright): Promise<void> {
+  // Also clears the spoken-phrase/item-text logs.
+  await voiceOver.navigateToWebContent();
+
+  await voiceOver.next();
+  await voiceOver.previous();
+}
+
+/**
+ * Loads the fixture and puts VoiceOver's cursor on the editor's first block.
+ * @param page - Playwright page to mount the editor on
+ * @param voiceOver - Guidepup VoiceOver controller
+ * @param search - query string to mount with, e.g. `?text=Alpha&text=Beta`
+ */
+async function mountEditor(page: Page, voiceOver: VoiceOverPlaywright, search = ''): Promise<void> {
+  await mountDocument(page, search);
+
+  await resetCursor(voiceOver);
+}
+
+/**
+ * The paragraph is the very first item in the editor's web content, so a forward walk long
+ * enough to leave it behind covers everything a user would meet on the way out.
+ */
+const FORWARD_WALK_STEPS = 6;
+
+/** Long enough for a forward walk to leave a three-block document behind. */
+const MULTI_BLOCK_WALK_STEPS = 12;
+
+/** Enough stops to get from the toolbox's search field back out to the button that opened it. */
+const BACKWARD_WALK_STEPS = 6;
+
+/** Stops to read across inside the block once interacting with it. */
+const INSIDE_BLOCK_STEPS = 6;
+
+/** Upper bound for a full sweep of the editor's web content, both when looking for an item and when proving one is absent. */
+const SCAN_STEPS = 25;
+
+/**
+ * Steps VoiceOver's cursor and returns what it announced at each stop, lowercased.
+ *
+ * Several cases below are about what a user meets while exploring rather than about one
+ * specific stop - which item carries a given piece of state isn't something a test should
+ * hardcode - so they assert over the whole walk instead of a single `itemText()`.
+ * @param voiceOver - Guidepup VoiceOver controller
+ * @param steps - how many times to move the cursor
+ * @param direction - `next` (VO+Right) or `previous` (VO+Left)
+ */
+async function walk(
+  voiceOver: VoiceOverPlaywright,
+  steps: number,
+  direction: 'next' | 'previous' = 'next'
+): Promise<string[]> {
+  const items: string[] = [];
+
+  for (let step = 0; step < steps; step++) {
+    if (direction === 'next') {
+      await voiceOver.next();
+    } else {
+      await voiceOver.previous();
+    }
+
+    items.push((await voiceOver.itemText()).toLowerCase());
+  }
+
+  return items;
+}
+
+/**
+ * Like `walk`, but records where the cursor already is before moving it.
+ *
+ * The difference matters whenever the item the cursor starts on is part of what's being
+ * examined: `walk` answers "what is ahead of here" and `sweep` answers "what is reachable from
+ * here". A case proving something is *absent* wants the second, and so does any guard checking
+ * that the scan really covered the editor - `resetCursor` leaves the cursor on the first block,
+ * which `walk` would step straight past and never record.
+ * @param voiceOver - Guidepup VoiceOver controller
+ * @param steps - how many stops to record
+ * @param direction - `next` (VO+Right) or `previous` (VO+Left)
+ */
+async function sweep(
+  voiceOver: VoiceOverPlaywright,
+  steps: number,
+  direction: 'next' | 'previous' = 'next'
+): Promise<string[]> {
+  const items: string[] = [];
+
+  for (let step = 0; step < steps; step++) {
+    items.push((await voiceOver.itemText()).toLowerCase());
+
+    if (direction === 'next') {
+      await voiceOver.next();
+    } else {
+      await voiceOver.previous();
+    }
+  }
+
+  return items;
+}
+
+/**
+ * Like `walk`, but records the full description at each stop rather than the item text alone.
+ *
+ * Kept separate because most walks are looking for *which* item they reached, and folding in
+ * the last spoken phrase - which can still be describing a previous stop - would make that
+ * ambiguous. Use this one when the question is what a user hears, not where they are.
+ * @param voiceOver - Guidepup VoiceOver controller
+ * @param steps - how many times to move the cursor
+ * @param direction - `next` (VO+Right) or `previous` (VO+Left)
+ */
+async function describeWalk(
+  voiceOver: VoiceOverPlaywright,
+  steps: number,
+  direction: 'next' | 'previous' = 'next'
+): Promise<string[]> {
+  const descriptions: string[] = [];
+
+  for (let step = 0; step < steps; step++) {
+    if (direction === 'next') {
+      await voiceOver.next();
+    } else {
+      await voiceOver.previous();
+    }
+
+    descriptions.push(await describeCurrentItem(voiceOver));
+  }
+
+  return descriptions;
+}
+
+test('Case 1: exposes the paragraph as the only text field, with no editable region wrapping it', async ({ page, voiceOver }) => {
+  await mountEditor(page, voiceOver);
+
+  const paragraphDescription = await describeCurrentItem(voiceOver);
+
+  expect(paragraphDescription).toContain('paragraph');
+  expect(paragraphDescription).toMatch(TEXTBOX_ROLE);
+
+  // VoiceOver never surfaces the blocks holder as an item of its own: an unnamed role="group"
+  // is structurally transparent to the virtual cursor (it's not a landmark and has no name to
+  // announce), which is why a backward scan for "group" found nothing and why stopInteracting()
+  // from here jumps straight out of the whole web content rather than up into a group level.
+  // So the holder's role isn't directly assertable through VoiceOver - what *is* assertable is
+  // the effect the role change was made for: no second, outer editable region. aria.spec.ts
+  // covers the role="group" attribute itself.
+  //
+  // Backward first: the paragraph is the first item VoiceOver reaches, so previous() is a hard
+  // no-op. Before role="group", the holder's contenteditable was implicitly a textbox and would
+  // have been the item you landed on ahead of it.
+  const beforeStepBack = await voiceOver.itemText();
+
+  // Anchors the no-op below. "Nothing is exposed ahead of the block" only follows from a
+  // stationary cursor while the block really is where the cursor starts; if the fixture ever
+  // mounts anything above the editor, the step back becomes a real move between two unrelated
+  // items and quietly proves nothing. This fails loudly in that case instead.
+  expect(beforeStepBack.toLowerCase()).toContain('hello world');
+
+  await voiceOver.previous();
+
+  expect(await voiceOver.itemText()).toBe(beforeStepBack);
+
+  // Forward: walking out of the paragraph must not meet another text field either.
+  const itemsAhead = await walk(voiceOver, FORWARD_WALK_STEPS);
+
+  expect(itemsAhead.filter(item => TEXTBOX_ROLE.test(item))).toEqual([]);
+});
+
+test('Case 2: announces the paragraph by name and role, and lets VoiceOver users type', async ({ page, voiceOver }) => {
+  await mountEditor(page, voiceOver);
+
+  const paragraph = page.getByRole('textbox', { name: 'Paragraph' });
+
+  const phrase = await describeCurrentItem(voiceOver);
+
+  expect(phrase).toContain('paragraph');
+  expect(phrase).toMatch(TEXTBOX_ROLE);
+
+  // VoiceOver's cursor sitting on the paragraph does not put the caret in it, and
+  // voiceOver.press()/type() don't reliably deliver as real keystrokes here (same finding as
+  // the header comment - the text was left untouched). Type the way e2e/README.md prescribes:
+  // a real click to place the caret, then page.keyboard.
+  await paragraph.click();
+  await page.keyboard.press('End');
+  await page.keyboard.type('!');
+
+  await expect(paragraph).toHaveText('Hello world!');
+
+  // The multiline half of the checklist item: VoiceOver must still see one editable field
+  // holding the whole text, not a line-truncated one. Whether it *echoes* the typed character
+  // is a VoiceOver typing-echo preference, not something aria-multiline affects, so it isn't
+  // asserted here.
+  await voiceOver.next();
+  await voiceOver.previous();
+
+  const afterTyping = await describeCurrentItem(voiceOver);
+
+  expect(afterTyping).toContain('hello world!');
+  expect(afterTyping).toMatch(TEXTBOX_ROLE);
+});
+
+test('Case 3: announces the plus-button with its popup relationship', async ({ page, voiceOver }) => {
+  await mountEditor(page, voiceOver);
+
+  const onTheWay = await walkTo(voiceOver, /add block/i);
+  const phrase = onTheWay[onTheWay.length - 1];
+
+  expect(phrase).toContain('add block');
+  expect(phrase).toMatch(/menu/);
+
+  // The checklist's third expectation - that the button is identifiable as part of a toolbar
+  // named "Block actions" - is pinned inverted rather than dropped, so that a VoiceOver version
+  // which does start announcing it fails here and prompts this back into a real assertion.
+  // Observed: the cursor goes from the block straight onto the button in a single
+  // step, announcing "add block menu pop-up button" and nothing about a container; the whole
+  // route from the block to the button contains no mention of the toolbar at all.
+  //
+  // This was an inference that turned out to be wrong, not a regression. Case 1 establishes that
+  // the *unnamed* blocks holder is transparent to the virtual cursor because it has no name to
+  // announce, and the reasonable-looking converse - that a named container therefore is
+  // announced - simply does not hold for linear VO+Right navigation. Whether VoiceOver's group
+  // navigation or the rotor would surface the name was not tested; the browse cursor is the path
+  // these cases are about.
+  //
+  // The name itself is correct and asserted at the DOM level in aria.spec.ts, so what is
+  // untestable here is VoiceOver's reporting of it, not the editor's markup. Same disposition as
+  // the `aria-expanded` finding in Case 15, and recorded alongside it in voiceover-verification.md.
+  expect(onTheWay.join(' | ')).not.toContain('block actions');
+});
+
+test.describe('Case 4: toolbox menu', () => {
+  test('announces the named menu and lets VoiceOver reach and activate an item', async ({ page, voiceOver }) => {
+    await mountEditor(page, voiceOver);
+
+    await findItem(voiceOver, /add block/i);
+    await voiceOver.act();
+
+    const menu = page.getByRole('menu', { name: 'Add block' });
+
+    await expect(menu).toBeVisible();
+
+    await voiceOver.clearSpokenPhraseLog();
+    await findItem(voiceOver, /text/i);
+
+    // Aggregated over the whole scan rather than a single moment, since it's the menu
+    // container and/or its search field that carry the "menu"/"search" wording, and
+    // exactly which item announces it first isn't something this test should hardcode.
+    const menuLog = (await voiceOver.spokenPhraseLog()).join(' ').toLowerCase();
+
+    expect(menuLog).toMatch(/menu|search/);
+
+    const itemPhrase = await describeCurrentItem(voiceOver);
+
+    expect(itemPhrase).toContain('text');
+
+    await voiceOver.act();
+
+    await expect(page.getByRole('textbox', { name: 'Paragraph' })).toHaveCount(2);
+
+    // Activating an item has to finish the interaction, not just insert: a menu left open over
+    // the document, or a user dropped onto <body>, is how "focus jumped to the whole page" felt
+    // in the original report. Which element ends up focused is deliberately not pinned - that is
+    // the subject of the todo aria.spec.ts marks `test.fail()` - only that it is a real one.
+    await expect(menu).toBeHidden();
+
+    const focusedTag = await page.evaluate(() => document.activeElement?.tagName ?? 'NONE');
+
+    expect(['BODY', 'HTML', 'NONE']).not.toContain(focusedTag);
+
+    // And VoiceOver still has somewhere to be afterwards, rather than being left describing the
+    // menu it just closed.
+    await resetCursor(voiceOver);
+
+    expect((await describeCurrentItem(voiceOver)).trim().length).toBeGreaterThan(0);
+  });
+});
+
+test.describe('Case 5 & 6: inline toolbar', () => {
+  test('is reachable and traversable via Tab, and reports the applied formatting through aria-pressed', async ({ page, voiceOver }) => {
+    await mountEditor(page, voiceOver);
+    await selectParagraphText(page);
+
+    const inlineToolbar = page.getByRole('toolbar', { name: 'Text formatting' });
+
+    await expect(inlineToolbar).toBeVisible();
+
+    await page.keyboard.press('Tab');
+
+    const boldButton = page.getByRole('button', { name: 'Bold' });
+
+    await expect(boldButton).toBeFocused();
+    await syncCursorToFocus(voiceOver);
+
+    const unpressedPhrase = await describeCurrentItem(voiceOver);
+
+    expect(unpressedPhrase).toContain('bold');
+    expect(unpressedPhrase).toContain('button');
+    expect(unpressedPhrase).not.toMatch(pressedState('bold'));
+
+    // Tab keeps moving through the toolbar and Shift+Tab comes back, which is the rest of what
+    // makes this the recommended path in for keyboard and AT users. Which tool is second is
+    // deliberately not pinned - tab order among the tools isn't asserted anywhere - only that
+    // the step lands on another of the toolbar's own buttons and is announced as one.
+    await page.keyboard.press('Tab');
+
+    await expect(boldButton).not.toBeFocused();
+
+    const focusedInsideToolbar = await inlineToolbar.evaluate(
+      toolbar => document.activeElement !== null && toolbar.contains(document.activeElement)
+    );
+
+    expect(focusedInsideToolbar).toBe(true);
+
+    await syncCursorToFocus(voiceOver);
+
+    expect(await describeCurrentItem(voiceOver)).toContain('button');
+
+    await page.keyboard.press('Shift+Tab');
+
+    await expect(boldButton).toBeFocused();
+
+    await page.keyboard.press('Enter');
+    await expect(boldButton).toHaveAttribute('aria-pressed', 'true');
+
+    // The popover is rebuilt on every selection change, so re-selecting the now-bold text is
+    // what produces the updated aria-pressed state.
+    await selectParagraphText(page);
+    await page.keyboard.press('Tab');
+
+    await expect(page.getByRole('button', { name: 'Bold' })).toBeFocused();
+    await syncCursorToFocus(voiceOver);
+
+    expect(await describeCurrentItem(voiceOver)).toMatch(pressedState('bold'));
+  });
+});
+
+/** Settling window for asserting an announcement did *not* happen. */
+const NO_ANNOUNCEMENT_SETTLE = 1_000;
+
+test('Case 7: announces the toolbar becoming available exactly once per open', async ({ page, voiceOver }) => {
+  await mountEditor(page, voiceOver);
+
+  // "Exactly once" is counted at the source rather than inferred from VoiceOver's speech log:
+  // InlineToolbarUI#announce clears the live region and fills it back in on a timer, so a
+  // repeat is a second fill - visible here as a second recorded entry, but indistinguishable
+  // from the first in a log of spoken phrases.
+  const announcements = await trackAnnouncements(page);
+  const message = 'Text formatting toolbar available. Press Tab to enter.';
+  const inlineToolbar = page.getByRole('toolbar', { name: 'Text formatting' });
+
+  await voiceOver.clearSpokenPhraseLog();
+
+  await selectParagraphText(page);
+
+  await expect(inlineToolbar).toBeVisible();
+
+  await expect.poll(announcements).toEqual([message]);
+
+  // The live region carrying the message is only half of it - VoiceOver has to actually speak
+  // it. Getting that into the log takes a command: Guidepup only samples VoiceOver's speech
+  // as part of executing one (see the header comment), so polling spokenPhraseLog() on its own
+  // can never observe an announcement that nothing asked for. VO-Z re-speaks the last phrase,
+  // which is the announcement if VoiceOver picked the live region up - and is captured because
+  // it goes through a command.
+  await voiceOver.perform(voiceOver.keyboardCommands.repeatLastSpokenPhrase);
+
+  expect((await voiceOver.spokenPhraseLog()).join(' ')).toContain('Text formatting toolbar available');
+
+  // Shrinks and grows the selection while it stays open and non-empty - the toolbar's popover
+  // rebuilds on every change, but the "available" announcement must not repeat.
+  await page.keyboard.press('Shift+ArrowLeft');
+  await page.keyboard.press('Shift+ArrowRight');
+
+  await expect(inlineToolbar).toBeVisible();
+  await page.waitForTimeout(NO_ANNOUNCEMENT_SETTLE);
+
+  expect(await announcements()).toHaveLength(1);
+
+  // The other half of "per open", and the direction the assertions above can't fail in:
+  // InlineToolbarUI#show only announces on a genuine hidden-to-shown transition, so a
+  // regression leaving its visibility state stuck would make the toolbar silent for the rest of
+  // the session while every "does not repeat" check above still passed.
+  await page.getByRole('textbox', { name: 'Paragraph' }).click();
+
+  await expect(inlineToolbar).toBeHidden();
+
+  await selectParagraphText(page);
+
+  await expect(inlineToolbar).toBeVisible();
+  await expect.poll(announcements).toEqual([message, message]);
+});
+
+/** What the focused element points at via aria-activedescendant, at one moment. */
+interface ActiveDescendantReading {
+  /** Value of aria-activedescendant, or null when nothing is highlighted */
+  id: string | null;
+
+  /** Accessible name of the element that id resolves to, so a reading names a tool rather than an id */
+  name: string | null;
+
+  /** Whether the reference is followable at all: it names a real element inside the claimed subtree */
+  resolves: boolean;
+}
+
+/**
+ * Reads back what the focused element currently points at, and what that resolves to.
+ *
+ * The name is read off the element rather than assumed from the press count: which item a given
+ * number of arrow presses lands on is ui-kit's business, and pinning it here would make this
+ * measurement fail for a reason that has nothing to do with what it measures.
+ * @param page - Playwright page the editor is mounted on
+ * @returns the id pointed at, the accessible name it resolves to, and whether the reference is followable
+ */
+async function readActiveDescendant(page: Page): Promise<ActiveDescendantReading> {
+  return page.evaluate(() => {
+    const focused = document.activeElement as HTMLElement | null;
+    const id = focused?.getAttribute('aria-activedescendant') ?? null;
+    const ownsId = focused?.getAttribute('aria-owns') ?? null;
+    const item = id !== null ? document.getElementById(id) : null;
+    const owned = ownsId !== null ? document.getElementById(ownsId) : null;
+
+    return {
+      id,
+      name: item?.getAttribute('aria-label') ?? item?.textContent?.trim() ?? null,
+      /** Followable means: named, and inside the subtree the focused element claims */
+      resolves: item !== null && owned !== null && owned.contains(item),
+    };
+  });
+}
+
+/** Arrow presses taken, so that a second, different tool proves the reference is being tracked. */
+const ACTIVEDESCENDANT_STEPS = 2;
+
+/**
+ * How long to wait for VoiceOver to get round to announcing a newly highlighted item.
+ *
+ * The announcement is asynchronous and unsignalled: the arrow key changes `aria-activedescendant`,
+ * VoiceOver notices, and it speaks whenever its queue reaches it. A single `VO-Z` straight after
+ * the keypress samples whatever was last *completed* instead - on a loaded machine that is still
+ * the selection announcement from the click that opened the toolbar ("Hello world selected"),
+ * which is exactly how this case first failed. Asking repeatedly is the only way to tell
+ * "VoiceOver does not announce this" apart from "VoiceOver has not announced it yet".
+ */
+const ANNOUNCEMENT_TIMEOUT = 20_000;
+
+/**
+ * How long to leave VoiceOver alone between asks. Load-bearing, not a politeness: `VO-Z` is itself
+ * speech, so polling it tightly would keep interrupting the very phrase being waited for.
+ */
+const ANNOUNCEMENT_INTERVAL = 1_500;
+
+/** One arrow step: the tool the reference named, and what VoiceOver said about it. */
+interface HighlightReading {
+  /** Accessible name of the item `aria-activedescendant` pointed at, lowercased */
+  name: string;
+
+  /** VoiceOver's spoken phrase log for that step, joined and lowercased */
+  spoken: string;
+}
+
+test('Case 8: announces the highlighted inline tool without moving focus off the text', async ({ page, voiceOver }) => {
+  /**
+   * The open question this whole change carried, now settled by a real run: **VoiceOver does
+   * follow `aria-activedescendant` set on the contenteditable `role="group"` blocks holder.**
+   * Arrowing to Bold is announced "Bold toggle button", arrowing on to Italic "Italic toggle
+   * button" - each naming exactly the item the reference points at, with DOM focus never leaving
+   * the text and the selection intact throughout.
+   *
+   * Two things worth keeping in view:
+   * - It could not have worked before `aria-owns` landed. The reference named an element outside
+   *   the focused subtree, so there was nothing for VoiceOver to resolve; the case had been left
+   *   unrun on the grounds that the answer was unknowable, when in fact the markup was broken.
+   * - "toggle button" rather than "button" is `aria-pressed` reaching speech on this path too,
+   *   which is ui-kit's doing. Not asserted here - Case 5 & 6 owns the pressed state, and pinning
+   *   it in this case would make it fail for a reason that has nothing to do with its subject.
+   */
+  await mountEditor(page, voiceOver);
+  await selectParagraphText(page);
+
+  const inlineToolbar = page.getByRole('toolbar', { name: 'Text formatting' });
+
+  await expect(inlineToolbar).toBeVisible();
+
+  const blocksHolder = page.getByRole('group');
+
+  // The holder is the outermost contenteditable, so it is what keeps focus - which is why the
+  // reference has to live there rather than on the block. Covered headlessly in aria.spec.ts.
+  await expect(blocksHolder).toBeFocused();
+  await expect(blocksHolder).not.toHaveAttribute('aria-activedescendant');
+
+  /**
+   * Load-bearing, and the reason this case first failed in the suite while passing on its own.
+   *
+   * `aria-activedescendant` is only reported for the element VoiceOver is actually watching, and
+   * the selection above was made by a Playwright click - an event VoiceOver does not observe at
+   * all, so its cursor is still wherever the previous case left it. Run alone that happened to be
+   * close enough to the block for the announcement to come through; run after sixteen other
+   * cases it was not, and VoiceOver sat on "Hello world selected" through twenty seconds of
+   * asking. This is the rule in this file's header, and every other case that reads VoiceOver
+   * back after a page-driven focus change already follows it
+   */
+  await syncCursorToFocus(voiceOver);
+
+  /** Captured once, purely so a future failure says where VoiceOver was looking when it happened */
+  const cursorAt = await describeCurrentItem(voiceOver);
+
+  const selectionBefore = await page.evaluate(() => window.getSelection()?.toString() ?? '');
+
+  const heard: HighlightReading[] = [];
+
+  /**
+   * Two steps, not one. A single reading cannot tell "VoiceOver announced the highlighted item"
+   * apart from "VoiceOver happened to still be saying something about the toolbar" - but if it
+   * follows the reference, the second step names a different tool than the first
+   */
+  for (let step = 0; step < ACTIVEDESCENDANT_STEPS; step++) {
+    await voiceOver.clearSpokenPhraseLog();
+
+    await page.keyboard.press('ArrowDown');
+
+    const pointed = await readActiveDescendant(page);
+
+    expect(pointed.id).not.toBeNull();
+    expect(pointed.resolves).toBe(true);
+    expect(pointed.name).not.toBeNull();
+
+    const name = (pointed.name as string).toLowerCase();
+
+    /**
+     * The finding itself: what VoiceOver speaks is the item the reference names. Compared against
+     * the name read off the element rather than a hardcoded 'bold'/'italic', since which tool a
+     * given press count lands on is ui-kit's business and pinning it here would make this case
+     * fail for a reason unrelated to its subject.
+     *
+     * VoiceOver only samples speech while executing a command, so an announcement nothing asked
+     * for can never appear in the log on its own - VO-Z re-speaks the last phrase *through* a
+     * command, which is how Case 7 captures the live-region announcement. Polled rather than
+     * asked once, because the announcement is asynchronous and nothing signals its arrival: this
+     * waits for VoiceOver to say the name, and fails only if it never does
+     */
+    await expect
+      .poll(async () => {
+        await voiceOver.perform(voiceOver.keyboardCommands.repeatLastSpokenPhrase);
+
+        return (await voiceOver.lastSpokenPhrase()).toLowerCase();
+      }, {
+        timeout: ANNOUNCEMENT_TIMEOUT,
+        intervals: [ANNOUNCEMENT_INTERVAL],
+        message: `VoiceOver never announced "${name}", the item aria-activedescendant points at.`
+          + ` Its cursor was on: "${cursorAt.trim()}" - if that is not the editor's text, the`
+          + ` cursor drifted and the reference was never being watched, not unreported.`,
+      })
+      .toContain(name);
+
+    /** Already sampled by the poll's last command, so reading it back costs nothing */
+    const spoken = (await voiceOver.lastSpokenPhrase()).toLowerCase();
+
+    expect(spoken).toContain('button');
+
+    heard.push({
+      name,
+      spoken,
+    });
+  }
+
+  /**
+   * Guards the vacuous reading, and matters more now that the announcement is polled for. VO-Z
+   * repeats the *last* phrase, so one step matching could in principle be VoiceOver echoing
+   * something it happened to have said already rather than reacting to the arrow key. Two steps
+   * landing on different tools, each spoken in turn and neither still mentioning the other, is
+   * what shows the reference is being tracked rather than a stale phrase replayed
+   */
+  expect(heard[0].name).not.toBe(heard[1].name);
+  expect(heard[1].spoken).not.toContain(heard[0].name);
+
+  /**
+   * Keeping the selection intact is the entire reason the toolbar refuses DOM focus and needs
+   * `aria-activedescendant` at all, so if arrow navigation drops it the design's premise is
+   * broken however well the announcement reads
+   */
+  const selectionAfter = await page.evaluate(() => window.getSelection()?.toString() ?? '');
+
+  expect(selectionAfter).toBe(selectionBefore);
+  expect(selectionAfter).not.toBe('');
+});
+
+test('Case 9: activating the Link tool opens its URL input without closing the toolbar', async ({ page, voiceOver }) => {
+  await mountEditor(page, voiceOver);
+  await selectParagraphText(page);
+
+  const inlineToolbar = page.getByRole('toolbar', { name: 'Text formatting' });
+
+  await expect(inlineToolbar).toBeVisible();
+
+  await tabToInlineTool(page, page.getByRole('button', { name: 'Link' }));
+
+  await page.keyboard.press('Enter');
+
+  await expect(inlineToolbar).toBeVisible();
+
+  const linkInput = page.getByRole('textbox', { name: 'Add a link' });
+
+  await expect(linkInput).toBeFocused();
+  await syncCursorToFocus(voiceOver);
+
+  expect(await describeCurrentItem(voiceOver)).toContain('add a link');
+});
+
+test('Case 10: does not announce invisible placeholder content after applying a tool', async ({ page, voiceOver }) => {
+  await mountEditor(page, voiceOver);
+  await selectParagraphText(page);
+  await page.keyboard.press('Tab');
+  await page.keyboard.press('Enter');
+
+  // Confirms Bold actually got applied before scanning - otherwise a silently-failed
+  // Tab+Enter would make the "no stray content" check below pass for the wrong reason.
+  await expect(page.getByRole('button', { name: 'Bold' })).toHaveAttribute('aria-pressed', 'true');
+
+  await voiceOver.clearSpokenPhraseLog();
+
+  await voiceOver.next();
+  await voiceOver.next();
+  await voiceOver.next();
+
+  const log = await voiceOver.spokenPhraseLog();
+
+  // Guards against a vacuous pass: `next()` must have actually produced some
+  // announcements for "doesn't contain zero width space" to mean anything.
+  expect(log.join('').trim().length).toBeGreaterThan(0);
+  expect(log.join(' ').toLowerCase()).not.toContain('zero width space');
+});
+
+test('Case 11: leaves the user in the document, not on a control, once the toolbar is dismissed', async ({ page, voiceOver }) => {
+  await mountEditor(page, voiceOver);
+  await selectParagraphText(page);
+
+  const inlineToolbar = page.getByRole('toolbar', { name: 'Text formatting' });
+
+  await expect(inlineToolbar).toBeVisible();
+
+  await page.keyboard.press('Tab');
+  await expect(page.getByRole('button', { name: 'Bold' })).toBeFocused();
+
+  // Collapses the selection, which dismisses the toolbar.
+  await page.getByRole('textbox', { name: 'Paragraph' }).click();
+  await expect(inlineToolbar).toBeHidden();
+
+  await resetCursor(voiceOver);
+
+  // `sweep`, not `walk`: the reset leaves the cursor *on* the block, which `walk` would step
+  // past without ever recording - and where the cursor lands is the whole subject here.
+  const reachable = await sweep(voiceOver, SCAN_STEPS);
+
+  // Guards against a vacuous pass: the sweep has to have actually covered the editor.
+  expect(reachable.some(item => item.includes('hello world'))).toBe(true);
+
+  // What this case can assert is that the user is put back in their document: dismissing the
+  // toolbar leaves the cursor on the block's own content, not stranded on a control that no
+  // longer does anything.
+  expect(reachable[0]).toContain('hello world');
+  expect(reachable[0]).not.toMatch(INLINE_TOOL_NAME);
+
+  // What it deliberately does *not* assert - established by this case failing, not assumed - is
+  // that the tools become unreachable. They do not: a sweep of the editor after dismissal still
+  // reaches an item whose entire text is "bold".
+  //
+  // That is VoiceOver retaining nodes the document has already dropped, not a leak in the editor.
+  // `InlineToolbarUI#hide` destroys the popover, which detaches it, and the DOM is provably clean
+  // afterwards on both engines - `aria.spec.ts` ("takes its tools out of the accessibility tree
+  // when dismissed") asserts exactly that, headlessly, and passes. `resetCursor` does not clear
+  // the retained nodes either, so there is no navigation that makes the absence observable from
+  // here; the editor has done everything it can and the residue is VoiceOver's.
+  //
+  // Not asserted in the inverted form Cases 3 and 15 use to pin their findings, because this one
+  // is a cache artifact rather than a deterministic announcement: whether a given sweep length
+  // reaches a retained node is not stable enough to fail a build over. Case 17 is where it
+  // actually bites, and it handles it by bounding the scan with interact() instead.
+});
+
+test('Case 12: announces each block as a separate text field while walking the document', async ({ page, voiceOver }) => {
+  await mountEditor(page, voiceOver, '?text=Alpha&text=Beta&text=Gamma');
+
+  // The whole point of moving role="textbox" onto each block (and off the holder, see Case 1)
+  // is that a user can move between blocks. With one block that's untestable - "no second text
+  // field" is vacuously true - so this is the case that actually exercises it.
+  const firstBlock = await describeCurrentItem(voiceOver);
+
+  expect(firstBlock).toContain('alpha');
+  expect(firstBlock).toMatch(TEXTBOX_ROLE);
+
+  const itemsAhead = await walk(voiceOver, MULTI_BLOCK_WALK_STEPS);
+
+  const beta = itemsAhead.findIndex(item => item.includes('beta'));
+  const gamma = itemsAhead.findIndex(item => item.includes('gamma'));
+
+  expect(beta).toBeGreaterThanOrEqual(0);
+  expect(gamma).toBeGreaterThan(beta);
+
+  // Each one announced as an editable field in its own right, not as inert text inside
+  // some larger region.
+  expect(itemsAhead[beta]).toMatch(TEXTBOX_ROLE);
+  expect(itemsAhead[gamma]).toMatch(TEXTBOX_ROLE);
+});
+
+test('Case 13: announces what belongs in an empty block', async ({ page, voiceOver }) => {
+  await mountEditor(page, voiceOver, '?text=');
+
+  // A contenteditable has no native placeholder, so without aria-placeholder an empty block
+  // is announced as an unlabelled empty field and there is nothing telling the user what to
+  // type or that the editor is even ready for input.
+  await findItem(voiceOver, new RegExp(PLACEHOLDER, 'i'));
+
+  const description = await describeCurrentItem(voiceOver);
+
+  expect(description).toContain('paragraph');
+  expect(description).toMatch(TEXTBOX_ROLE);
+});
+
+test('Case 14: exposes a block created with Enter as a text field of its own', async ({ page, voiceOver }) => {
+  await mountEditor(page, voiceOver);
+
+  const paragraph = page.getByRole('textbox', { name: 'Paragraph' });
+
+  await paragraph.click();
+  await page.keyboard.press('End');
+  await page.keyboard.press('Enter');
+
+  await expect(page.getByRole('textbox', { name: 'Paragraph' })).toHaveCount(2);
+
+  // Known gap, deliberately not asserted: nothing announces the new block at the moment it is
+  // created - there is no live region for it, and VoiceOver's cursor doesn't follow the caret -
+  // so a user only learns about it by exploring. What must hold is that exploring finds it.
+  const itemsAhead = await walk(voiceOver, FORWARD_WALK_STEPS);
+
+  // The new block is empty, so what identifies it as *the block that was just created* is the
+  // placeholder the paragraph tool exposes - not merely "a text field that isn't the first
+  // one", which the link tool's URL input or any other editable on the page would satisfy too.
+  const newBlock = itemsAhead.find(item => item.includes(PLACEHOLDER.toLowerCase()));
+
+  expect(newBlock).toBeDefined();
+  expect(newBlock).toMatch(TEXTBOX_ROLE);
+});
+
+test('Case 15: takes the user into the toolbox menu when the plus button is activated', async ({ page, voiceOver }) => {
+  await mountEditor(page, voiceOver);
+
+  await findItem(voiceOver, /add block/i);
+
+  const collapsed = (await voiceOver.itemText()).toLowerCase();
+
+  await voiceOver.act();
+
+  await expect(page.getByRole('menu', { name: 'Add block' })).toBeVisible();
+
+  // VoiceOver reads this button as "Add block menu pop-up button" whether the menu is open or
+  // closed - the `aria-expanded` state never reaches speech. That's `aria-haspopup` suppressing
+  // it, established by experiment rather than assumed: on a scratch page varying one attribute at
+  // a time, VoiceOver announced the state fine on a plain button and dropped it as soon as
+  // `aria-haspopup` was present, with `aria-controls` making no difference. A VoiceOver
+  // limitation, not a gap in our markup - so the round trip isn't assertable from here and
+  // aria.spec.ts covers it at the DOM level instead. Full results in voiceover-verification.md.
+  //
+  // What VoiceOver does instead is take the user to the menu: activating the button moves DOM
+  // focus into the popover's search field, and a focus change caused by VoiceOver's own command
+  // is one it follows. Arriving there is how a VoiceOver user learns the menu opened, so that
+  // is what this case asserts.
+  const afterActivating = await describeCurrentItem(voiceOver);
+
+  expect(afterActivating).toContain('search');
+  expect(afterActivating).toMatch(TEXTBOX_ROLE);
+
+  // The button is behind the cursor now, and has to stay reachable and named while the menu is
+  // open - a control that goes silent or unnamed once its popup is showing leaves the user no
+  // way back to it. Walked rather than read at one stop: how many stops back it is, and whether
+  // the popover announces a container of its own on the way, isn't worth hardcoding.
+  const itemsBehind = await walk(voiceOver, BACKWARD_WALK_STEPS, 'previous');
+  const plusButtonHeard = itemsBehind.filter(item => item.includes('add block'));
+
+  expect(plusButtonHeard.length).toBeGreaterThan(0);
+  expect(plusButtonHeard[0]).toContain('button');
+
+  // Pins the finding rather than assuming it holds forever: if a future VoiceOver or ui-kit
+  // version does start exposing the state, the open announcement stops matching the closed one
+  // and this fails - prompting the case to be tightened into a real round-trip assertion.
+  //
+  // Compared on the item description alone, not the fuller `describeCurrentItem` string: half of
+  // that is the last *spoken* phrase, which can still be describing the previous stop, so an
+  // exact match on it would fail on timing rather than on the state having changed.
+  expect(plusButtonHeard[0]).toBe(collapsed);
+});
+
+test('Case 16: returns the user to the plus button when the toolbox is dismissed', async ({ page, voiceOver }) => {
+  await mountEditor(page, voiceOver);
+
+  await findItem(voiceOver, /add block/i);
+  await voiceOver.act();
+
+  const menu = page.getByRole('menu', { name: 'Add block' });
+
+  await expect(menu).toBeVisible();
+
+  await page.keyboard.press('Escape');
+
+  await expect(menu).toBeHidden();
+
+  // Safari doesn't focus a button when it's clicked, so the popover used to capture <body> as
+  // the element to restore focus to and dismissing the menu dropped the user out of the editor
+  // entirely. ToolbarUI focuses the button explicitly now; this is the announcement half of the
+  // aria.spec.ts test that asserts the focus move itself.
+  const plusButton = page.getByRole('button', { name: 'Add block' });
+
+  await expect(plusButton).toBeFocused();
+  await syncCursorToFocus(voiceOver);
+
+  const description = await describeCurrentItem(voiceOver);
+
+  expect(description).toContain('add block');
+  expect(description).toContain('button');
+});
+
+test('Case 17: announces applied links as links', async ({ page, voiceOver }) => {
+  await mountEditor(page, voiceOver);
+  await selectParagraphText(page);
+
+  const inlineToolbar = page.getByRole('toolbar', { name: 'Text formatting' });
+
+  await expect(inlineToolbar).toBeVisible();
+
+  await tabToInlineTool(page, page.getByRole('button', { name: 'Link' }));
+
+  await page.keyboard.press('Enter');
+  await page.keyboard.type('https://example.com');
+  await page.keyboard.press('Enter');
+
+  await expect(page.getByRole('textbox', { name: 'Paragraph' }).getByRole('link')).toHaveCount(1);
+
+  // Collapsing the selection dismisses the toolbar, which is what a user does next anyway. It is
+  // not what makes the reading below safe, though - see the second finding under the scan.
+  await page.getByRole('textbox', { name: 'Paragraph' }).click();
+  await expect(inlineToolbar).toBeHidden();
+
+  // Navigate to the block deliberately, then read *inside* it.
+  //
+  // Two findings shape this, both established by experiment rather than guessed at (results in
+  // voiceover-verification.md under this case). First, VoiceOver does not announce a link nested
+  // in editable content at the browse cursor - it reads the field's value flat. That is
+  // `contenteditable`, not the `role="textbox"` this change added: a plain contenteditable
+  // behaves identically, and a non-editable container announces the link fine. So reading the
+  // block from outside can never satisfy this case. Interacting with the field (VO-Shift-Down)
+  // is the other way VoiceOver reads editable text, and is the path a user takes to move through
+  // it - so that is the path asserted here.
+  //
+  // Second, the scan has to stay *inside* the block. An earlier version walked across it and
+  // passed twice in three runs for the wrong reason: the inline toolbar's controls stay reachable
+  // to VoiceOver after dismissal - it retains nodes the document has already dropped, and no
+  // amount of re-navigating clears them (Case 11 records the evidence) - and their item text is
+  // the bare tool name, so Link announces as "link". A walk long enough to leave the block
+  // matched the control that *applies* the formatting rather than the formatted text, and would
+  // pass with the text completely unchanged. Interacting bounds the scan to the block, which is
+  // the only reliable fix: the toolbar being gone from the DOM is not enough.
+  await resetCursor(voiceOver);
+  await voiceOver.clearSpokenPhraseLog();
+  await findItem(voiceOver, /hello world/i);
+
+  await voiceOver.interact();
+
+  // Applying a tool has to change what the text sounds like, not just what it looks like -
+  // otherwise a screen-reader user has no way to tell the link is there.
+  const insideBlock = [
+    await describeCurrentItem(voiceOver),
+    ...await describeWalk(voiceOver, INSIDE_BLOCK_STEPS),
+  ];
+
+  await voiceOver.stopInteracting();
+
+  // Guards against a vacuous pass: interacting must have produced announcements for their
+  // content to mean anything.
+  expect(insideBlock.join('').trim().length).toBeGreaterThan(0);
+  expect(insideBlock.join(' | ')).toContain('link');
+});
+
+/**
+ * Every distinct item matching `pattern` that VoiceOver's cursor reaches within `SCAN_STEPS`
+ * forward steps.
+ *
+ * Returns the matches rather than a boolean so that asserting "nothing is reachable" fails with
+ * the offending announcements in the message. A bare `toBe(false)` says only that something
+ * matched, which leaves you guessing at whether the fault is the page or the pattern.
+ * @param voiceOver - Guidepup VoiceOver controller
+ * @param pattern - matched against the current item's text at each stop
+ */
+async function collectReachable(voiceOver: VoiceOverPlaywright, pattern: RegExp): Promise<string[]> {
+  const reachable = await sweep(voiceOver, SCAN_STEPS);
+
+  return [...new Set(reachable.filter(item => pattern.test(item)))];
+}
+
+test('Case 18: does not let the cursor reach toolbox items filtered out by search', async ({ page, voiceOver }) => {
+  await mountEditor(page, voiceOver);
+
+  await findItem(voiceOver, /add block/i);
+  await voiceOver.act();
+
+  const menu = page.getByRole('menu', { name: 'Add block' });
+
+  await expect(menu).toBeVisible();
+
+  const menuItemPattern = /menu item/;
+
+  // Baseline. It also guards the real assertion below: if VoiceOver words menu items
+  // differently than this expects, the test fails here instead of making "nothing reachable"
+  // pass for the wrong reason.
+  await resetCursor(voiceOver);
+
+  const beforeFiltering = await collectReachable(voiceOver, menuItemPattern);
+
+  expect(beforeFiltering.length).toBeGreaterThan(0);
+
+  // Opening the toolbox puts DOM focus in its search field; filling it filters the list.
+  await page.getByRole('searchbox', { name: 'Search' }).fill('no such tool');
+
+  await expect(menu.getByRole('menuitem')).toHaveCount(0);
+
+  // Back to the top rather than continuing from wherever the scan stopped - that item may be
+  // one of the ones just hidden, and VoiceOver would keep describing it from where it stands.
+  // The round trip inside resetCursor is what makes this reliable: `fill()` is a page-driven
+  // change, so without it VoiceOver can still be describing the unfiltered list.
+  await resetCursor(voiceOver);
+
+  // ui-kit hides filtered items with a CSS class and sets the `hidden` attribute alongside it;
+  // the attribute is what takes them out of the accessibility tree, so nothing matching should
+  // remain reachable. If something does, the message below carries its announcement - the
+  // answer to "is this the hidden item, or is the pattern matching something else entirely"
+  // is not worth guessing at.
+  expect(await collectReachable(voiceOver, menuItemPattern)).toEqual([]);
+});
diff --git a/packages/editorjs/e2e/vite.config.ts b/packages/editorjs/e2e/vite.config.ts
new file mode 100644
index 00000000..fd5c176b
--- /dev/null
+++ b/packages/editorjs/e2e/vite.config.ts
@@ -0,0 +1,9 @@
+import { defineConfig } from 'vite';
+
+export default defineConfig({
+  root: __dirname + '/fixtures',
+  server: {
+    port: 4173,
+    strictPort: true,
+  },
+});
diff --git a/packages/editorjs/eslint.config.mjs b/packages/editorjs/eslint.config.mjs
index e822a5e9..7453a519 100644
--- a/packages/editorjs/eslint.config.mjs
+++ b/packages/editorjs/eslint.config.mjs
@@ -36,4 +36,15 @@ export default [
       }],
     },
   },
+  {
+    files: ['e2e/**/*.ts', 'playwright.config.ts', 'playwright.voiceover.config.ts'],
+    rules: {
+      /**
+       * e2e tooling only ships in devDependencies, never published
+       */
+      'n/no-unpublished-import': ['error', {
+        allowModules: ['@playwright/test', 'vite', '@axe-core/playwright', '@guidepup/playwright'],
+      }],
+    },
+  },
 ];
diff --git a/packages/editorjs/package.json b/packages/editorjs/package.json
index 81e7aaea..a7d5d48b 100644
--- a/packages/editorjs/package.json
+++ b/packages/editorjs/package.json
@@ -9,17 +9,24 @@
     "build": "yarn build:dependencies && yarn clear && tsc --build tsconfig.build.json",
     "build:dependencies": "yarn workspaces foreach -Rpt --from $npm_package_name --exclude $npm_package_name run build",
     "build:declaration": "yarn build --emitDeclarationOnly",
-    "lint": "eslint ./src",
+    "lint": "eslint ./src ./e2e playwright.config.ts playwright.voiceover.config.ts",
     "lint:ci": "yarn lint --max-warnings 0",
     "lint:fix": "yarn lint --fix",
     "test": "node --experimental-vm-modules $(yarn bin jest)",
     "test:coverage": "yarn test --coverage=true",
+    "test:e2e": "playwright test",
+    "test:e2e:ui": "playwright test --ui",
+    "test:e2e:voiceover": "playwright test --config playwright.voiceover.config.ts",
     "clear": "rm -rf dist && rm -f tsconfig.build.tsbuildinfo && rm -f tsconfig.tsbuildinfo"
   },
   "devDependencies": {
+    "@axe-core/playwright": "^4.12.1",
     "@babel/core": "^7.29.0",
     "@babel/preset-env": "^7.29.2",
+    "@guidepup/guidepup": "^0.29.2",
+    "@guidepup/playwright": "^0.18.0",
     "@jest/globals": "^29.7.0",
+    "@playwright/test": "^1.62.0",
     "@types/eslint": "^9.6.1",
     "@types/jest": "^29.5.12",
     "@types/node": "^22.10.2",
@@ -28,9 +35,11 @@
     "eslint-config-codex": "^2.0.3",
     "eslint-plugin-import": "^2.31.0",
     "jest": "^29.7.0",
+    "playwright-core": "^1.62.0",
     "ts-jest": "^29.2.5",
     "ts-node": "^10.9.2",
-    "typescript": "^5.5.4"
+    "typescript": "^5.5.4",
+    "vite": "^5.4.11"
   },
   "dependencies": {
     "@editorjs/bold": "workspace:^",
diff --git a/packages/editorjs/playwright.config.ts b/packages/editorjs/playwright.config.ts
new file mode 100644
index 00000000..246700bd
--- /dev/null
+++ b/packages/editorjs/playwright.config.ts
@@ -0,0 +1,42 @@
+import process from 'node:process';
+import { defineConfig, devices } from '@playwright/test';
+
+const PORT = 4173;
+const isCI = process.env.CI !== undefined;
+
+export default defineConfig({
+  testDir: './e2e/tests',
+  // Guidepup's VoiceOver suite needs a real, headed VoiceOver instance and can't run in
+  // parallel - it has its own config (playwright.voiceover.config.ts / test:e2e:voiceover).
+  testIgnore: /voiceover\.spec\.ts/,
+  fullyParallel: true,
+  forbidOnly: isCI,
+  retries: isCI ? 2 : 0,
+  // On CI the html report is written too, for the e2e action to upload: it is what keeps the
+  // traces recorded on a retry (see `trace` below) once the runner is gone.
+  reporter: isCI ? [['list'], ['html', { open: 'never' }]] : 'list',
+  use: {
+    baseURL: `http://localhost:${PORT}`,
+    trace: 'on-first-retry',
+  },
+  projects: [
+    {
+      name: 'chromium',
+      use: { ...devices['Desktop Chrome'] },
+    },
+    {
+      name: 'webkit',
+      use: { ...devices['Desktop Safari'] },
+    },
+  ],
+  webServer: {
+    // The fixture imports this package's `src`, but that resolves `@editorjs/ui` and the tools
+    // through their published `exports` — i.e. their `dist`. Without building first, the suite
+    // silently audits whatever was built last, so a change to the ARIA attributes in
+    // `packages/ui` can pass against the previous build of it.
+    command: `yarn build:dependencies && yarn vite --config e2e/vite.config.ts --port ${PORT} --strictPort`,
+    url: `http://localhost:${PORT}`,
+    reuseExistingServer: !isCI,
+    stdout: 'pipe',
+  },
+});
diff --git a/packages/editorjs/playwright.voiceover.config.ts b/packages/editorjs/playwright.voiceover.config.ts
new file mode 100644
index 00000000..e3fbebf4
--- /dev/null
+++ b/packages/editorjs/playwright.voiceover.config.ts
@@ -0,0 +1,48 @@
+import process from 'node:process';
+import { defineConfig, devices } from '@playwright/test';
+import { screenReaderConfig } from '@guidepup/playwright';
+
+const PORT = 4174;
+const isCI = process.env.CI !== undefined;
+
+/**
+ * Per-test budget. Every VoiceOver command is a real keystroke against a real screen reader, so
+ * a case that walks the document runs into minutes rather than the seconds the headless suite takes.
+ * Five minutes.
+ */
+const TEST_TIMEOUT_MS = 300_000;
+
+/**
+ * Separate config from playwright.config.ts: screen readers are singletons (one VoiceOver
+ * instance, can't parallelize) and can't drive a headless browser, so this suite needs
+ * `workers: 1` and `headless: false` - settings that would slow the rest of the e2e suite down
+ * for no reason. Run with `yarn test:e2e:voiceover`. macOS only.
+ */
+export default defineConfig({
+  ...screenReaderConfig,
+  testDir: './e2e/tests',
+  testMatch: /voiceover\.spec\.ts/,
+  reporter: 'list',
+  timeout: TEST_TIMEOUT_MS,
+  use: {
+    ...screenReaderConfig.use,
+    baseURL: `http://localhost:${PORT}`,
+    trace: 'on-first-retry',
+  },
+  projects: [
+    {
+      // VoiceOver's best-supported browser on macOS - same reasoning as the webkit target
+      // in playwright.config.ts and voiceover-verification.md.
+      name: 'webkit',
+      use: { ...devices['Desktop Safari'] },
+    },
+  ],
+  webServer: {
+    // Builds first for the same reason as playwright.config.ts: the fixture reaches the UI
+    // packages through their `dist`, so an unbuilt change is invisible to the suite.
+    command: `yarn build:dependencies && yarn vite --config e2e/vite.config.ts --port ${PORT} --strictPort`,
+    url: `http://localhost:${PORT}`,
+    reuseExistingServer: !isCI,
+    stdout: 'pipe',
+  },
+});
diff --git a/packages/editorjs/tsconfig.eslint.json b/packages/editorjs/tsconfig.eslint.json
index 509a876f..33b8ee82 100644
--- a/packages/editorjs/tsconfig.eslint.json
+++ b/packages/editorjs/tsconfig.eslint.json
@@ -7,7 +7,10 @@
     "src/**/*",
     "eslint.config.mjs",
     "**/*.spec.ts",
-    "jest.config.ts"
+    "jest.config.ts",
+    "playwright.config.ts",
+    "playwright.voiceover.config.ts",
+    "e2e/**/*"
   ],
   "exclude": [
     "dist/**/*",
diff --git a/packages/sdk/package.json b/packages/sdk/package.json
index 6ce94bda..de94fe26 100644
--- a/packages/sdk/package.json
+++ b/packages/sdk/package.json
@@ -33,7 +33,7 @@
   "dependencies": {
     "@editorjs/helpers": "^1.2.2",
     "@editorjs/model-types": "workspace:^",
-    "@editorjs/ui-kit": "^1.1.5",
+    "@editorjs/ui-kit": "^2.0.0",
     "editorjs-v2": "npm:@editorjs/editorjs@^2.30.8"
   }
 }
diff --git a/packages/tools/bold/package.json b/packages/tools/bold/package.json
index df2becf6..e5e18637 100644
--- a/packages/tools/bold/package.json
+++ b/packages/tools/bold/package.json
@@ -23,7 +23,7 @@
   },
   "dependencies": {
     "@codexteam/icons": "^0.3.3",
-    "@editorjs/dom": "^1.1.0",
+    "@editorjs/dom": "^1.2.0",
     "@editorjs/sdk": "workspace:^"
   }
 }
diff --git a/packages/tools/inline-link/package.json b/packages/tools/inline-link/package.json
index c5d836af..3238cabd 100644
--- a/packages/tools/inline-link/package.json
+++ b/packages/tools/inline-link/package.json
@@ -23,7 +23,7 @@
   },
   "dependencies": {
     "@codexteam/icons": "^0.3.3",
-    "@editorjs/dom": "^1.1.0",
+    "@editorjs/dom": "^1.2.0",
     "@editorjs/sdk": "workspace:^"
   }
 }
diff --git a/packages/tools/italic/package.json b/packages/tools/italic/package.json
index d6f8daa2..04b62e19 100644
--- a/packages/tools/italic/package.json
+++ b/packages/tools/italic/package.json
@@ -23,7 +23,7 @@
   },
   "dependencies": {
     "@codexteam/icons": "^0.3.3",
-    "@editorjs/dom": "^1.1.0",
+    "@editorjs/dom": "^1.2.0",
     "@editorjs/sdk": "workspace:^"
   }
 }
diff --git a/packages/tools/paragraph/src/index.ts b/packages/tools/paragraph/src/index.ts
index 5fcf7732..0beb0047 100644
--- a/packages/tools/paragraph/src/index.ts
+++ b/packages/tools/paragraph/src/index.ts
@@ -12,6 +12,16 @@ import { ToolType } from '@editorjs/sdk';
 import { IconText } from '@codexteam/icons';
 import type { DOMBlockToolAdapter } from '@editorjs/dom-adapters';
 
+/**
+ * Accessible name of a paragraph block's editable element.
+ *
+ * Identifies the block *type*, so it reads identically on every paragraph in a document — see
+ * the Open Questions in `openspec/changes/add-editor-aria-semantics/design.md` for whether that
+ * should become per-instance. Named here rather than inline as the seam localisation would
+ * attach to, mirroring `packages/ui/src/messages.ts`; i18n itself is out of scope for now
+ */
+const ARIA_LABEL = 'Paragraph';
+
 /**
  * Data structure describing the tool's input/output data
  */
@@ -83,11 +93,17 @@ export class Paragraph implements BlockTool<ParagraphData, ParagraphConfig> {
     return this.#wrapper;
   }
 
+  /**
+   * Hint describing what to type into an empty paragraph
+   */
+  #placeholder: string | undefined;
+
   /**
    * @param options - Block tool constructor options
    */
-  constructor({ adapter }: BlockToolConstructorOptions<ParagraphData, ParagraphConfig, DOMBlockToolAdapter>) {
+  constructor({ adapter, config }: BlockToolConstructorOptions<ParagraphData, ParagraphConfig, DOMBlockToolAdapter>) {
     this.#adapter = adapter;
+    this.#placeholder = config?.placeholder;
 
     adapter.addEventListener('adapter:updated', this.#onUpdate);
 
@@ -124,6 +140,24 @@ export class Paragraph implements BlockTool<ParagraphData, ParagraphConfig> {
     const paragraph = document.createElement('div');
 
     paragraph.contentEditable = 'true';
+
+    /**
+     * Make the implicit contenteditable textbox role explicit and give the block
+     * an accessible name, so assistive tech announces it as an editable text field
+     */
+    paragraph.setAttribute('role', 'textbox');
+    paragraph.setAttribute('aria-multiline', 'true');
+    paragraph.setAttribute('aria-label', ARIA_LABEL);
+
+    /**
+     * A contenteditable has no native placeholder, so an empty block would otherwise be
+     * announced as just an unlabelled empty field. aria-placeholder is the ARIA equivalent
+     * of the `placeholder` attribute and is announced when the field has no value
+     */
+    if (this.#placeholder !== undefined && this.#placeholder !== '') {
+      paragraph.setAttribute('aria-placeholder', this.#placeholder);
+    }
+
     paragraph.style.outline = 'none';
     paragraph.style.whiteSpace = 'pre-wrap';
 
diff --git a/packages/ui/package.json b/packages/ui/package.json
index 46557ed1..02dce4a2 100644
--- a/packages/ui/package.json
+++ b/packages/ui/package.json
@@ -47,9 +47,9 @@
   "dependencies": {
     "@codexteam/icons": "^0.3.3",
     "@codexteam/ui": "^0.2.2",
-    "@editorjs/dom": "^1.1.0",
+    "@editorjs/dom": "^1.2.0",
     "@editorjs/helpers": "^1.2.2",
     "@editorjs/sdk": "workspace:^",
-    "@editorjs/ui-kit": "^1.1.5"
+    "@editorjs/ui-kit": "^2.0.0"
   }
 }
diff --git a/packages/ui/src/Blocks/Blocks.ts b/packages/ui/src/Blocks/Blocks.ts
index 110f78de..14fbfcc4 100644
--- a/packages/ui/src/Blocks/Blocks.ts
+++ b/packages/ui/src/Blocks/Blocks.ts
@@ -81,6 +81,14 @@ export class BlocksUI implements EditorjsPlugin {
       contentEditable: true,
     });
 
+    /**
+     * The holder is a structural container, not an editable region of its own.
+     * Being contenteditable, it would otherwise be implicitly mapped to role="textbox"
+     * — nesting a textbox inside the textbox each block already exposes.
+     * Each block owns its own role="textbox" and accessible name instead.
+     */
+    blocksHolder.setAttribute('role', 'group');
+
     /**
      * Workaround Safari behavior when it deletes blocks if there is no content in them
      * E.g. when you delete all content in the only block, it deletes the block
@@ -169,6 +177,12 @@ export class BlocksUI implements EditorjsPlugin {
     const zeroWidthSpace = document.createTextNode('\u200B');
 
     zeroWidthSpaceWrapper.classList.add(Style['host-holder']);
+
+    /**
+     * Purely a DOM workaround with no content of its own - without this, assistive tech can
+     * land on it and read out its zero-width-space text node as if it were real content
+     */
+    zeroWidthSpaceWrapper.setAttribute('aria-hidden', 'true');
     zeroWidthSpaceWrapper.appendChild(zeroWidthSpace);
 
     blocksHolder.appendChild(zeroWidthSpaceWrapper);
diff --git a/packages/ui/src/InlineToolbar/InlineToolbar.module.pcss b/packages/ui/src/InlineToolbar/InlineToolbar.module.pcss
index ff5282f3..72598cf1 100644
--- a/packages/ui/src/InlineToolbar/InlineToolbar.module.pcss
+++ b/packages/ui/src/InlineToolbar/InlineToolbar.module.pcss
@@ -1,3 +1,15 @@
+.visually-hidden {
+  position: absolute;
+  width: 1px;
+  height: 1px;
+  margin: -1px;
+  padding: 0;
+  border: 0;
+  overflow: hidden;
+  white-space: nowrap;
+  clip-path: inset(50%);
+}
+
 .inline-toolbar {
   position: absolute;
   top: 0;
diff --git a/packages/ui/src/InlineToolbar/InlineToolbar.ts b/packages/ui/src/InlineToolbar/InlineToolbar.ts
index 9de36ef4..6971a07f 100644
--- a/packages/ui/src/InlineToolbar/InlineToolbar.ts
+++ b/packages/ui/src/InlineToolbar/InlineToolbar.ts
@@ -17,8 +17,37 @@ import {
 import type { InlineFragment, TextIndex, TextRange } from '@editorjs/sdk';
 import Style from './InlineToolbar.module.pcss';
 import type { PopoverItemDefaultBaseParams, PopoverItemParams } from '@editorjs/ui-kit';
-import { PopoverInline, PopoverItemType } from '@editorjs/ui-kit';
+import { PopoverEvent, PopoverInline, PopoverItemType } from '@editorjs/ui-kit';
 import { beautifyShortcut, capitalize } from '@editorjs/helpers';
+import { messages } from '../messages.js';
+
+/**
+ * Delay before filling the live region in, so that its content is treated as a change
+ * and hence announced even when the same message repeats
+ */
+const ANNOUNCEMENT_DELAY = 50;
+
+/**
+ * Number of inline toolbars constructed so far, used to keep their popover ids apart
+ */
+let inlineToolbarCount = 0;
+
+/**
+ * Builds the id put on the popover element so that the editable holding focus can claim it via
+ * aria-owns (see #setActiveDescendant).
+ *
+ * Per instance rather than a single constant: several editors can share a page, `aria-owns`
+ * resolves by document-wide id lookup, and a duplicate id would hand the second editor's blocks
+ * holder the *first* editor's popover — pointing assistive tech at controls that operate on a
+ * different document. Stable for the lifetime of the toolbar, since the popover element it names
+ * is rebuilt on every selection change while the reference to it has to keep resolving
+ * @returns an id unique to one inline toolbar instance
+ */
+function nextPopoverElementId(): string {
+  inlineToolbarCount += 1;
+
+  return `ejs-inline-toolbar-popover-${inlineToolbarCount}`;
+}
 
 /**
  * Inline Toolbar UI module
@@ -57,6 +86,57 @@ export class InlineToolbarUI implements EditorjsPlugin {
    */
   #popover: PopoverInline | null = null;
 
+  /**
+   * Id this toolbar's popover element carries, so that aria-owns can name it across rebuilds
+   */
+  #popoverElementId = nextPopoverElementId();
+
+  /**
+   * Handle of the not-yet-written live region announcement, so that dismissing the toolbar
+   * within the delay can cancel it instead of announcing a toolbar that is already gone
+   */
+  #announcementTimeout: ReturnType<typeof setTimeout> | null = null;
+
+  /**
+   * Element currently pointed at the highlighted popover item via aria-activedescendant.
+   * Kept so that the attribute can be removed from the very element it was set on, even if
+   * the focus has moved on since then
+   */
+  #activeDescendantHost: HTMLElement | null = null;
+
+  /**
+   * Whether the toolbar is currently shown. The popover itself is destroyed and recreated on
+   * every selection change (see #renderPopover), so its own visibility state can't be used to
+   * tell a genuine hidden-to-shown transition apart from a reselection while already open
+   */
+  #isVisible = false;
+
+  /**
+   * Number of popover renders started so far, used to tell a render that is still the current
+   * one from a render that has been superseded while it was awaiting, see #renderPopover
+   */
+  #renderGeneration = 0;
+
+  /**
+   * Subscription to the core's selection changes.
+   *
+   * Held as a field rather than passed inline, so that `destroy()` has something to unsubscribe:
+   * an inline arrow cannot be handed back to `removeEventListener`, which would leave the
+   * toolbar reacting to selection changes for as long as the event bus outlives it
+   * @todo Handle a rejected build instead of discarding it. `#renderPopover` awaits a
+   * `getToolbarConfig` per tool, so a throwing tool rejects the whole chain — and `void` drops
+   * it, leaving the user without formatting controls and nothing logged. The render generation
+   * added for the interleaving case makes this more visible rather than less: an older build
+   * that would once have completed and put *something* up now bails on the generation check,
+   * so a failing newest build is the whole outcome. Deciding between hiding the toolbar,
+   * retrying, and rendering the tools that did resolve is a call about tool-failure semantics
+   * across the editor, not one to make here
+   * @param event - SelectionChangedCoreEvent dispatched by the core
+   */
+  #onSelectionChanged = (event: SelectionChangedCoreEvent): void => {
+    void this.#handleSelectionChange(event);
+  };
+
   /**
    * InlineToolbarUI class constructor
    * @param params - Plugin parameters
@@ -72,14 +152,25 @@ export class InlineToolbarUI implements EditorjsPlugin {
 
     this.#render();
 
-    this.#eventBus.addEventListener(`core:${CoreEventType.SelectionChanged}`, (event: SelectionChangedCoreEvent) => void this.#handleSelectionChange(event));
+    this.#eventBus.addEventListener(`core:${CoreEventType.SelectionChanged}`, this.#onSelectionChanged);
   }
 
   /**
    * Cleanup when plugin is destroyed
    */
   public destroy(): void {
-    this.#nodes.holder?.remove();
+    /**
+     * Unsubscribed first, so that a selection change arriving mid-teardown cannot put a new
+     * popover up in the holder that is about to be detached
+     */
+    this.#eventBus.removeEventListener(`core:${CoreEventType.SelectionChanged}`, this.#onSelectionChanged);
+
+    /**
+     * Removing the holder detaches the popover with it but leaves the document-level listeners
+     * and the pending announcement alive, so tear the toolbar down properly first
+     */
+    this.#hide();
+    this.#nodes.holder.remove();
   }
 
   /**
@@ -111,6 +202,17 @@ export class InlineToolbarUI implements EditorjsPlugin {
       || !selection
       || !selection.rangeCount
     ) {
+      /**
+       * A control inside the toolbar taking real DOM focus (e.g. VoiceOver activating a button,
+       * unlike a plain mouse click which Safari doesn't focus by default) collapses the native
+       * text selection as a side effect. That is not the user dismissing the toolbar - it is
+       * the toolbar being actively used - so it must not be torn down out from under whatever
+       * is currently focused inside it (e.g. the link tool's URL input)
+       */
+      if (document.activeElement instanceof Node && this.#nodes.holder.contains(document.activeElement)) {
+        return;
+      }
+
       this.#hide();
 
       return;
@@ -124,7 +226,16 @@ export class InlineToolbarUI implements EditorjsPlugin {
       return;
     }
 
-    await this.#renderPopover(availableInlineTools, textRange, fragments);
+    const isCurrent = await this.#renderPopover(availableInlineTools, textRange, fragments);
+
+    /**
+     * A superseded render built nothing, so there is nothing to position or show — and doing
+     * either would move and re-announce the toolbar the render that overtook it put up
+     */
+    if (!isCurrent) {
+      return;
+    }
+
     this.#move();
     this.#show();
   }
@@ -135,24 +246,80 @@ export class InlineToolbarUI implements EditorjsPlugin {
   #render(): void {
     this.#nodes.holder = make('div', Style['inline-toolbar']);
 
+    /**
+     * The toolbar appears next to a text selection without moving focus or DOM position, so
+     * nothing tells a screen reader user it's there or that Tab now leads somewhere new. This
+     * region announces its appearance without disturbing where the user actually is.
+     */
+    this.#nodes.liveRegion = make('div', Style['visually-hidden']);
+    this.#nodes.liveRegion.setAttribute('role', 'status');
+    this.#nodes.liveRegion.setAttribute('aria-live', 'polite');
+
+    /**
+     * ui-kit's own popover also carries a role="status" live region (for search results /
+     * confirmation announcements), so plain role-based lookup can't tell the two apart in tests
+     */
+    this.#nodes.liveRegion.setAttribute('data-testid', 'inline-toolbar-announcer');
+    this.#nodes.holder.appendChild(this.#nodes.liveRegion);
+
     this.#eventBus.dispatchEvent(new InlineToolbarRenderedUIEvent({ toolbar: this.#nodes.holder }));
   }
 
+  /**
+   * Announces a message to screen readers via the toolbar's own live region.
+   * The region is cleared first, otherwise repeating the same text is not announced
+   * @param message - text to announce
+   */
+  #announce(message: string): void {
+    const region = this.#nodes.liveRegion;
+
+    this.#cancelPendingAnnouncement();
+
+    region.textContent = '';
+
+    this.#announcementTimeout = setTimeout(() => {
+      this.#announcementTimeout = null;
+      region.textContent = message;
+    }, ANNOUNCEMENT_DELAY);
+  }
+
+  /**
+   * Drops an announcement that has been scheduled but not written yet.
+   * Without this, a toolbar dismissed inside the delay still announces itself as available
+   */
+  #cancelPendingAnnouncement(): void {
+    if (this.#announcementTimeout === null) {
+      return;
+    }
+
+    clearTimeout(this.#announcementTimeout);
+    this.#announcementTimeout = null;
+  }
+
   /**
    * Creates a new InlinePopover instance and adds it to the Editor UI
    * @param availableInlineTools - inline tools to render in the toolbar
    * @param textRange - selected text range
    * @param fragments - inline tool fragments for the selected text range
+   * @returns false when a later render started while this one was awaiting, so the caller
+   * knows this call built nothing and must not act on it
    */
   async #renderPopover(
     availableInlineTools: InlineToolFacade[],
     textRange: TextRange,
     fragments: InlineFragment[]
-  ): Promise<void> {
-    if (this.#popover !== null) {
-      this.#popover.destroy();
-      this.#popover = null;
-    }
+  ): Promise<boolean> {
+    /**
+     * Claimed before the first await, so that ordering is decided by when a render *started*
+     * rather than by when its tools happened to resolve. Every tool contributes an awaited
+     * `getToolbarConfig`, so two selection changes in flight at once can resolve in either
+     * order — and without this the slower one wins whether or not it is the older one, putting
+     * up a toolbar whose `isActive`/`onActivate` closures captured a `textRange` the user has
+     * already moved off
+     */
+    this.#renderGeneration += 1;
+
+    const generation = this.#renderGeneration;
 
     const popoverItems = Array.from(availableInlineTools).map(async (tool, i) => {
       const toolFragments = fragments.filter((fragment: InlineFragment) => fragment.tool === tool.name);
@@ -218,28 +385,223 @@ export class InlineToolbarUI implements EditorjsPlugin {
         .flat();
     });
 
+    const items = (await Promise.all(popoverItems)).flat();
+
+    /**
+     * Anything that started a render of its own while this one was awaiting has taken over:
+     * a newer selection change, or a #hide() that dropped the toolbar entirely. Bailing out
+     * before the teardown below is what keeps this call from disposing of a popover it did
+     * not build, and from replacing it with one built for a selection that is already gone
+     */
+    if (generation !== this.#renderGeneration) {
+      return false;
+    }
+
+    /**
+     * Torn down here rather than on entry, after the last `await` and immediately before the
+     * replacement is built. Two selection changes in a row can both be partway through this
+     * method, and tearing down on entry means the second one runs its teardown *before* the
+     * first one has built anything — so the first one's popover is then overwritten with no
+     * teardown at all, leaking its document-level listeners. Doing it here makes each call
+     * dispose of whatever is actually current, whichever order they interleave in.
+     *
+     * It also means the outgoing toolbar stays up across the rebuild instead of blinking out
+     * for the duration of the await
+     */
+    this.#destroyPopover();
+
     this.#popover = new PopoverInline({
-      items: (await Promise.all(popoverItems)).flat(),
+      items,
       scopeElement: this.#config.holder,
       closeOnOutsideClick: false,
+
+      /**
+       * Names the toolbar the popover renders its items into,
+       * so it is distinguishable from the block actions toolbar
+       */
+      messages: {
+        label: messages.inlineToolbar,
+      },
+    });
+
+    /**
+     * The inline popover never takes real focus — moving it to a button would drop the text
+     * selection the inline tools operate on. Which item is currently highlighted is therefore
+     * only conveyable via aria-activedescendant on the element that does hold the focus,
+     * that is the block being edited
+     */
+    this.#popover.on(PopoverEvent.ActiveDescendantChanged, (itemId: string | null) => {
+      this.#setActiveDescendant(itemId);
     });
 
-    this.#nodes.holder.appendChild(this.#popover.getElement());
+    /**
+     * The popover can also close on its own, e.g. on Escape, without going through #hide()
+     */
+    this.#popover.on(PopoverEvent.Closed, this.#onPopoverClosed);
+
+    /**
+     * Only the popover is swapped, never the whole holder: a live region has to be present in
+     * the accessibility tree *before* its text changes for a screen reader to announce it.
+     * Re-inserting the region on every render (as replaceChildren did) resets it each time,
+     * and the announcement right after was silently dropped.
+     *
+     * Exactly one popover is in the holder at any point — the teardown above detached the
+     * previous one — so its items cannot surface in the accessibility tree twice
+     */
+    const popoverElement = this.#popover.getElement();
+
+    /** Named so that the focused editable can claim it via aria-owns, see #setActiveDescendant */
+    popoverElement.id = this.#popoverElementId;
+
+    this.#nodes.holder.appendChild(popoverElement);
+
+    return true;
+  }
+
+  /**
+   * Tears the current popover down, if there is one, and forgets it.
+   *
+   * Forgetting it is the point: `destroy()` detaches the element and drops the popover's
+   * document-level listeners, but leaves the instance itself perfectly callable, so a reference
+   * kept past this point reads as a live popover and gets torn down a second time on the next
+   * rebuild - re-running item cleanup and re-emitting PopoverEvent.Closed to anything listening
+   */
+  #destroyPopover(): void {
+    /** Unconditional, so that no reference to a gone popover can outlive it by any route */
+    this.#setActiveDescendant(null);
+
+    if (this.#popover === null) {
+      return;
+    }
+
+    /**
+     * destroy() hides the popover on its way out and emits Closed. Unsubscribed first: a rebuild
+     * destroys the outgoing popover while the toolbar stays open, and taking that for a close
+     * would re-announce the toolbar on every selection change
+     */
+    this.#popover.off(PopoverEvent.Closed, this.#onPopoverClosed);
+
+    /** destroy() hides the popover on its way out, so hiding it here first would be a no-op */
+    this.#popover.destroy();
+    this.#popover = null;
   }
 
   /**
    * Shows the Inline Toolbar
    */
   #show(): void {
+    const wasVisible = this.#isVisible;
+
     this.#popover?.show();
+    this.#isVisible = true;
+
+    if (!wasVisible) {
+      this.#announce(messages.inlineToolbarAvailable);
+    }
   }
 
+  /**
+   * Handles the popover closing by itself rather than through #hide(), e.g. on Escape.
+   * Without this #isVisible stays true, and the next time the toolbar appears it is taken for
+   * a reselection while already open, so it is never announced again
+   */
+  #onPopoverClosed = (): void => {
+    this.#cancelPendingAnnouncement();
+    this.#isVisible = false;
+  };
+
   /**
    * Hides the Inline Toolbar
    */
   #hide(): void {
-    this.#popover?.hide();
-    this.#popover?.destroy();
+    /**
+     * Counts as a render for the purpose of the generation check, so that a rebuild still
+     * awaiting its tools does not resolve after this and put the toolbar back up for a
+     * selection the user has already dropped
+     */
+    this.#renderGeneration += 1;
+
+    this.#cancelPendingAnnouncement();
+    this.#destroyPopover();
+    this.#isVisible = false;
+  }
+
+  /**
+   * Points the element holding the focus at the popover item highlighted by keyboard
+   * navigation, or clears the pointer when nothing is highlighted anymore
+   * @param itemId - id of the highlighted item's element, null when nothing is highlighted
+   */
+  #setActiveDescendant(itemId: string | null): void {
+    const host = itemId === null ? null : this.#activeDescendantTarget();
+
+    /**
+     * Released before the new one is adopted, and unconditionally when there is no new one.
+     * Skipping this would leave the attributes on an element that no longer holds focus,
+     * still claiming a popover it has nothing to do with - a stale reference that outlives
+     * every route the popover teardown covers
+     */
+    if (this.#activeDescendantHost !== null && this.#activeDescendantHost !== host) {
+      this.#activeDescendantHost.removeAttribute('aria-activedescendant');
+      this.#activeDescendantHost.removeAttribute('aria-owns');
+    }
+
+    this.#activeDescendantHost = host;
+
+    if (host === null || itemId === null) {
+      return;
+    }
+
+    /**
+     * aria-activedescendant is only resolved when the element it names is a descendant of the
+     * element holding focus, or is claimed by it via aria-owns. The toolbar is rendered as a
+     * sibling of the blocks holder (EditorjsUI appends both to the editor wrapper), and the
+     * holder is what keeps focus, so on DOM structure alone the reference points outside the
+     * focused subtree and assistive tech drops it. aria-owns re-parents the popover onto the
+     * holder in the accessibility tree only, leaving the DOM — and hence the text selection
+     * the inline tools operate on — untouched.
+     *
+     * Set together with the reference and removed together with it, so the two can never
+     * disagree about which element owns the popover
+     */
+    host.setAttribute('aria-owns', this.#popoverElementId);
+    host.setAttribute('aria-activedescendant', itemId);
+  }
+
+  /**
+   * The element the highlighted item can be announced through, or null when there isn't one.
+   *
+   * Normally the block being edited: focus stays in the text while the popover is navigated,
+   * so that is what holds it. Three cases have no usable target, and all have to yield null
+   * rather than fall back to whatever was last used - writing to a stale host points a
+   * previously focused element at a popover that is no longer anything to do with it:
+   *
+   * - Focus somewhere that isn't an element at all. Defensive; `document.activeElement` is
+   *   null between documents and need not be an `HTMLElement` in general.
+   * - Focus *inside the toolbar itself*, which happens once a user Tabs into it. There is
+   *   nothing to announce indirectly then - the focused button is the active item, and
+   *   aria-activedescendant is only consulted on the focused element anyway. Claiming the
+   *   popover from a control inside it would also make the element own its own ancestor.
+   * - Focus *outside this editor*. Reachable today on a page with two editors: on chromium the
+   *   inline toolbar is not scoped per instance, so selecting text in the second editor raises
+   *   the first one's, which would then claim its own popover from the second editor's holder -
+   *   telling assistive technology that controls operating on one document belong to another.
+   *   Bounding the host to this editor doesn't fix that scoping bug, but it turns a confidently
+   *   wrong claim into no claim, which is the safer of the two for a screen reader user
+   * @returns the element to carry the reference, or null when none qualifies
+   */
+  #activeDescendantTarget(): HTMLElement | null {
+    const focused = document.activeElement;
+
+    if (!(focused instanceof HTMLElement) || this.#nodes.holder.contains(focused)) {
+      return null;
+    }
+
+    /** The editor this toolbar belongs to, which is also the popover's scope element */
+    if (!this.#config.holder.contains(focused)) {
+      return null;
+    }
+
+    return focused;
   }
 
   /**
diff --git a/packages/ui/src/Toolbar/Toolbar.ts b/packages/ui/src/Toolbar/Toolbar.ts
index 50e2f81d..75392f1d 100644
--- a/packages/ui/src/Toolbar/Toolbar.ts
+++ b/packages/ui/src/Toolbar/Toolbar.ts
@@ -8,6 +8,17 @@ import Style from './Toolbar.module.pcss';
 import { ToolbarRenderedUIEvent } from './ToolbarRenderedUIEvent.js';
 import type { BlockSelectedUIEvent } from '../Blocks/events/index.js';
 import { ToolboxOpenUIEvent } from '../Toolbox/events/index.js';
+import { messages } from '../messages.js';
+
+/**
+ * Keys that move between the controls of a horizontal toolbar, mapped to the direction they
+ * move in. Deliberately horizontal-only: the actions container lays its buttons out in a row,
+ * and ArrowUp/ArrowDown belong to the toolbox popover that opens inside it
+ */
+const TOOLBAR_STEP_KEYS = new Map<string, number>([
+  ['ArrowRight', 1],
+  ['ArrowLeft', -1],
+]);
 
 /**
  * HTML Nodes toolbar uses in the UI
@@ -118,7 +129,42 @@ export class ToolbarUI implements EditorjsPlugin {
     this.#nodes.holder.appendChild(this.#nodes.actions);
     this.#nodes.actions.appendChild(this.#nodes.plusButton);
 
+    /**
+     * The actions container groups related controls. It is named because the inline toolbar
+     * is a toolbar too, and the plus button is icon-only, so it needs a name of its own
+     */
+    this.#nodes.actions.setAttribute('role', 'toolbar');
+    this.#nodes.actions.setAttribute('aria-label', messages.blockActionsToolbar);
+    this.#nodes.actions.setAttribute('aria-orientation', 'horizontal');
+    this.#nodes.plusButton.setAttribute('aria-label', messages.addBlockButton);
+
+    /**
+     * role="toolbar" is a promise that the group is a single tab stop navigated with the arrow
+     * keys, not a promise the browser keeps on its own. With one control today the roving
+     * tabindex is invisible at runtime, but the alternative is a role that describes an
+     * interaction the toolbar does not support - and getting it right now is what keeps adding
+     * a second control from being the moment it silently becomes wrong
+     */
+    this.#nodes.actions.addEventListener('keydown', this.#handleActionsKeydown);
+    this.#updateRovingTabindex(this.#nodes.plusButton);
+
+    /**
+     * The button opens the toolbox, which is rendered as a menu.
+     * The expanded state is kept in sync with the toolbox events, see #subscribeToToolboxEvents
+     */
+    this.#nodes.plusButton.setAttribute('aria-haspopup', 'menu');
+    this.#nodes.plusButton.setAttribute('aria-expanded', 'false');
+
     this.#nodes.plusButton.addEventListener('click', () => {
+      /**
+       * Safari does not focus a button when it is clicked, so without this the toolbox
+       * popover captures `document.body` as the element to restore focus to when it closes -
+       * and closing it (by Escape, or by inserting a block) drops focus out of the editor
+       * entirely. Focusing the button that owns the menu also matches the WAI-ARIA menu
+       * button pattern, where focus returns to the button once the menu is dismissed
+       */
+      this.#nodes.plusButton.focus();
+
       this.#openToolbox();
     });
 
@@ -137,10 +183,12 @@ export class ToolbarUI implements EditorjsPlugin {
 
     this.#eventBus.addEventListener(`ui:toolbox:opened`, () => {
       this.#isToolboxOpen = true;
+      this.#nodes.plusButton.setAttribute('aria-expanded', 'true');
     });
 
     this.#eventBus.addEventListener(`ui:toolbox:closed`, () => {
       this.#isToolboxOpen = false;
+      this.#nodes.plusButton.setAttribute('aria-expanded', 'false');
     });
   }
 
@@ -150,4 +198,75 @@ export class ToolbarUI implements EditorjsPlugin {
   #openToolbox(): void {
     this.#eventBus.dispatchEvent(new ToolboxOpenUIEvent('ui:toolbox:open'));
   }
+
+  /**
+   * The toolbar's own controls, in the order the arrow keys walk them.
+   *
+   * Read from the DOM rather than kept as a list, so a control added to the container later is
+   * navigable without anything here needing to know about it. Scoped to direct children: the
+   * toolbox popover is rendered *inside* this container and its menu items are emphatically not
+   * toolbar controls
+   * @returns the container's own buttons, in document order
+   */
+  get #controls(): HTMLElement[] {
+    return Array.from(this.#nodes.actions.children).filter(
+      (child): child is HTMLElement => child instanceof HTMLElement && child.tagName === 'BUTTON'
+    );
+  }
+
+  /**
+   * Makes one control the toolbar's single tab stop and takes the rest out of the tab order,
+   * which is what lets Tab move past the toolbar rather than through it
+   * @param active - control to leave reachable by Tab
+   */
+  #updateRovingTabindex(active: HTMLElement): void {
+    this.#controls.forEach((control) => {
+      control.tabIndex = control === active ? 0 : -1;
+    });
+  }
+
+  /**
+   * Moves focus between the toolbar's controls with the arrow keys, per the WAI-ARIA toolbar
+   * pattern, and keeps the tab stop on whichever one was last focused
+   * @param event - keydown captured on the actions container
+   */
+  #handleActionsKeydown = (event: KeyboardEvent): void => {
+    /**
+     * The toolbar pattern owns the *unmodified* arrow keys and nothing else. A modified arrow
+     * always belongs to someone else, and preventDefault()-ing it takes a key away from its
+     * real owner: VO+Right and VO+Left - VoiceOver's own cursor navigation - arrive here as
+     * Control+Option+Arrow, so without this the toolbar swallows them and a VoiceOver user
+     * whose cursor has reached the plus button cannot move off it at all. Cmd+Arrow and
+     * Shift+Arrow are the same kind of theft from the OS and from selection
+     */
+    if (event.ctrlKey || event.altKey || event.metaKey || event.shiftKey) {
+      return;
+    }
+
+    const step = TOOLBAR_STEP_KEYS.get(event.key);
+
+    if (step === undefined) {
+      return;
+    }
+
+    const controls = this.#controls;
+    const current = controls.indexOf(event.target as HTMLElement);
+
+    /**
+     * Only keys pressed on a control of this toolbar are ours. Anything arriving from inside the
+     * toolbox popover is that popover's to handle, and stealing it here would break its own
+     * keyboard navigation
+     */
+    if (current === -1) {
+      return;
+    }
+
+    /** Wraps, which the pattern calls for and which also makes a single-control toolbar a no-op */
+    const next = controls[(current + step + controls.length) % controls.length];
+
+    event.preventDefault();
+
+    this.#updateRovingTabindex(next);
+    next.focus();
+  };
 }
diff --git a/packages/ui/src/Toolbox/Toolbox.ts b/packages/ui/src/Toolbox/Toolbox.ts
index d3df296a..e167673a 100644
--- a/packages/ui/src/Toolbox/Toolbox.ts
+++ b/packages/ui/src/Toolbox/Toolbox.ts
@@ -15,6 +15,7 @@ import { PopoverDesktop, PopoverEvent } from '@editorjs/ui-kit';
 import type { BlockSelectedUIEvent } from '../Blocks/events/index.js';
 import { ToolboxRenderedUIEvent, ToolboxClosedUIEvent, ToolboxOpenedUIEvent } from './events/index.js';
 import type { ToolboxOptionsEntry } from './ToolboxConfigEntry.js';
+import { messages } from '../messages.js';
 
 /**
  * UI module responsible for rendering the toolbox
@@ -82,6 +83,14 @@ export class ToolboxUI implements EditorjsPlugin {
       scopeElement: this.#editorConfig.holder,
       searchable: true,
       items: [],
+
+      /**
+       * Names the menu the popover renders its items into, so assistive technologies
+       * announce what the list is for. Matches the name of the button that opens it
+       */
+      messages: {
+        label: messages.addBlockMenu,
+      },
     });
 
     this.#popover.on(PopoverEvent.Closed, () => {
@@ -143,6 +152,11 @@ export class ToolboxUI implements EditorjsPlugin {
         title: tool.name,
         ...toolbox,
         closeOnActivate: true,
+
+        /**
+         * @todo `focus: true` does not put the caret into the inserted block,
+         * so the user has to click it before typing
+         */
         onActivate: () => {
           void this.#api.blocks.insert({
             type: tool.name,
diff --git a/packages/ui/src/messages.ts b/packages/ui/src/messages.ts
new file mode 100644
index 00000000..bc4f4856
--- /dev/null
+++ b/packages/ui/src/messages.ts
@@ -0,0 +1,29 @@
+/**
+ * Every user-facing string `@editorjs/ui` writes into the DOM, in one place.
+ *
+ * None of these is rendered visually — they exist to be read out by assistive technology — but
+ * they are user-facing text all the same, and localising them will mean sourcing them from the
+ * editor config instead of from here. Collecting them in one module is what makes that a change
+ * to a single file rather than to every call site that sets an attribute. i18n itself stays out
+ * of scope (see the Non-Goals in `openspec/changes/add-editor-aria-semantics/design.md`); this
+ * is only the seam it would attach to.
+ */
+export const messages = {
+  /** Accessible name of the container holding the block-level controls */
+  blockActionsToolbar: 'Block actions',
+
+  /** Accessible name of the icon-only button that opens the toolbox */
+  addBlockButton: 'Add block',
+
+  /** Accessible name of the toolbox menu. Deliberately matches the button that opens it */
+  addBlockMenu: 'Add block',
+
+  /** Accessible name of the inline formatting toolbar, distinguishing it from the block one */
+  inlineToolbar: 'Text formatting',
+
+  /**
+   * Announced when the inline toolbar appears. It takes no DOM focus and moves no virtual
+   * cursor, so without this nothing tells a screen reader user that it is there at all
+   */
+  inlineToolbarAvailable: 'Text formatting toolbar available. Press Tab to enter.',
+} as const;
diff --git a/yarn.lock b/yarn.lock
index 0ef9b761..842c2414 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -15,6 +15,17 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@axe-core/playwright@npm:^4.12.1":
+  version: 4.13.0
+  resolution: "@axe-core/playwright@npm:4.13.0"
+  dependencies:
+    axe-core: "npm:~4.13.0"
+  peerDependencies:
+    playwright-core: ">= 1.0.0"
+  checksum: 2400e309d6f6d96b3f3f12b00a80e32cb0213726fcfc3c457b36d17f7136a3361f02a7523286024d7e8ceba9045a5f9c18edd8bc352f76b549faedce298fada2
+  languageName: node
+  linkType: hard
+
 "@babel/code-frame@npm:^7.0.0, @babel/code-frame@npm:^7.12.13, @babel/code-frame@npm:^7.23.5, @babel/code-frame@npm:^7.26.2":
   version: 7.26.2
   resolution: "@babel/code-frame@npm:7.26.2"
@@ -2250,7 +2261,7 @@ __metadata:
   resolution: "@editorjs/bold@workspace:packages/tools/bold"
   dependencies:
     "@codexteam/icons": "npm:^0.3.3"
-    "@editorjs/dom": "npm:^1.1.0"
+    "@editorjs/dom": "npm:^1.2.0"
     "@editorjs/sdk": "workspace:^"
     "@types/eslint": "npm:^9.6.1"
     "@types/node": "npm:^22.10.2"
@@ -2386,7 +2397,7 @@ __metadata:
   version: 0.0.0-use.local
   resolution: "@editorjs/dom-adapters@workspace:packages/dom-adapters"
   dependencies:
-    "@editorjs/dom": "npm:^1.1.0"
+    "@editorjs/dom": "npm:^1.2.0"
     "@editorjs/sdk": "workspace:^"
     "@jest/globals": "npm:^29.7.0"
     "@stryker-mutator/core": "npm:^7.0.2"
@@ -2407,12 +2418,12 @@ __metadata:
   languageName: unknown
   linkType: soft
 
-"@editorjs/dom@npm:^1.1.0":
-  version: 1.1.0
-  resolution: "@editorjs/dom@npm:1.1.0"
+"@editorjs/dom@npm:^1.1.0, @editorjs/dom@npm:^1.2.0":
+  version: 1.2.0
+  resolution: "@editorjs/dom@npm:1.2.0"
   dependencies:
-    "@editorjs/helpers": "npm:^1.2.0"
-  checksum: 0d468d99eede9d98e2fac518cf38528f9f427a8607c80631f12e0ae3eaaa19f77e86f5b01a1ff0c51f1e85bea84b3682f8634affc327edcc2409104da086188a
+    "@editorjs/helpers": "npm:^1.2.2"
+  checksum: 8dee6a76f3d211c7c37d0690d3714d44877b3f646c24aa3cfc82a449a18657179430624346f4ae42bd96f1d5d3b3fb712f900d534d1b13963e96670aee72dc98
   languageName: node
   linkType: hard
 
@@ -2427,6 +2438,7 @@ __metadata:
   version: 0.0.0-use.local
   resolution: "@editorjs/editorjs@workspace:packages/editorjs"
   dependencies:
+    "@axe-core/playwright": "npm:^4.12.1"
     "@babel/core": "npm:^7.29.0"
     "@babel/preset-env": "npm:^7.29.2"
     "@editorjs/bold": "workspace:^"
@@ -2440,7 +2452,10 @@ __metadata:
     "@editorjs/sdk": "workspace:^"
     "@editorjs/shortcuts-plugin": "workspace:^"
     "@editorjs/ui": "workspace:^"
+    "@guidepup/guidepup": "npm:^0.29.2"
+    "@guidepup/playwright": "npm:^0.18.0"
     "@jest/globals": "npm:^29.7.0"
+    "@playwright/test": "npm:^1.62.0"
     "@types/eslint": "npm:^9.6.1"
     "@types/jest": "npm:^29.5.12"
     "@types/node": "npm:^22.10.2"
@@ -2449,21 +2464,14 @@ __metadata:
     eslint-config-codex: "npm:^2.0.3"
     eslint-plugin-import: "npm:^2.31.0"
     jest: "npm:^29.7.0"
+    playwright-core: "npm:^1.62.0"
     ts-jest: "npm:^29.2.5"
     ts-node: "npm:^10.9.2"
     typescript: "npm:^5.5.4"
+    vite: "npm:^5.4.11"
   languageName: unknown
   linkType: soft
 
-"@editorjs/helpers@npm:^1.2.0":
-  version: 1.2.0
-  resolution: "@editorjs/helpers@npm:1.2.0"
-  dependencies:
-    codex-tooltip: "npm:^1.0.5"
-  checksum: 7a56163ea342f9e9ea111132900b19fe6672cd475276a5a85048b27faa0a5efd6f7cee90fd0c25d8bdf2838519de696492be90646b11d08d02daa9ee42105fa6
-  languageName: node
-  linkType: hard
-
 "@editorjs/helpers@npm:^1.2.2":
   version: 1.2.2
   resolution: "@editorjs/helpers@npm:1.2.2"
@@ -2478,7 +2486,7 @@ __metadata:
   resolution: "@editorjs/inline-link@workspace:packages/tools/inline-link"
   dependencies:
     "@codexteam/icons": "npm:^0.3.3"
-    "@editorjs/dom": "npm:^1.1.0"
+    "@editorjs/dom": "npm:^1.2.0"
     "@editorjs/sdk": "workspace:^"
     "@types/eslint": "npm:^9.6.1"
     "@types/node": "npm:^22.10.2"
@@ -2494,7 +2502,7 @@ __metadata:
   resolution: "@editorjs/italic@workspace:packages/tools/italic"
   dependencies:
     "@codexteam/icons": "npm:^0.3.3"
-    "@editorjs/dom": "npm:^1.1.0"
+    "@editorjs/dom": "npm:^1.2.0"
     "@editorjs/sdk": "workspace:^"
     "@types/eslint": "npm:^9.6.1"
     "@types/node": "npm:^22.10.2"
@@ -2597,7 +2605,7 @@ __metadata:
     "@babel/preset-env": "npm:^7.29.2"
     "@editorjs/helpers": "npm:^1.2.2"
     "@editorjs/model-types": "workspace:^"
-    "@editorjs/ui-kit": "npm:^1.1.5"
+    "@editorjs/ui-kit": "npm:^2.0.0"
     "@jest/globals": "npm:^29.7.0"
     "@types/eslint": "npm:^9.6.1"
     "@types/jest": "npm:^29.5.12"
@@ -2640,15 +2648,15 @@ __metadata:
   languageName: unknown
   linkType: soft
 
-"@editorjs/ui-kit@npm:^1.1.5":
-  version: 1.1.5
-  resolution: "@editorjs/ui-kit@npm:1.1.5"
+"@editorjs/ui-kit@npm:^2.0.0":
+  version: 2.0.0
+  resolution: "@editorjs/ui-kit@npm:2.0.0"
   dependencies:
     "@codexteam/icons": "npm:^0.3.3"
     "@editorjs/caret": "npm:^1.1.0"
-    "@editorjs/dom": "npm:^1.1.0"
+    "@editorjs/dom": "npm:^1.2.0"
     "@editorjs/helpers": "npm:^1.2.2"
-  checksum: c46cc31874e5271b097486e0abdd626a23d9cd6acd1a81abda580c5a762bdb513984a6eb380639ba8a1cfb945a1cdcfe790482c19508eaf438293f7d10f83568
+  checksum: 97110bd1d12fe22077cff40bf9d7df044d6cdc086cdb80c0bcd0b5a96b1363d7efa10cce62db67932f9daa0ebe782b44ed3f749d4f5781d703d2a75b0e7e8f74
   languageName: node
   linkType: hard
 
@@ -2659,12 +2667,12 @@ __metadata:
     "@codexteam/icons": "npm:^0.3.3"
     "@codexteam/ui": "npm:^0.2.2"
     "@editorjs/core": "workspace:^"
-    "@editorjs/dom": "npm:^1.1.0"
+    "@editorjs/dom": "npm:^1.2.0"
     "@editorjs/dom-adapters": "workspace:^"
     "@editorjs/helpers": "npm:^1.2.2"
     "@editorjs/paragraph": "workspace:^"
     "@editorjs/sdk": "workspace:^"
-    "@editorjs/ui-kit": "npm:^1.1.5"
+    "@editorjs/ui-kit": "npm:^2.0.0"
     chokidar-cli: "npm:^3.0.0"
     eslint: "npm:^9.9.1"
     eslint-config-codex: "npm:^2.0.3"
@@ -3164,6 +3172,23 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@guidepup/guidepup@npm:^0.29.2":
+  version: 0.29.2
+  resolution: "@guidepup/guidepup@npm:0.29.2"
+  checksum: 6517918c17ec253a59f4088133487453b59bf339b71a730f65c5465f9e05f41afd3d1034ba91a2e73df3617263551c931dc6ba8890b8b032af22ecc357c6c2d3
+  languageName: node
+  linkType: hard
+
+"@guidepup/playwright@npm:^0.18.0":
+  version: 0.18.0
+  resolution: "@guidepup/playwright@npm:0.18.0"
+  peerDependencies:
+    "@guidepup/guidepup": ">=0.27.0"
+    "@playwright/test": ^1.57.0
+  checksum: 09355c1e04cc9b525c8c897f496424f2fbe1e21b242de9561adc176e2e191ca0ffe323dee144584f39c7e7f812e4f84f2e0d827d784455816465110a3b904037
+  languageName: node
+  linkType: hard
+
 "@hawk.so/nodejs@npm:^3.1.5":
   version: 3.1.5
   resolution: "@hawk.so/nodejs@npm:3.1.5"
@@ -4031,6 +4056,17 @@ __metadata:
   languageName: node
   linkType: hard
 
+"@playwright/test@npm:^1.62.0":
+  version: 1.62.1
+  resolution: "@playwright/test@npm:1.62.1"
+  dependencies:
+    playwright: "npm:1.62.1"
+  bin:
+    playwright: cli.js
+  checksum: a84fdc2b0c0f01131fa4c0f0aaebf2698a618ca4a459e3b71ebec4b0b8a5be5b7b1a3cfc063e316d4d75f403a04078d214baf69c4bcbc9606ba12be696d4ff14
+  languageName: node
+  linkType: hard
+
 "@posthog/core@npm:^1.44.0":
   version: 1.45.0
   resolution: "@posthog/core@npm:1.45.0"
@@ -5342,6 +5378,13 @@ __metadata:
   languageName: node
   linkType: hard
 
+"axe-core@npm:~4.13.0":
+  version: 4.13.0
+  resolution: "axe-core@npm:4.13.0"
+  checksum: b9319bedc705fde00e4abd981d8724202cc20102e4ae6d8edfde33cb5265e0fb8f67f32adcb4ad33fbd4a2c8d7ad7ef5af1d933d9ad859bed90e3eae0ee8c52f
+  languageName: node
+  linkType: hard
+
 "axios@npm:^0.21.1":
   version: 0.21.4
   resolution: "axios@npm:0.21.4"
@@ -5906,13 +5949,6 @@ __metadata:
   languageName: node
   linkType: hard
 
-"codex-tooltip@npm:^1.0.5":
-  version: 1.0.5
-  resolution: "codex-tooltip@npm:1.0.5"
-  checksum: adb4cc8a9a26de3eb39d22b9a2c0ca57ef387d5d4a52c0a978a0a13ba0ea53dc6603604702f005fa42fd074db936742e1a1094d59debb7f987dc096849e818dd
-  languageName: node
-  linkType: hard
-
 "codex-tooltip@npm:^1.0.6":
   version: 1.0.6
   resolution: "codex-tooltip@npm:1.0.6"
@@ -7720,6 +7756,16 @@ __metadata:
   languageName: node
   linkType: hard
 
+"fsevents@npm:2.3.2":
+  version: 2.3.2
+  resolution: "fsevents@npm:2.3.2"
+  dependencies:
+    node-gyp: "npm:latest"
+  checksum: 6b5b6f5692372446ff81cf9501c76e3e0459a4852b3b5f1fc72c103198c125a6b8c72f5f166bdd76ffb2fca261e7f6ee5565daf80dca6e571e55bcc589cc1256
+  conditions: os=darwin
+  languageName: node
+  linkType: hard
+
 "fsevents@npm:^2.3.2, fsevents@npm:~2.3.2, fsevents@npm:~2.3.3":
   version: 2.3.3
   resolution: "fsevents@npm:2.3.3"
@@ -7730,6 +7776,15 @@ __metadata:
   languageName: node
   linkType: hard
 
+"fsevents@patch:fsevents@npm%3A2.3.2#optional!builtin<compat/fsevents>":
+  version: 2.3.2
+  resolution: "fsevents@patch:fsevents@npm%3A2.3.2#optional!builtin<compat/fsevents>::version=2.3.2&hash=df0bf1"
+  dependencies:
+    node-gyp: "npm:latest"
+  conditions: os=darwin
+  languageName: node
+  linkType: hard
+
 "fsevents@patch:fsevents@npm%3A^2.3.2#optional!builtin<compat/fsevents>, fsevents@patch:fsevents@npm%3A~2.3.2#optional!builtin<compat/fsevents>, fsevents@patch:fsevents@npm%3A~2.3.3#optional!builtin<compat/fsevents>":
   version: 2.3.3
   resolution: "fsevents@patch:fsevents@npm%3A2.3.3#optional!builtin<compat/fsevents>::version=2.3.3&hash=df0bf1"
@@ -10428,6 +10483,30 @@ __metadata:
   languageName: node
   linkType: hard
 
+"playwright-core@npm:1.62.1, playwright-core@npm:^1.62.0":
+  version: 1.62.1
+  resolution: "playwright-core@npm:1.62.1"
+  bin:
+    playwright-core: cli.js
+  checksum: 2dab88793a6a5cbfa27641664548ded72a4f869d7eab8d3541e070081b5e09595253aa3dbd42eb4e6eca1b03d96a727c60704359b5b309e71ca58b12549a4c06
+  languageName: node
+  linkType: hard
+
+"playwright@npm:1.62.1":
+  version: 1.62.1
+  resolution: "playwright@npm:1.62.1"
+  dependencies:
+    fsevents: "npm:2.3.2"
+    playwright-core: "npm:1.62.1"
+  dependenciesMeta:
+    fsevents:
+      optional: true
+  bin:
+    playwright: cli.js
+  checksum: f99546873ab2545160ad5a0145fef8e2c1d805efd1ba77356f5b0ee3d8688192b3a2af08cd948bece36ca386fdfad889ef7e53b7aaad309940744c0bbccc0a19
+  languageName: node
+  linkType: hard
+
 "possible-typed-array-names@npm:^1.0.0":
   version: 1.1.0
   resolution: "possible-typed-array-names@npm:1.1.0"
@@ -13182,6 +13261,49 @@ __metadata:
   languageName: node
   linkType: hard
 
+"vite@npm:^5.4.11":
+  version: 5.4.21
+  resolution: "vite@npm:5.4.21"
+  dependencies:
+    esbuild: "npm:^0.21.3"
+    fsevents: "npm:~2.3.3"
+    postcss: "npm:^8.4.43"
+    rollup: "npm:^4.20.0"
+  peerDependencies:
+    "@types/node": ^18.0.0 || >=20.0.0
+    less: "*"
+    lightningcss: ^1.21.0
+    sass: "*"
+    sass-embedded: "*"
+    stylus: "*"
+    sugarss: "*"
+    terser: ^5.4.0
+  dependenciesMeta:
+    fsevents:
+      optional: true
+  peerDependenciesMeta:
+    "@types/node":
+      optional: true
+    less:
+      optional: true
+    lightningcss:
+      optional: true
+    sass:
+      optional: true
+    sass-embedded:
+      optional: true
+    stylus:
+      optional: true
+    sugarss:
+      optional: true
+    terser:
+      optional: true
+  bin:
+    vite: bin/vite.js
+  checksum: 479a63e271d2d9e80a8e553e165444179681f33ddec1e7c84a43c4572f67c3d3abd33136389beb42703e32d3e96e1e8a930a222ee1bb64263ba057c187ccf793
+  languageName: node
+  linkType: hard
+
 "vscode-uri@npm:^3.0.8":
   version: 3.1.0
   resolution: "vscode-uri@npm:3.1.0"