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 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
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:
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):
Update: December 16, 2015
As of this morning it appears there is agreement that the prohibition against
<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.
[…] 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.
I kinda thought the second sentence of the post was sufficient warning. But fair point not all will catch it.