Consider creating an HTML search element

[carmacleod]

All of the ARIA landmark roles (banner, complementary, contentinfo, form, main, navigation, region)
have a corresponding HTML element (header, aside, footer, form, main, nav, section)
whose implied role is a landmark role... except for the search role.

Consider creating an element called "search" that will have an implied search landmark role, i.e. it would have the same semantics as <div role="search">.

The intent of creating this element is to allow user agents to include <search> in landmark navigation, so that users could navigate quickly to the search facility for the document. User agents should not have to rely on the presence of ARIA role markup (such as role="search") in order to decide whether to include an element in landmark navigation.

Note that this is not the same as a search input (which has an implied role of searchbox). The search landmark can be thought of as a container for search-related controls, i.e. a search landmark could contain an input with type="search".

[bathos]

I didn't know a specific role for this existed; it never occurred to me that there might be extra landmarks. Pretty much every app I've worked on has had a search filters bar/sidebar/panel and apparently I've never marked them up correctly. If there were an element for it, I suspect I would have discovered this sooner.

[domenic]

Hey @carmacleod, we discussed this in the triage meeting (#6936) and there was general agreement (including from implementers in Gecko and Chromium) that this is a good idea.

However, we worried a bit about the name. <search> sounded too much like a search input, not a search landmark. I.e. it sounds like a widget that would do a search.

This isn't the biggest deal; authors can always read the docs and figure it out. But I think it would be a shame if we introduced a new feature and then immediately had to add to the docs: "You may be looking for <input type="search"> instead."

Can you (or others) help us think of ideas for alternate names that might avoid that pitfall?

[scottaohara]

FYI: I've discussed the following with @carmacleod

Would something like one of the following names be of help here: "searcharea", "searchform", "searchgroup" or "searchset"? (fwiw, carolyn and i prefer 'searchset')

In terms of how this might be spec'd beyond the naming of the element, some thoughts for your consideration:

Presently, depending on how a page's search functionality is setup (e.g., using an actual form submission, or using JavaScript), current use of the landmark would be expected to look like one of the two following markup patterns:

<form role=search action=... method=get aria-label="site (or some other name to describe purpose)">
  <!-- search related controls here -->
</form>

 or

<div role=search aria-labelledby=foo>
  <p id=foo>Filter results</p>
  <!-- search related controls here -->
</div>

While there is no requirement in the ARIA spec for a search landmark to have an accessible name, it can be helpful to provide one, particularly in instances where there might be two search landmarks on a page, or if the search controls have a specific function that is a variant of searching - e.g, filtering. It would be nice if the new element could be named by a native HTML feature, for instance similar to a <fieldset> via its <legend>.

[domenic]

Personally I like searcharea and searchgroup; either of those would be good in my book. Can you tell us more about why you like searchset? I don't normally think of a landmark or section as a "set".

For the non-naming point, it sounds like what you're suggesting is that we'd benefit from changing the accessible name computation algorithm for this element in some way, so as to give a "first-class" (i.e., non-ARIA) way of specifying accessible names.

What kind of markup pattern do you think would be best for such scnarios? It looks like other sectioning and grouping elements use title="" attributes. This seems a bit strange given how that will also create a tooltip in desktop browsers, but probably there's a good reason for the precedent... should we follow it?

[scottaohara]

Personally I was leaning towards searchset purely towards the relationship I see here with fieldset. And that’s because the search landmark is meant to represent a related grouping of form controls / potentially links and instructions that are related to searching. As such, it isn’t a huge leap to make, imo, that a search grouping of form controls could be named by a legend, similarly to a standard grouping of form controls.

To your point though, yes this could be done via the title attribute. It’s just unfortunate that’s the only way to name these elements using HTML at present. Just figured this would be a good opportunity to suggest such a mechanism.

So my original though was something like

< searchgroup>
< legend>name< /legend>
…
< /searchgroup>

The mapping/behavior for legend already exists, so if it could be extended to work for this new element, as it does with fieldset, it seemed a path with lower potential for friction.

I hadn’t thought of another element, aside from legend, since I figured that’d be out of scope. Though ideally, to allow other elements that are also landmarks to be named, it’d be nice if there were either an element that could work similarly to fieldset / legend or table/caption. Or I suppose an attribute that could indicate the element’s content was to be used as the accessible name for the closest ancestor element that was an implicit landmark. Or if more direct relation was needed, it could work as an attribute (spitballing: namefor=foo) pointing to the id of the element it was to name.

I understand this is all obviously beyond what was previously discussed, so definitely do not want this to hold up the primary objective of creating the new element. But appreciate that I could talk this out a bit more. Thanks.