Maybe Ignore type=search

Another case of the headline saying it all.

If you have a valid, accessible search field (with a useful, sensible label) then you can probably ignore type="search" and use type="text" instead.

I made a code sample you can use for testing in your preferred set-up; it is what I used to perform the tests documented below. You can get to the debug view on CodePen which is free of all the cruft.

See the Pen Input Type Text v. Search by Adrian Roselli (@aardrian) on CodePen.

How Browsers Expose type="search"

Mostly they do not.

Default Styles

Oh, sorry, there actually are some Very Important™ styling decisions.

Chrome adds 1 pixel of padding to the left and right of the search field and on macOS also gives it rounded corners. Safari on macOS also does rounded corners and makes it almost 30 pixels wider. Safari on iOS gives the search field rounded corners.

But you are likely not using those fields unstyled and are overriding all that anyway.

Programmatically

Other than passing along the type, they do nothing. See the screenshots of the accessibility inspectors of various browsers at the end of this post.

Mobile

Scott Vinkle reminded me that on mobile the keyboard changes a bit. On Android it goes from an arrow to a magnifying glass. On iOS it changes from a “Go” button to “Search”. I added screen shots at the way end of this post showing the visual distinction.

Delete Option

Both Rhy Moore and Eric Eggert pointed out that the field gets an in-built delete control. Which it does. Sometimes.

Adam Silver pointed out that in those cases, users can press Esc to clear the field. Which is also sometimes true.

Windows 10 / Edge
type="search": Gets a delete control, cannot be activated via keyboard, is not announced by a screen reader.
type="text": Gets a delete control, cannot be activated via keyboard, is not announced by a screen reader.
Windows 10 / Firefox
type="search": Gets no delete control.
type="text": Gets no delete control.
Windows 10 / Chrome
type="search": Gets a delete control, cannot be activated via keyboard, is not announced by a screen reader, supports Esc.
type="text": Gets no delete control.
Windows 10 / IE11
type="search": Gets a delete control, cannot be activated via keyboard, is not announced by a screen reader, supports Esc.
type="text": Gets a delete control, cannot be activated via keyboard, is not announced by a screen reader, supports Esc.
macOS / Chrome
type="search": Gets a delete control, cannot be activated via keyboard, is not announced by VoiceOver, supports Esc.
type="text": Gets no delete control.
macOS / Safari
type="search": Gets a delete control, cannot be activated via keyboard, is not announced by VoiceOver, supports Esc.
type="text": Gets no delete control.
Android / Chrome
type="search": Gets a delete control, cannot be activated via keyboard, is not announced by TalkBack, supports Esc.
type="text": Gets no delete control.
Android / Firefox
type="search": Gets no delete control.
type="text": Gets no delete control.
iOS / Safari
type="search": Gets no delete control.
type="text": Gets no delete control.

Of 9 browsers tested, six get a delete control and two of those also get a delete control on type="text". That means 4 of them get a delete control from type="search".

Since screen readers do not announce this delete control (when it appears) and it can seemingly only be activated by pointer (I could not get it work in Voice Control), I don’t find it a compelling reason to use type="search". This does not even address target size, contrast, nor lack of accessible name.

While the Esc support is awesome, it is also not announced to users and likely unknown by all but power users, trained users, or possibly keyboard mashing.

Also note that some NVDA and JAWS users have been observed (this is anecdotal) quickly exiting forms or application mode by pressing Esc. So there is also a chance of an unintended search field clearing.

ARIA Mapping

An <input type="search"> maps to the searchbox role. Here is the entirety of its definition in the ARIA 1.1 spec (it is unchanged in ARIA 1.2 Working Draft):

A type of textbox intended for specifying search criteria. See related textbox and search.

As you can see, it does not mandate any special consideration (let alone warrant it).

What Screen Readers Do

We know that screen readers can take information from the DOM and ignore or override what the browser passes along in the accessibility API if it means a better experience for its users.

Control

There is no special command to jump to a search field.

Announcement

With two exceptions (VoiceOver with Safari on macOS and iOS), both fields announce the same as one another across screen readers. Even with the different announcement in Safari, <input type="search"> does not behave differently from <input type="text">.

Note that in all cases, the <label> is where the announced search comes from. That still happens in the exceptions, making the announcement redundant.

Windows 10 / Narrator / Edge
type="search": Search, editing, scan off, editing.
type="text": Search, editing, scan off, editing.
Windows 10 / NVDA / Firefox
type="search": Search edit has auto complete.
type="text": Search edit has auto complete.
Windows 10 / NVDA / Chrome
type="search": Search edit blank.
type="text": Search edit blank.
Windows 10 / NVDA / IE11
type="search": Search edit blank.
type="text": Search edit blank.
Windows 10 / JAWS / IE11
type="search": Region search edit type of text.
type="text": Region search edit type of text.
Windows 10 / JAWS / Chrome
type="search": Search edit type of text.
type="text": Search edit type of text.
Windows 10 / JAWS / Firefox
type="search": Search edit type of text.
type="text": Search edit type of text.
macOS / VoiceOver / Chrome
type="search": Search edit text search.
type="text": Search edit text search.
macOS / VoiceOver / Safari
type="search": Search edit text.
type="text": Search text field blank, search.
Android / TalkBack / Chrome
type="search": Edit box search.
type="text": Edit box search.
Android / TalkBack / Firefox
type="search": Entry search.
type="text": Entry search.
iOS / VoiceOver / Safari
type="search": Search, text field.
type="text": Search, search field.

Conclusion

Generally you need not bother with <input type="search">. It offers little to no benefit. Use <input type="text"> instead.

If your label (however you provide the accessible name) and/or submit button also use the word “search” then probably do not use <input type="search">.

If the entire search form is also in a role="search" landmark then almost definitely do not use <input type="search">.

If you have a novel corner case (multiple searches on the page, a Dragon bug I do not know, etc.), then please leave a comment. There’s no use letting me be wrong.

For all these reasons I avoided the type="search" in my 2015 post Responsive Progressive Accessible Vanilla Search and it has not proved to be an issue in nearly four years.

Dev Tools Screens

The following screen shots show what the browser’s accessibility inspector in the dev tools exposes for the text field (first image) and the search field (second image).

Edge on Windows 10.
Firefox on Windows 10.
Chrome on Windows 10.
Safari on macOS.
Chrome on macOS.

Mobile Keyboard

The following screen shots show the mobile keyboard for the text field (first image) and the search field (second image).

Android.
iOS.

Update: enterkeyhint

8 November 2021: I added the enterkeyhint attribute to the search box on this site, giving it the value of search. Doing so gives me the same search icon for the enter key on Chrome and Firefox on Android, and Safari on iOS and iPadOS.

Update: 23 September 2023

This update is only tangentially related to the post, but I felt it worth memorializing here rather than just on the socials.

A dev excitedly told me about the <search> element, citing WebKit Features in Safari 17.0. While I watched its minting in the spec, this statement in the Safari post stood out:

[…] Without the ARIA search role, search functionality is not made properly accessible to all users — a problem that’s far too easy to create. […] We are excited to be the first browser to ship this new <search> element, now supported in Safari 17.0.

I made a demo showing what it really means for users — noting it impacts screen reader users only.

My demo loaded in Safari with the VoiceOver rotor showing all the landmarks on the page — search being one of them, which I circled in red.

It is indeed swell that Safari flipped a bit to take its existing support for the ARIA search role and apply it to this element, but maybe not worth the level of exhortation in that post. I found no similar excitement for the ARIA search role in prior Apple posts.

If that is not clear, the search role (and now the <search> element in Safari TP 179) allows screen reader (VoiceOver) users to navigate to a search form as a landmark. Handy when a search form is buried or not already in a banner or navigation landmark. Not a show stopper in most cases, though.

Still, very glad to see Apple Safari committing to standards (unlike CSS display properties) — particularly well-established ones with long histories (as opposed to, say, popovers, Chrome).

12 Comments

Reply

I appreciate that you did the legwork in testing all these configurations. I’m not sure I agree with your conclusion.

You show that type=search has no current benefit over type=text, but you don’t seem to claim that it is any worse than type=text.

But using type=search does provide an opportunity for future innovation. When I was doing standards at W3C, it was a very common consideration for spec writers to look at whether and how a feature was being used. Unused features faced deprecation. Often, if web authors were using a pattern, even if it didn’t result in different browser behavior, spec authors would “pave the cowpaths”, and specify particular browser behavior. There’s no guarantee that it would happen in this case, but if people don’t use type=search, it certainly never will.

So, I guess I’m suggesting that we optimistically use type=search to encourage the browsers or screenreaders to innovate with it.

In response to Doug Schepers. Reply

Doug, your cowpaths argument is a great argument. I do not disagree with it. I did not evaluate how much it is used in the wild, nor did I look at signals from browsers that they might do more with it. Right now it is under-defined. It might be worth thinking about (as a community) what else it can offer to users, because today it is little to nothing.

Reply

type="search" also changes its autocompletion behavior, which I think was its original reason for being.

That said, it was unilaterally proposed by WebKit a long, long time ago — I can’t find the original blog post on the WK blog for some reason, but I swear it exists.

In response to Taylor Hunt. Reply

Taylor, I do not doubt you that it exists. I would love to see it if you find it.

Reply

Either I’m missing something or this is a lousy reason to ignore the spec. The accessibility benefits of the search type aren’t great, so it should be ignored? The mobile UI benefit is solid and there are no apparent negatives to using this type.

Using the type correctly offers minor benefits now and sets you up for additional benefits as platforms improve support. Better to encourage platforms to improve a11y reading of the attribute than to encourage devs to ignore parts of the HTML specification.

In response to Alex. Reply

You claim the mobile UI benefit is solid, but I disagree. On iOS and Android, the biggest difference is the submit button changes (arrow to magnifying glass on Android, “Go” to “Search” on iOS). It does not even get bigger. While Android supports Esc to clear the field, this is not exposed to users and can be problematic when not expected.

Doug’s argument above echoes your second argument. See my response to him.

Reply

It doesn’t behave super different so we can ignore it you say, but… why? Why ignore it and type “text” instead of search? How are we making anything worse? We’re just making it so that when a future browser innovates on the search type, our old websites’ code don’t benefit.

By your logic, let’s ignore HTML5 semantic tags like article, section, footer and just use div. What’s the difference?

Craig S; . Permalink
In response to Craig S. Reply

Your argument echoes Doug’s above. See my response to him.

As for your assertion about my logic behind it, that is demonstrably wrong (and a false equivalency). Above I show how type="search" offers little to no benefit today. The elements you cite have tangible benefits that are exposed to AT and which I write about extensively on this site.

Reply

I understand your concern that it’s not doing enough… yet. But for me, the fact that the mobile keyboard adapts like that it enough of a benefit to use it.

For the pitfalls and use cases not covered: I’d be covering them anyway when using a type=”text”.

It’s a net gain in the user experience ¯\ _ (ツ) _ /¯

Reply

I didn’t realize that the Esc key was causing the input to be cleared. I just stumbled upon this because we use Inputs in our Modal windows. And, we also use Esc to close our modal windows. The behavior of these two things together was causing an undesired behavior because clearing the search-input was causing “filtering” in the modal window content to change just as the modal window was closing. This was jarring. As such, I switched to type="text" to prevent the momentary flash of changing content.

I had originally switched to the “search” type to avoid auto-completing. But, I’m just hoping that autocomplete="off" will be sufficient.

Reply

Appreciate your thorough overview and work you did in publishing this article. For those of us where WCAG compliance is mandatory, the search clear button (an “x” icon populated in the right portion of any element by Chrome and other browsers) is useful to visual/mouse users but inaccessible to reader/keyboard users. This alone is a strong reason for me to always use until the browsers can universally support this in an accessible way.

Grant Arnold; . Permalink
In response to Grant Arnold. Reply

Grant, since I wrote this the version of Edge that I used for testing (in the Delete Option section) has been replaced by a version with a Chromium engine. That means for each instance of <input type="search"> that receives a delete control in modern browsers, the delete operation can be operated by the keyboard (by pressing Esc). That satisfies 2.1.1. Other concerns about discoverability still apply of course.

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>