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.

[carmacleod]

searchgroup is also ok with me (@scottaohara says he's fine with it, too).

[Edit: Although... thinking about existing elements with "group" in the element name, there's hgroup, colgroup, and optgroup. Both colgroup and optgroup feel like "sub-groups", which might be confusing. And optgroup supports a label attribute, which might be an odd precedent if the "search" element were to support a "legend" child element... so I still have a slight preference for the name searchset with optional legend child, along the same lines as fieldset with legend child.]

I'm not a fan of searcharea - I guess it feels like it could be confused with "this is the area to search within" as opposed to "this is a group of things to aid in searching the site/page/internet/whatever". :)

[j9t]

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.

If this element is not related to performing a search (and input for a search query), just what is this element for then? What is a “search facility for the document”?

(It seems all perfectly clear for everyone here, but it wasn’t for me when reading through the issue.)

[annevk]

@j9t the first paragraph of OP explains it (and has a link with further information).

[annevk]

"set" seems quite reasonable from the perspective of fieldset, but perhaps not from the perspective of mathematics. Another variant I thought of is searchsection, but it's quite long (not longer than foreignObject though so I think it's okay parser-wise as far as optimizations go).

[j9t]

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.

If this input from the side is welcome (apologies for anything I missed): Is this not the same problem the ARIA role suffers from? And would the consistency not be useful and valuable by itself, similar to what we have with main, nav[igation], or form?

Also: Would the problem of authors mistaking search just for search input (if that’s a concern, re @domenic) outweigh the problem of authors shunning searchsomething because they don’t understand it well enough?

From my (limited) vantage point, “search” looks like a name consistent with the naming of other elements, allowing for great 1:1 translation to ARIA, and coming with enough clarity for adoption. As an author, I’d prefer this element name.

[domenic]

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.

Ah OK. Yeah, I agree that might be a reasonable thing to tackle, but I think we should do it holistically for all sectioning elements that currently use title="", and not couple it to this proposal. Then we can have discussions like <legend> vs. <summary> vs. <caption> vs. new element vs. <h1> (😉 mostly kidding on that last one).

I'm not a fan of searcharea - I guess it feels like it could be confused with "this is the area to search within" as opposed to "this is a group of things to aid in searching the site/page/internet/whatever". :)

Good call.

Another variant I thought of is searchsection

I like this one too. I think length is not a huge deal since there shouldn't be too many of these per page.

Also: Would the problem of authors mistaking search just for search input (if that’s a concern, re @domenic) outweigh the problem of authors shunning searchsomething because they don’t understand it well enough?

I don't think you should use this element if you don't understand it; my understanding is that mislabeled landmarks are worse than no landmarks at all.

---

So at this point I think the best candidates are searchgroup, searchsection, and search. I've posted a Twitter poll to see if we can get some web developer sentiment, but to be clear the results are not binding; it's just seeking to get more input :).

[Paul-Hebert]

Hey, thanks for working on this! I'd love to have parity between HTML elements and aria roles, and it would be nice to be able to switch from a role to an element in my code.

I'm a little confused about how this would work in conjunction with forms. If I wanted to use a <form> element for native form submission would I continue to use <form role="search">? Or would I nest the new search element in a form? <form><search>...</search></form>?

Either way would work for me. I just want to make sure I'm understanding. Thanks!

[domenic]

This fell off my radar during vacation, but back on it now...

The Twitter poll is fairly conclusive that we should name it <search>. However a lot of people expressed confusion (similar to @Paul-Hebert's above) about when they would use this versus using <form role="search">.

The answer, I believe, is that they would use <search> in place of <div role="search">, and continue using <form role="search"> if they didn't need a wrapper element.

I wonder if we should consider solving the <form role="search"> case as well though. I.e. if our goal is to avoid people having to use ARIA for mainstream use cases (per the first rule of ARIA), then it's less of a win if we tell them to sometimes use <search> and sometimes use <form role="search">.

Ideas I can think of:

• Encourage (in the spec and docs) a nested pattern, i.e. <search><form>...</form></search> for search forms. I'm not sure what impact this has on AT users, if any, versus <form role="search">.

• In addition to <search> (for the <div role="search"> case), also specify a boolean attribute search which can be placed on <form>. So then you'd replace <form role="search"> with <form search>. There's not a lot of precedent for semantics/AT-only attributes as opposed to elements, perhaps because the win over ARIA attributes is so slight, but it still seems reasonable to me, and philosophically aligned with the goal of not requiring ARIA for mainstream use cases...

[scottaohara]

<search>
  <form>...</form>
</search>

or

<form>
  <search>...</search>
</form>

or

<form role=search>...</form>

would all be the same as far as how these patterns were exposed to AT. I personally like the idea of using a search attribute on a <form> element as an alternative to using ARIA. While practically it wouldn't be that different than devs using role=search on a <form>, right now... it being part of HTML could at least allow for extensions of its features or functionality in the future?

[jimmyfrasche]

I have a lot of nav with just a ul so search with just a form seems perfectly normal

[Paul-Hebert]

Thanks for following up! I like the idea of having a <search> element but would probably reach for <form search> first if it were available. Though, I haven't run into a need for <div role="search"> instead of <form role="search"> so there may be a use case I'm missing!

[foolip]

@Kaleidea as I said, I'm going to step away from this issue. If this comes to an Intent to Ship on blink-dev I will have to expand on the compat risk that I see and the analysis that would be needed.

[Daasin]

Perhaps the discussion currently taking place at w3ctag/design-reviews#714 aswell as #7320 could be relevant?

[jcsteh]

<search>
  <form>...</form>
</search>

or

<form>
  <search>...</search>
</form>

or

<form role=search>...</form>

would all be the same as far as how these patterns were exposed to AT.

@scottaohara , I don't follow this. The user might perceive them similarly, but they're definitely different in terms of a11y tree exposure. In particular, <form role="search"> would override the form role with the search role, whereas the other two provide both roles, albeit in a different nesting order. Can you clarify your thinking here?

[scottaohara]

@jcsteh in the other two instances the from landmark is not supposed to be exposed due to no accessible name of the form element.

[jcsteh]

That's fair, but the element is still exposed with the form role , even if it's not a landmark. If an AT chooses to report the presence of forms even if they aren't landmarks, these will not be equivalent. NVDA doesn't report non-landmark forms, but I vaguely recall JAWS might; I'm not certain.

[scottaohara]

Last I had checked JAWS made no mention of a form element if it had no name.

If need be, we can clarify this further in html aam to suppress a form landmark role if it is nested with a search element.

edit: yes, testing again today with JAWS w/chrome and firefox, an unnamed form is not exposed with default settings for either of the screen readers. Neither does Narrator with Edge on Win11.

Further, only recently (last few months - much later than my original comment here) was HTML AAM updated to indicate a form element could still expose a form role (though not a landmark). Previously a nameless form was not mapped/a generic element.

ARIA 1.3 has additional updates indicating that only a named element with a form role should be exposed as a landmark form.