Search block: Render in the semantic <search> element

[adamsilverstein]

What

Render the core/search block in the native HTML <search> landmark element instead of <form role="search">.

<!-- Before -->
<form role="search" class="wp-block-search ..." ...>…</form>

<!-- After -->
<search class="wp-block-search ..." ...>
  <form method="get" action="...">…</form>
</search>

Why

<search> is now Baseline (Chrome 118+, Firefox 118+, Safari 17+, Edge 118+) and has an implicit ARIA landmark role of search. Using it expresses the search landmark with native semantics rather than a manual role attribute.

The role="search" attribute is dropped from the <form> because keeping it alongside the <search> wrapper would produce nested search landmarks, which assistive technology may announce twice or report as a structural error.

Implementation notes

The block wrapper attributes (get_block_wrapper_attributes()) and Interactivity API directives are applied to the new <search> element, making it the styled block root. This is important for correctness:

• Alignment (alignwide / alignfull) and constrained-layout centering only apply when the alignment class is on the layout container's direct child. Leaving the wrapper attributes on the inner <form> would break wide/full alignment.
• The HTML anchor and spacing/border/color block supports also belong on the outermost element.
• The expandable-searchfield state class wp-block-search__searchfield-hidden is toggled by a data-wp-class--* directive and is matched by the compound selector .wp-block-search.wp-block-search__button-only.wp-block-search__searchfield-hidden. Because the directives move to <search> together with the block classes, all three classes stay on the same element and the selector keeps matching.
• Internal flex layout is unaffected: it targets descendant wp-block-search__inside-wrapper / wp-block-search__input classes, which remain reachable through the extra <form> layer.

The Interactivity handlers (handleSearchKeydown, handleSearchFocusout) operate on the directive's element (getElement().ref) using ref.querySelector(...) / ref.contains(...); since <search> now hosts the region and contains the whole form, these continue to work.

The editor (edit.js) root is intentionally left as <div { ...blockProps }>. This is a dynamic (server-rendered) block with no save.js, so the editor DOM does not need to match the rendered output, and editor alignment already works via blockProps on that outer <div>. Adding a <search> landmark inside the editor canvas is out of scope.

WordPress Core

The Core-maintained get_search_form() function and the bundled classic-theme searchform.php templates get the same treatment in wordpress-develop#11913. This block change flows into Core via the regular block package sync. A Trac ticket tracks the overall effort.

Testing instructions

1. Add a Search block to a post/page (try each button position: inside, outside, button-only/expandable, no-button).
2. View on the front end and inspect the markup: the block should render as <search class="wp-block-search …"><form method="get">…</form></search> with no role="search".
3. Set the block alignment to Wide and Full; confirm alignment still works on the front end.
4. Set an HTML anchor and block spacing; confirm both are applied to the <search> element.
5. For the button-only (expandable) variation, confirm the expand/collapse interaction and Escape-to-close still work.
6. With a screen reader, confirm a single "search" landmark is announced per block.

Accessibility

• Native search landmark via <search>; no more manual role="search".
• No nested landmarks.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

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: adamsilverstein <adamsilverstein@git.wordpress.org>
Co-authored-by: westonruter <westonruter@git.wordpress.org>

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

[westonruter]

Per WordPress/wordpress-develop#11913 (comment):

I'd be concerned about breaking sites using CSS selectors like header > form[role="search"].

Themes using the form[role="search"] selector: https://veloria.dev/search/9e01303f-ef26-4607-9ea5-39ea2097710f

[github-actions]

Flaky tests detected in 1797583.
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.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/26200391361
📝 Reported issues:

• [Flaky Test] Navigates the items list via UP/DOWN arrow keys #64334 in /test/e2e/specs/site-editor/dataviews-list-layout-keyboard.spec.js