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">
	<form>
	…
	</form>
</div>

<form>
	<div role="search">
	…
	</div>
</form>

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.

Why?

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.

Background

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

Validating <form role="search"> -> "Warning: Element form does not need a role attribute". Wrong to indicate that it is “a search facility”?

— Roger Johansson (@rogerjohansson) August 19, 2015

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:

• role=search should be allowed on form elements #18 against ARIA in HTML;
• allow roles search and presentation on form element #193 against The Nu Html Checker;
• Found new error when validating with validator.w3.org #7291 against the Web Experience Toolkit (WET);
• Using the form’s role attribute #85 against Accessible Rich Internet Applications (WAI-ARIA);
• Incorrect ARIA Landmark Example (role=search) #113 against the Web Content Accessibility Guidelines (the bug I initially filed).

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.