[ciampo]

Closes #50877.

What?

Give palette picker popups an accessible name and screen-reader-only dismissal controls while preserving live editing.

Why?

Screen reader users need to know which preset they are editing and have a way to dismiss the popup without an Escape key, including when using a touch screen.

The chosen resolution for #50877 preserves the established live-edit model: Escape dismisses the picker and retains edits. A separate screen-reader action provides another way to close it.

How?

Add a named dialog and visually hidden Close buttons at the start and end of its contents, following React Aria's color picker. The buttons stay outside the normal Tab sequence. The shared popup covers colors, gradients, and duotones in both palette views.

Edits remain live. Escape, outside clicks, and the hidden Close buttons retain the edited value. The visible interface and Enter behavior stay unchanged.

Testing Instructions

1. Open the Site Editor, then Styles → Colors → Edit palette.
2. With a screen reader, open a preset and confirm the popup is announced as a dialog named after that preset.
3. Change its value and confirm the palette updates while the popup remains open. Navigate to a Close button with the screen reader and activate it. Confirm the popup closes, focus returns to the swatch, and reopening shows the edited value.
4. Repeat from Color options → Show details, and with gradient and duotone presets.

Testing Instructions for Keyboard

1. Focus a palette swatch and press Enter to open its picker.
2. Tab through the picker. Confirm the visually hidden Close buttons do not add Tab stops.
3. Edit a value and press Escape. Confirm the picker closes, focus returns to the swatch, and the edit is retained.
4. Reopen the picker and press Enter in a value field. Confirm the picker remains open, as on trunk.

Use of AI Tools

Codex implemented the accessibility changes and regression tests, and drafted this description.

[github-actions]

🤖 PR meta 🤖

🎉 Props

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>
Co-authored-by: afercia <afercia@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Updated as activity occurs, without notifying anyone named here. Add the props-bot label to refresh.

📦 Bundle size

Size Change: +57 B (0%)

Total Size: 8.58 MB

📦 View Changed

Filename	Size	Change
build/scripts/components/index.min.js	352 kB	+57 B (+0.02%)

_{b7e84b0 Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	209fb4f	trunk	% Change
timeToFirstByte	53.1 ms +3.67% -2.64%	54.45 ms +11.66% -3.4%	-2.48%
largestContentfulPaint	92 ms +4.35% -4.35%	94 ms +4.26% -6.38%	-2.13%
lcpMinusTtfb	37.5 ms +12.53% -7.6%	34.5 ms +24.35% -3.62%	8.7%
wpBeforeTemplate	28.2 ms +7.77% -0.89%	28.49 ms +19.83% -2.04%	-1.02%
wpTemplate	20.99 ms +3.76% -4.43%	21.33 ms +6.47% -4.13%	-1.59%
wpTotal	49.46 ms +4.12% -3.01%	50.88 ms +10.57% -4.01%	-2.79%
wpMemoryUsage	7.61 MB +0% -0%	7.58 MB +0% -0%	0.46%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	209fb4f	trunk	% Change
timeToFirstByte	44.75 ms +7.04% -1.12%	45.1 ms +7.32% -0.89%	-0.78%
largestContentfulPaint	100 ms +2% -0%	100 ms +4% -0%	0%
lcpMinusTtfb	55.4 ms +0.9% -3.07%	55.2 ms +1.81% -2.36%	0.36%
wpBeforeTemplate	25.8 ms +6.51% -0.74%	26.21 ms +6.22% -1.37%	-1.56%
wpTemplate	15.74 ms +4.07% -1.59%	15.83 ms +1.58% -1.64%	-0.57%
wpTotal	41.68 ms +7.32% -0.86%	42.11 ms +7.77% -0.97%	-1.02%
wpMemoryUsage	6.25 MB +0% -0%	6.21 MB +0% -0%	0.71%
wpDbQueries	14 +0% -0%	14 +0% -0%	0%

media-processing

Metric	209fb4f	trunk	% Change
mediaProcessingJpeg	399.86 ms +0.13% -0.04%	396.72 ms +0.8% -0.6%	0.79%
mediaProcessingAvif	6026.11 ms +0.19% -0.08%	6028.88 ms +0.04% -0.23%	-0.05%
mediaProcessingJpegToAvif	4162.79 ms +0.03% -0.22%	4166.51 ms +0.03% -0.41%	-0.09%

media-upload

Metric	209fb4f	trunk	% Change
jpegUploadProcessing	1416.45 ms +36.73% -0.58%	1418.42 ms +0.85% -0.16%	-0.14%
pngUploadProcessing	178.38 ms +17.38% -3.37%	191.32 ms +14.41% -7.73%	-6.76%
largeJpegUploadProcessing	1405.4 ms +0.2% -0.34%	1400.27 ms +0.45% -0.4%	0.37%
multipleImageUploadProcessing	1554.25 ms +1.34% -0.85%	1589.62 ms +0.14% -2.54%	-2.23%

post-editor

Metric	209fb4f	trunk	% Change
serverResponse	410.73 ms +8.29% -4.12%	398.88 ms +3.28% -4.91%	2.97%
firstPaint	270.85 ms +75% -15.49%	353.77 ms +30.19% -37.28%	-23.44%
domContentLoaded	1088.75 ms +3.9% -2.75%	1038.01 ms +1.92% -1.66%	4.89%
loaded	1090.05 ms +3.87% -2.74%	1039.05 ms +1.94% -1.64%	4.91%
firstContentfulPaint	478.93 ms +3.69% -1.03%	464.42 ms +1.45% -0.83%	3.12%
firstBlock	3145.11 ms +1.25% -1.22%	2977.24 ms +0.58% -1.62%	5.64%
type	17.04 ms +8.1% -3.87%	17.27 ms +1.8% -3.07%	-1.33%
typeWithoutInspector	17.74 ms +0.56% -3.04%	16.88 ms +3.73% -0.77%	5.09%
typeWithTopToolbar	22.21 ms +5.76% -3.06%	22.44 ms +3.88% -6.33%	-1.02%
typeContainer	8.41 ms +10.7% -5.83%	8.47 ms +7.44% -6.26%	-0.71%
focus	104.52 ms +6.34% -1.71%	104.46 ms +2.87% -4.3%	0.06%
firstFocus	205.78 ms +0% -0%	222.1 ms +0% -0%	-7.35%
selectAll	421.8 ms +6.2% -2.25%	419.96 ms +9.81% -0.47%	0.44%
listViewOpen	69.03 ms +9.34% -3.36%	67.1 ms +8.51% -5.96%	2.88%
inserterOpen	37.55 ms +10.12% -4.15%	36.69 ms +10.22% -4.88%	2.34%
inserterHover	11.62 ms +8.61% -4.04%	11.8 ms +10.68% -8.81%	-1.53%
inserterSearch	8.8 ms +3.18% -3.41%	8.57 ms +8.98% -6.88%	2.68%
loadPatterns	618.22 ms +3.08% -3.92%	629 ms +2.86% -1.15%	-1.71%
wpTotal	398.82 ms +8.19% -4.09%	386.81 ms +3.39% -4.97%	3.1%
wpMemoryUsage	13.34 MB +0% -0%	13.31 MB +0% -0%	0.28%
wpDbQueries	54 +0% -1.85%	53 +1.89% -0%	1.89%

site-editor

Metric	209fb4f	trunk	% Change
serverResponse	421.05 ms +0.96% -2.95%	419.28 ms +1.47% -5.61%	0.42%
firstPaint	258.47 ms +79.94% -19.37%	246.06 ms +21.98% -14.22%	5.04%
domContentLoaded	1135.04 ms +1.35% -2.25%	1166.89 ms +1.66% -1.47%	-2.73%
loaded	1136.27 ms +1.33% -2.24%	1168.05 ms +1.66% -1.47%	-2.72%
firstContentfulPaint	469.12 ms +2.41% -0.71%	483.15 ms +2.74% -2.57%	-2.9%
firstBlock	4231.38 ms +1.7% -0.31%	4323.1 ms +0.93% -0.87%	-2.12%
type	17.55 ms +4.62% -4.05%	17.58 ms +3.01% -2.73%	-0.17%
navigate	117.7 ms +10.08% -5.75%	115.14 ms +5.26% -1.26%	2.22%
loadPatterns	1260.99 ms +5.24% -7.03%	1235.57 ms +2.71% -11.04%	2.06%
loadPages	991.44 ms +4.44% -0.73%	975.17 ms +2.05% -0.31%	1.67%
wpTotal	410.14 ms +0.93% -3.05%	408.14 ms +1.55% -5.8%	0.49%
wpMemoryUsage	12.37 MB +0% -0%	12.36 MB +0% -0%	0.13%
wpDbQueries	43 +2.33% -0%	43 +2.33% -0%	0%

_{b7e84b0 Run}

🏁 Flaky tests

Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

pushes earlier threads above the canvas to keep the selected one aligned in /test/e2e/specs/editor/various/block-notes-floating.spec.js, passed after 1 failed attempt.

Error: expect(locator).toBeVisible() failed

Locator: getByRole('region', { name: /^(Notes|Editor settings)$/ }).getByRole('treeitem', { name: 'Note: Two: Comprehensive considerations regarding extraordinarily sophisticated implementation characteristics notwithstanding.' })
Expected: visible
Timeout: 5000ms
Error: element(s) not found

Call log:
  - Expect "toBeVisible" getByRole('region', { name: /^(Notes|Editor settings)$/ }).getByRole('treeitem', { name: 'Note: Two: Comprehensive considerations regarding extraordinarily sophisticated implementation characteristics notwithstanding.' }) with timeout 5000ms
  - waiting for getByRole('region', { name: /^(Notes|Editor settings)$/ }).getByRole('treeitem', { name: 'Note: Two: Comprehensive considerations regarding extraordinarily sophisticated implementation characteristics notwithstanding.' })

    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/various/block-notes-floating.spec.js:551:4

should cut and paste individual blocks with collapsed selection in /test/e2e/specs/editor/various/copy-cut-paste.spec.js, passed after 1 failed attempt.

Error: expect(string).toMatchSnapshot(expected) failed

  @@ -1,3 +1,3 @@
   <!-- wp:paragraph -->
  -<p>2Cut - collapsed selection</p>
  +<p>2</p>
   <!-- /wp:paragraph -->


    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/various/copy-cut-paste.spec.js:45:49

_{b7e84b0 Run}

[mirka]

I'm not sure we can do this without making this a modal dialog with explicit save and cancel buttons.

1. Nothing implies that the edits are temporary and contained within the popup. The edited values are updated outside of popup in real time. That looks like the edits are not contained to the popup, and are already being persisted outside of it. Maybe not persisted permanently, but at least to somewhere outside of the popup.
2. I can make changes without touching the input fields at all (grabber handles). A user would not know that they need to go to a input field and press enter.
3. Hitting escape cancels, but clicking outside of the popup doesn't. That doesn't match normal expectations.

To me, the trunk behavior is at least consistent in the sense that keyboard interaction matches pointer interaction. Values are persisted automatically, so closing the popup doesn't revert your changes. If you want cancel to abort, you need to change the entire interaction so the pointer interaction matches that model.

[ciampo]

IMO, adding explicit buttons would add (too much) friction to the color-picking UX.

I took a look at what other color pickers do, and they generally don't show cancel/confirm buttons; most just work as our current trunk, ie. pressing escape closes the popup, but doesn't reset the value (Polaris, React Aria, Chakra, Ark UI).

The only exception seems to be the HTML native color input: when pressing Esc, it resets the value but keeps the picker open. Pressing Esc again closes the popup.

I'd like to adopt one of these two models, WDYT ?

[mirka]

I'd like to adopt one of these two models, WDYT ?

The first model being the behavior on current trunk, right? Personally, I don't think there's any problem with the current trunk behavior. Do you?

[ciampo]

Yeah, based on those examplesx I agree with keeping trunk's live-edit behavior, so I've repurposed the PR to preserve it.

It now only adds a named picker dialog and screen-reader-only Close controls, following React Aria's color picker, without changing the visible UI, normal Tab sequence, or what happens to edits when the popup closes.

[mirka]

Seems reasonable now 👍