Delete your role="search" wrapper

An HTML element for the region that holds your search box. It maps to the same search landmark the role attribute gave you, so screen reader users can jump straight to it without you writing any ARIA.

Delete: the role="search" attribute, and usually the <div> it sits on.

−<!-- a div doing an element's job -->
−<div role="search">
−  <form action="/search">…</form>
−</div>

+<search>
+  <form action="/search">…</form>
+</search>

One thing to style yourself. Browsers that know the tag give it display: block in the user agent stylesheet. A browser too old to know it gives it nothing, and the initial value of display is inline. If old browsers matter to you, declare search { display: block } yourself: one line, inert wherever the browser already does it. Beyond that, failure is graceful. The contents render everywhere, and an old browser loses the landmark, not the page.

A note on the numbers: the summary scoreboard currently shows Safari at zero on this feature. That zero comes down to one missing line in Safari’s stylesheet. Only two tests are scored here, both checking the element’s default styles, and Safari fails one check in each: it does not give <search> the unicode-bidi: isolate the spec asks for. The role-mapping suite passes whole. So the landmark works and the layout is fine. What you lose is bidi isolation, which matters if you put text of mixed direction inside the element.

Hand it a background color and it returns white or black, whichever contrasts more. New this month, April 10, 2026. The deletion it promises is every hand-maintained pair of background and text custom properties.

.badge {
  background: var(--accent);
  color: contrast-color(var(--accent));
}

/* Which of white or black wins on a mid-tone
   background is the browser's call, not yours. */

The label is running ahead of the paperwork. The function’s spec is an editor’s draft that still carries the banner “This spec is not yet ready for implementation”, and in the only form browsers ship, with no target contrast stated, the spec leaves the choice of contrast algorithm to the browser. Two engines can legitimately disagree about which of white or black a mid-tone background gets. The tests show real disagreements: Firefox’s current stable run fails both cases where contrast-color() takes container units inside calc(), and Safari’s fails to repaint a gradient whose color stop uses contrast-color(currentColor). One more thing the name does not say: it maximizes contrast, it guarantees none. Against a mid-gray background the winner clears no bar, it just loses less. For now, picking the text color yourself is the only way to know what it will be.