Where to Put Your Search Role

I really spent far too much time re-thinking that title.

If you have a search form on your site and you want to be a good accessibility soldier and drop ARIA roles in for landmarks, then you may have wondered where to put role="search". If you’re like me (or many others) then you probably put it directly into the form element. Don’t.

These are the two legal (see below) options (which will also keep the HTML validator from yelling at you):

<div role="search">
	<div role="search">

Clearly you can use other elements instead of a div, and you can nest them in different ways, but what is important is that you do not put the role="search" on the form element.


A proper form already has the form role thanks to its own native semantics. Ignore this incorrect statement on that same page: For search facilities, authors SHOULD use the search role and not the generic form role.

Sorry for the whiplash I just caused there, but I want to make sure people aren’t reading the bad advice and assuming I missed it.

The reason you don’t want to override the native role is that the search role doesn’t replicate the form role, and therefore this matters:

Adding an ARIA role overrides the native role semantics in the accessibility tree which is reported via the accessibility API, and therefore ARIA indirectly affects what is reported to a screen reader or other assistive technology.

Also, doing this violates the second rule of ARIA use:

Do not change native semantics, unless you really have to.


Roger Johansson asked about the search ARIA role on Twitter today:

Which lead to a conversation (and spec link sharing) between him, Eric Eggert, and me.

Today if you go to the Techniques for WCAG 2.0 document, as any developer might when trying to make sure a site passes WCAG, there is a whole section dedicated to ARIA (here they are all on one page).

The technique for using ARIA landmarks has this example which has led to some confusion (I left out the HTML code sample to prevent poor copy-paste practices):

The following example shows a search form with a “search” landmark. The search role typically goes on the form field or a div surrounding the search form.

With guidance and explanations over at the Gitter a11ySlackers channel (thanks to Léonie Watson, Mark Sadecki, and Eric Eggert), I filed a bug against this example, which quickly got some more detail from Léonie:

What real-world impact this has on current ATs is unknown, but my hunch is that it’s minimal. We can’t know what impact it might have as more ATs support ARIA though (obviously).

Arguably a WCAG technique shouldn’t recommend a practice that is generally problematic though.

Can of Worms

In the Gitter chat and on Twitter a few people (including me) wondered aloud why an item cannot accept two roles — such as one landmark role and one widget role. The risk, of course, is that invariably roles have functional overlaps and there is no good way for a browser nor AT to tease out which one in conflict should win.

Update: August 20, 2015

The Gitter a11ySlackers archive from yesterday‘s chat is online now. You can follow along starting at item 20 (sorry, no anchor to link).

Eric Eggert (yatil) also opened an issue against the ARIA spec yesterday: Using the form’s role attribute #85

Update: September 23, 2015

I was testing use of SVG icon sprites on my site and made a CodePen that just happens to show the role="search" on something other than the <form> (and uses placeholder text with sufficient contrast per Karl Groves):

See the Pen Search Box by Adrian Roselli (@aardrian) on CodePen.

Update: December 16, 2015

As of this morning it appears there is agreement that the prohibition against role="search" on <form> elements has been lifted. It is discussed in the following bug reports:

Please note that the HTML specification is not updated to reflect this yet and the Nu HTML validator does not reflect the change yet either (see above for the change request). If you submit anything with <form role="search"> to the validator it will generate an error.

Update: March 24, 2023

As of yesterday, the <search> has been added to the WHATWG HTML specification. This closes the 2020 issue #5811 Consider creating an HTML search element, originally opened by Carolyn MacLeod (who I and the industry misses).

This does not mean support will come immediately. Read Scott O’Hara’s post, The search element, to understand the broader context.



[…] Where to Put Your Search Role – by Adrian Roselli. TL;DR, not on a <form> element, as that overrides its native semantics […]


[…] div in the form is simply a container for role="search", because it is not allowed on the form itself (updated as of 12/16/15, this prohibition will be changing in the specs and validator […]


Those updates should go at the top of the post, since the latest update largely invalidates any arguments made, if I’m reading it correctly.

Rene; . Permalink
In response to Rene. Reply

I kinda thought the second sentence of the post was sufficient warning. But fair point not all will catch it.

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>