feat: a11y testing setup by matthewlipski · Pull Request #3177 · TypeCellOS/BlockNote

matthewlipski · 2026-10-09T16:38:48Z

Summary

This PR shows a vertical slice of the a11y areas we need to test. Below is the full list of what we need ot test, which what's included in this PR marked as checked.

The approach to testing is based on the a11y study done earlier. It's recommended to get familiarised with that first.

The tests all require using a browser environment due to one of the following:

Test uses axe-core, which requires a real DOM tree to scan.
Test uses GuidePup to test screen reader output, which requires a browser to use a screen reader with.
Test uses Playwright visual snapshots, which require rendering components in a browser.
Test requires browser keyboard navigation/focus handling.
Test requires snapshotting the browser accessibility tree.

The test runner itself is Vitest Browser Mode, which is in line with a lot of our existing browser tests and uses Playwright for the browser.

Below is a summary of what works and what doesn't at the moment. For each type of test:

🟢 Tests are implemented and passing.
🔴 Tests are skipped as the functionality being tested is missing, or are implemented but failing or having incorrect snapshots.

Editor Body

BlockNoteView.browser.test.ts

Keyboard Navigation & Focus
- 🟢 Navigate through a document with the whole default schema using only the arrow keys, including navigating through each cell in a table.
- 🔴 Focus editor without a selection, allowing Tab and arrow keys navigate the page rather than navigating the editor.
  - While the user can hit Escape to revert focus to <body>, it's not quite what we want as they cannot e.g. press Enter to then refocus the editor.
- 🔴 Escape allows the user to focus the next element on the page using Tab.
  - WebKit doesn't preserve the index of the last focused item, so Tab focuses the first element on the page.
- 🔴 Extend keyboard selection to entire block.
  - Selecting entire blocks is possible using Cmd+Click, but not using the keyboard, so only a stub is included for this test. No additional styling is applied when entire block is selected.
- 🔴 Links are focusable when editor is read-only.
  - They are, but have incorrect styling.
- 🔴 The formatting toolbar can be opened when the editor is read-only.
  - Blocks are not focusable when the editor is read-only.
ARIA
- 🔴 Accessibility tree is correct for document with all content types in all possible states.
  - Numbered list item indices are separate text elements, among other issues.
AXE
- 🔴 Scan reports no issues for document with all content types in all possible states, for both light & dark themes.
  - Editor textbox lacks required name.
Visual
- 🟢 A document with content containing everything in the default schema remains legible and doesn't clip content, when text spacing is overridden to that defined by WCAG 1.4.12 success criteria.
- 🟢 A document with content containing everything in the default schema remains legible and doesn't clip content, when text sizing is overridden to that defined by WCAG 1.4.4 success criteria.

BlockNoteView.screen-reader.test.ts

Screen Reader
- 🔴 All content & markup are read out when navigating a document with the whole default schema, including navigating through each cell in a table.
  - Markup such as block nesting level, color and more are missing.
- 🔴 It's communicated to the user when a whole block is selected as opposed to selecting all content within it.
  - Cannot currently tested as we cannot create a selection around a whole block using the keyboard.

Formatting Toolbar

FormattingToolbar.browser.test.ts

Keyboard Navigation & Focus
- 🔴 Each item in the toolbar can be navigated to using Tab and has a visible focus ring. Pressing Enter activates the item and causes some change in the editor.
  - Almost all working but the input in the create link popover is missing a focus ring.
ARIA
- 🟢 Activating each item in the toolbar changes its state in the accessibility tree correctly.
AXE
- 🟢 Scan reports no issues for the base toolbar.
- 🔴 Scan reports no issues for the block type menu.
  - Mantine inserts a focusable div inside the menu, triggering axe aria-required-children violations.
- 🔴 Scan reports no issues for the colors menu.
  - Mantine inserts a focusable div inside the menu, triggering axe aria-required-children violations.
- 🟢 Scan reports no issues for create link popover.

FormattingToolbar.screen-reader.test.ts

Screen Reader
- 🔴 Opening and closing the toolbar causes the change in focus to be clearly communicated.
  - Currently pretty confusing, e.g. on close the whole document content is read out again.

Toggle Heading

block.browser.test.ts

Keyboard Navigation & Focus
- 🔴 Showing/hiding children can be toggled while the used is editing the document.
  - The toggle button is focusable using Tab, but that first requires leaving the editor and is quite clunky. There is no way to show.hide children while the editor remains focused either.
- 🟢 While the editor is read-only, the toggle button can be navigated to using Tab and has a visible focus ring. Pressing Enter toggles the button and causes some change in local storage.
ARIA
- 🟢 While the editor is read-only, pressing Enter on the button toggles its state in the accessibility tree

Rationale

While we have done accessibility work before, it was mainly patching fairly glaring issues like the formatting toolbar being inaccessible via the keyboard. This PR is the start of a longer term commitment to improve a11y, and testing gives us a framework for figuring out where the main issues are and what still needs to be done.

Changes

N/A

Impact

N/A

Testing

See above.

Screenshots/Video

N/A

Checklist

Code follows the project's coding standards.
Unit tests covering the new feature have been added.
All existing tests pass.
The documentation has been updated to reflect the new feature

Additional Notes

We should enable the a11y oxlint rules, but that's out of scope for this PR.
Possible TODO: only Mantine skin is tested, should discuss whether we want to test the others in the future.

Summary by CodeRabbit

Tests
- Added automated accessibility coverage for keyboard navigation, focus behavior, text resizing and spacing, and formatting toolbar interactions.
- Added browser-based accessibility checks and screen-reader test support. Some test scenarios remain skipped.
Chores
- Accessibility tests run in CI, with reports and diagnostics available as downloadable artifacts.
Documentation
- Added guidance on accessibility concerns, testing requirements, and available tools.

vercel · 2026-10-09T16:38:54Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
blocknote	Ready	Preview	Nov 13, 2026 7:45pm UTC
blocknote-website	Ready	Preview	Nov 13, 2026 7:45pm UTC

coderabbitai · 2026-10-09T16:38:57Z

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Last reviewed commit: e7dd7ba
Latest commit, not reviewed: 7208742

Use the following commands to manage reviews:

@coderabbitai resume to resume automatic reviews.
@coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

▶️ Resume reviews
🔍 Trigger review

Walkthrough

This pull request adds accessibility-testing guidance, browser and screen-reader test infrastructure, and tests for editor and formatting-toolbar interactions. It adds project commands and a GitHub Actions workflow for browser accessibility tests.

Changes: Accessibility testing

Layer / File(s)	Summary
Accessibility concerns and test scope `a11y-study/*.md`	The documents describe concerns and testing methods for legibility, keyboard and focus behavior, and screen-reader output. They identify tools and note topics marked TODO or out of scope.
Test fixtures and shared helpers `tests/a11y/documents.ts`, `tests/a11y/helpers.tsx`, `tests/a11y/commands.ts`, `packages/react/src/editor/a11y/axe-documents.ts`, `packages/react/src/editor/a11y/helpers.ts`, `packages/react/src/components/FormattingToolbar/a11y/helpers.ts`	Fixtures cover default-schema content, varied block properties, inline content, colors, and tables. Helpers support editor setup, axe checks, keyboard navigation, text resizing, ARIA snapshots, and screen-reader transcripts.
Editor and toolbar accessibility coverage `packages/core/src/blocks/Heading/a11y/`, `packages/react/src/editor/a11y/`, `packages/react/src/components/FormattingToolbar/a11y/*`, `packages/core/tsconfig.json`, `packages/core/vite.config.ts`, `packages/react/tsconfig.json`, `packages/react/vite.config.ts`	Tests cover editor navigation and focus, text spacing and resizing, toggle headings, and toolbar interactions. Several tests are skipped. Package configurations exclude accessibility tests from standard TypeScript and Vitest inputs.
Test execution and CI `tests/a11y/*`, `tests/package.json`, `tsconfig.json`, `vite.config.ts`, `.github/workflows/a11y.yml`	The runner supports Docker browser tests and native screen-reader tests. Project tasks configure browser and screen-reader runs. The workflow runs browser accessibility tests and uploads reports and diagnostics.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Change: Other

Sequence Diagram(s)

sequenceDiagram
  participant GitHubActions
  participant Runner as tests/a11y/run.mjs
  participant ViteConfig as tests/a11y/vite.config.ts
  participant Playwright
  participant GuidePup
  GitHubActions->>Runner: Start browser accessibility tests
  Runner->>ViteConfig: Select mode and forward arguments
  ViteConfig->>Playwright: Configure and run browser tests
  Runner->>ViteConfig: Select native mode when --screen-reader is set
  ViteConfig->>GuidePup: Configure screen-reader test commands

Possibly related PRs

TypeCellOS/BlockNote#3248: Updates Vite Plus, Vitest, and the Playwright browser adapter used by the accessibility test configurations.

Merge Risk: Moderate · previous review e7dd7

This change adds an accessibility test suite and CI workflow. The root type check may fail because the new tests/a11y project is referenced without the settings TypeScript requires for a referenced project. A few guidance statements and one toolbar test also need tightening. These are fixable before merge and do not affect the shipped library code.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly identifies the main change: adding an accessibility testing setup.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Description check		The description follows the repository template. It has the Summary, Rationale, Changes, Impact, Testing, Screenshots/Video, Checklist, and Additional Notes sections. The Summary gives a clear scope. …

Full details: Description check

Explanation

The description follows the repository template. It has the Summary, Rationale, Changes, Impact, Testing, Screenshots/Video, Checklist, and Additional Notes sections. The Summary gives a clear scope. It lists the covered areas, the passing and failing tests, and the test approach. Some template sections are only partly filled. The Summary still has the template placeholder comment, and the Changes and Impact sections read N/A. The Testing section refers back to the Summary. The Checklist is unchecked. These gaps are minor, so the description is mostly complete.

Finishing Touches

Fix failing CI checks

Commit to this branch
Create a new PR

🧪 Generate unit tests (beta)

Commit to this branch
Create a new PR

Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

_{A rabbit checks the tab key’s flight
Through headings, menus, left and right
Axe and readers join the run
Snapshots note what has been done
CI carries tests along
The bunny thumps a testing song}

pkg-pr-new · 2026-10-09T16:43:27Z

Open in StackBlitz

@blocknote/ariakit

npm i https://pkg.pr.new/@blocknote/ariakit@3177

@blocknote/code-block

npm i https://pkg.pr.new/@blocknote/code-block@3177

@blocknote/core

npm i https://pkg.pr.new/@blocknote/core@3177

@blocknote/diagram-block

npm i https://pkg.pr.new/@blocknote/diagram-block@3177

@blocknote/mantine

npm i https://pkg.pr.new/@blocknote/mantine@3177

@blocknote/math-block

npm i https://pkg.pr.new/@blocknote/math-block@3177

@blocknote/react

npm i https://pkg.pr.new/@blocknote/react@3177

@blocknote/server-util

npm i https://pkg.pr.new/@blocknote/server-util@3177

@blocknote/shadcn

npm i https://pkg.pr.new/@blocknote/shadcn@3177

@blocknote/xl-ai

npm i https://pkg.pr.new/@blocknote/xl-ai@3177

@blocknote/xl-docx-exporter

npm i https://pkg.pr.new/@blocknote/xl-docx-exporter@3177

@blocknote/xl-email-exporter

npm i https://pkg.pr.new/@blocknote/xl-email-exporter@3177

@blocknote/xl-multi-column

npm i https://pkg.pr.new/@blocknote/xl-multi-column@3177

@blocknote/xl-odt-exporter

npm i https://pkg.pr.new/@blocknote/xl-odt-exporter@3177

@blocknote/xl-pdf-exporter

npm i https://pkg.pr.new/@blocknote/xl-pdf-exporter@3177

@blocknote/xl-typst-exporter

npm i https://pkg.pr.new/@blocknote/xl-typst-exporter@3177

commit: 7208742

github-actions · 2026-10-09T16:46:36Z

PR Preview Action v1.8.2
🚀 View preview at https://TypeCellOS.github.io/BlockNote/pr-preview/pr-3177/
Built to branch `gh-pages` at 2026-11-13 19:50 UTC. Preview will be ready when the GitHub Pages deployment is complete.

…e from check list items to toggle headings

YousefED · 2026-10-13T07:39:59Z

+  await expect.element(button).toHaveAttribute("aria-pressed", "true");
+});
+
+test("formatting toolbar: Italic", async () => {


This repeats the same for every button, which got me thinking we can go in two directions:

full: Accept that we want to test every user interaction like this. In that case, we might as well extend it to make sure the action (enter) does what's expected (make text bold). This concept would not turn it into an a11y specific test anymore, but sets a pattern where every component must have a complete browser test that covers functionality, a11y, etc. In this case, we should also think if mouse clicks should be handled as well

minimal: test this for 1 button or at the ToolbarButton level

I do wonder if we should have screenshots for all possible states though

I think it's worth having a discussion about this on call. Another solution could be to have even more granular, Storybook-esque UI testing, and test toolbar buttons/dropdowns/menus/etc in isolation. That would be a pretty major refactor though.

I believe we decided to keep a test for each button now that we have a clear distinction between the responsibilities of different tests, correct me if I'm wrong @YousefED

YousefED · 2026-10-13T08:15:54Z

+  }
+}
+
+test.describe("text spacing and resizing", () => {


Interesting! How did you find this? Are there similar cases that should be tested? Are there tools that can set these variants for us? (so we don't need to hand-roll these document changes)

I was literally browsing the WCAG 2.0 requirements one by one and stumbled across these. They were the only ones I found that were based on making sure that some external styles can be applied without issue, except animations but we can't really test those as they'd require smth like video snapshots.

YousefED · 2026-10-13T08:17:43Z

+    });
+  });
+
+  test("default schema remains readable at 200% text size", async () => {


can't we set this with playwright or sth else instead of hand-rolling this?

It's not that simple since each font in the editor has to be scaled by 200%, not just the base editor font size. So we have to go through each one and multiple the original size.

to be revisited

YousefED · 2026-10-13T08:31:55Z

+    )
+    .toBe(false);
+  const results = await axe.run(scope ? { include: [scope] } : document.body);
+  expect(results.violations, "axe violations").toEqual([]);


how will we go about this in practice? I assume this will report a lot? Are they all relevant? What's a good workflow that allows us to ship continuous improvements?

Honestly there aren't that many. We can skip the failing axe test files for now and start enabling each one separately after fixing all the issues for that component.

These are all reported violations:

Test Rule Severity Finding

Default schema aria-input-field-name Serious The editor’s textbox has no accessible name.

Default schema color-contrast Serious “Quoted text” has 4.29:1 contrast; requires 4.5:1.

Default schema label Critical Both check list checkboxes—checked and unchecked—lack accessible names.

Default schema target-size Serious Both checkboxes measure 12 × 24px, with insufficient surrounding space to satisfy the spacing exception.

Formatting toolbar: block type menu aria-required-children Critical The menu contains a Mantine autofocus div[tabindex="-1"] that axe flags as a disallowed child.

Formatting toolbar: colors menu aria-required-children Critical Same autofocus-element issue as the block type menu.

There is one incomplete finding requiring manual review:

Test Rule Finding

Default schema video-caption Check whether the video requires captions and whether suitable captions are available. Axe cannot determine this automatically.

The formatting toolbar itself and link popover report no violations or incomplete findings.

…tByTestId`

nperez0111

Overall, I think we are 95% the way there @matthewlipski just some minor cleanup and I need some clarification on the tests/a11y folder of files and I think we are good.

Please cleanup any files that you feel are no longer necessary to the PR

nperez0111 · 2026-11-11T17:37:22Z

+      }
+      .bn-editor p { margin-block-end: 2em !important; }
+    `);
+        await screenshotFull(document.body, "default-schema-text-spacing.png", {


I'm a little unsure what this screenshot test actually ends up proving or not

A11y tools can change text spacing/sizing and cause overflows that may not be covered by CSS, causing content to get cut off. E.g. we had a related issue to this with equation blocks initially, where we didn't realize that longer equations would get cut off and the block wasn't scrollable.

nperez0111 · 2026-11-11T17:37:33Z

+        await openEditor(defaultSchemaDocument);
+        await waitForMedia();
+        resizeText(2);
+        await screenshotFull(


YousefED

I think there's been a great cleanup and the organization into groups also really helps.

Left some inline comments, my main two questions are:

How would we test behavior and what's the current policy for this? (see my comment on the skill file
Some tests are 90% the same (tab to element), but test something slightly different. I assume this is a best practice, but let's quickly tradeoffs at standup

YousefED · 2026-11-11T18:39:05Z

+
+| Group      | Actions and assertions                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `behavior` | Navigate using the keyboard and activate with Enter. Assert the component's functional effect. For document edits, subscribe with `editor.onChange(vi.fn())` after navigation and before activation, register the unsubscribe with `onTestFinished`, and assert the callback ran. View-only changes may need another observable effect: toggle-heading tests check persisted expansion state. Keep detailed editor-command unit tests colocated with those commands rather than duplicating them here. |


so I understand correctly, this means that in the .browser.test.ts files we don't check that an action did the "correct" thing, but just that it did "something"?

I assume (also based on standup discussions) that "full behavior" tests are then out of scope for now, which is fair. But maybe we should do the thought exercise of where the full behavior tests would / should live if / when we'd invest in those. In the same file under a different group? would they replace the behavior group? Or, the philosophy is that we should always test them at a lower level?

Note from our discussion: full integration style tests would override the need for "behavior" tests in the case of the formatting toolbar, but there are cases for other UI elements where both test types are relevant. @nperez0111 will provide examples of this.

YousefED · 2026-11-11T18:48:34Z

+      await pressKey("Enter");
+      const menu = page.getByRole("menu");
+      await expect.element(menu).toBeVisible();
+      // Mantine initially focuses a placeholder before the first menu item.


do we agree to explicitly only test mantine now? ok to leave other skins out of scope, but maybe good to document this as possible follow up work later

Will add to PR description, though I don't think it's gonna make sense to worry about the other frameworks until we are really happy with Mantine, if at all.

YousefED · 2026-11-11T18:51:51Z

+
+exports[`ARIA > formatting toolbar: Align text center > after activation 1`] = `
+"- button "Align text center" [pressed]:
+  - img"


fyi (for later, once we do fixing). The best practice is to make the icons aria-hidden, right?

Yeah though it's very minor. The buttons already have accessible names so the images are ignored by screen readers in any testing I've done.

YousefED · 2026-11-11T18:53:06Z

+
+exports[`ARIA > formatting toolbar: Colors > before activation 1`] = `"- button "Colors": A"`;
+
+exports[`ARIA > formatting toolbar: Italic > after activation 1`] = `


nitpick? should we snapshot the entire toolbar, or just the button?

The test is for the entire FormattingToolbar, I think it might be more consistent to validate the a11y-tree of the entire component?

Logically that makes sense, practically I'd rather not do that since the snapshots are harder to check when all of them are 90% the same.

Initial a11y testing setup

35b14f2

matthewlipski requested a review from YousefED October 9, 2026 16:38

github-advanced-security Bot found potential problems Oct 9, 2026

View reviewed changes

Comment thread .github/workflows/a11y.yml Fixed

Comment thread .github/workflows/a11y.yml Fixed

matthewlipski added 4 commits October 12, 2026 18:36

Migrated from Playwright to Vitest Browser Mode

a974076

Small refactor

1fd7af8

Moved axe scans to separate test files

9dee776

Added read-only tests and moved interactive block tests vertical slic…

177e755

…e from check list items to toggle headings

vercel Bot deployed to Preview – blocknote October 12, 2026 18:45

View deployment

vercel Bot deployed to Preview – blocknote-website October 12, 2026 18:46

View deployment

YousefED reviewed Oct 13, 2026

View reviewed changes

matthewlipski added 5 commits October 13, 2026 16:12

Removed crypto.randomUUID calls and added lint rule to disallow `ge…

1de7a16

…tByTestId`

Made saveTranscript throw error when screenReader is not defined.

75e158a

Changed animation handling for axe scans

a6bafae

Rename spec -> test

66f1a48

Added @root shorthand

c92db4b

vercel Bot deployed to Preview – blocknote October 13, 2026 15:19

View deployment

vercel Bot deployed to Preview – blocknote-website October 13, 2026 15:20

View deployment

matthewlipski added 2 commits October 13, 2026 21:42

Cleanup

463e237

Implemented remaining PR feedback

7cf0798

vercel Bot deployed to Preview – blocknote-website October 13, 2026 20:03

View deployment

vercel Bot deployed to Preview – blocknote October 13, 2026 20:04

View deployment

Small axe changes

137f4d4

vercel Bot deployed to Preview – blocknote October 14, 2026 11:33

View deployment

vercel Bot deployed to Preview – blocknote-website October 14, 2026 11:34

View deployment

YousefED reviewed Oct 15, 2026

View reviewed changes

Comment thread packages/react/src/editor/a11y/helpers.ts Resolved

Comment thread packages/react/src/editor/a11y/helpers.ts Resolved

Comment thread tests/a11y/helpers.tsx Resolved

Comment thread tests/a11y/documents.ts Resolved

vercel Bot deployed to Preview – blocknote November 9, 2026 10:13

View deployment

vercel Bot deployed to Preview – blocknote-website November 9, 2026 10:14

View deployment

nperez0111 requested changes Nov 9, 2026

View reviewed changes

Implemented PR feedback

c8d90c3

vercel Bot deployed to Preview – blocknote November 9, 2026 13:29

View deployment

vercel Bot deployed to Preview – blocknote-website November 9, 2026 13:29

View deployment

Updated skill

2dc8bfc

vercel Bot deployed to Preview – blocknote November 9, 2026 18:34

View deployment

vercel Bot deployed to Preview – blocknote-website November 9, 2026 18:35

View deployment

Small fixes

c138511

vercel Bot deployed to Preview – blocknote November 9, 2026 20:24

View deployment

vercel Bot deployed to Preview – blocknote-website November 9, 2026 20:25

View deployment

Removed obsolete snapshots

354034c

vercel Bot deployed to Preview – blocknote November 9, 2026 20:35

View deployment

vercel Bot deployed to Preview – blocknote-website November 9, 2026 20:36

View deployment

nperez0111 reviewed Nov 11, 2026

View reviewed changes

YousefED reviewed Nov 11, 2026

View reviewed changes

coderabbitai Bot mentioned this pull request Nov 11, 2026

fix: Placeholder & side menu contrast (BLO-1243) #3338

Open

3 of 4 tasks

Refactored a11y test helpers

6c4be74

vercel Bot deployed to Preview – blocknote November 12, 2026 20:41

View deployment

vercel Bot deployed to Preview – blocknote-website November 12, 2026 20:42

View deployment

Fixed review feedback

48f95a6

vercel Bot deployed to Preview – blocknote November 12, 2026 21:00

View deployment

vercel Bot deployed to Preview – blocknote-website November 12, 2026 21:01

View deployment

Added lint rules for browser tests

852e1e7

vercel Bot deployed to Preview – blocknote November 13, 2026 18:38

View deployment

vercel Bot deployed to Preview – blocknote-website November 13, 2026 18:39

View deployment

Updated full document keyboard navigation test

c6337ef

vercel Bot deployed to Preview – blocknote November 13, 2026 19:11

View deployment

Added key press limit to tests in addition to time limit

7208742

Test	Rule	Severity	Finding
Default schema	`aria-input-field-name`	Serious	The editor’s `textbox` has no accessible name.
Default schema	`color-contrast`	Serious	“Quoted text” has 4.29:1 contrast; requires 4.5:1.
Default schema	`label`	Critical	Both check list checkboxes—checked and unchecked—lack accessible names.
Default schema	`target-size`	Serious	Both checkboxes measure 12 × 24px, with insufficient surrounding space to satisfy the spacing exception.
Formatting toolbar: block type menu	`aria-required-children`	Critical	The menu contains a Mantine autofocus `div[tabindex="-1"]` that axe flags as a disallowed child.
Formatting toolbar: colors menu	`aria-required-children`	Critical	Same autofocus-element issue as the block type menu.


		exports[`ARIA > formatting toolbar: Colors > before activation 1`] = `"- button "Colors": A"`;

		exports[`ARIA > formatting toolbar: Italic > after activation 1`] = `

Conversation

matthewlipski commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Editor Body

Formatting Toolbar

Toggle Heading

Rationale

Changes

Impact

Testing

Screenshots/Video

Checklist

Additional Notes

Summary by CodeRabbit

Uh oh!

vercel Bot commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

coderabbitai Bot commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviews paused

Sequence Diagram(s)

Uh oh!

Uh oh!

Uh oh!

pkg-pr-new Bot commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Built to branch gh-pages at 2026-11-13 19:50 UTC. Preview will be ready when the GitHub Pages deployment is complete.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nperez0111 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

matthewlipski commented Oct 9, 2026 •

edited

Loading

vercel Bot commented Oct 9, 2026 •

edited

Loading

coderabbitai Bot commented Oct 9, 2026 •

edited

Loading

pkg-pr-new Bot commented Oct 9, 2026 •

edited

Loading

github-actions Bot commented Oct 9, 2026 •

edited

Loading

Built to branch `gh-pages` at 2026-11-13 19:50 UTC.
Preview will be ready when the GitHub Pages deployment is complete.

matthewlipski Nov 12, 2026 •

edited

Loading