Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<search> element #610

Closed
domenic opened this issue Feb 4, 2022 · 4 comments
Closed

<search> element #610

domenic opened this issue Feb 4, 2022 · 4 comments

Comments

@domenic
Copy link
Contributor

domenic commented Feb 4, 2022

Request for Mozilla Position on an Emerging Web Specification

@annevk
Copy link
Contributor

annevk commented Feb 7, 2022

From @hsivonen in a comment on the PR:

If a <search> element is added, making it close <p> is probably the right thing to do. I'm not convinced that adding the <search> element is worthwhile, since it doesn't add expressiveness but mainly addresses a principled concern that all of ARIA should be ported to HTML in non-ARIA form, but I don't know enough about the use cases to argue strongly in favor or against.

I don't have a particularly strong opinion on this either, though I do think it's valuable for HTML to be expressive enough that in most situations web developers don't have to reach for ARIA.

Overall I'd lean towards worth prototyping for this therefore.

@annevk annevk added the whatwg label Feb 7, 2022
@bgrins
Copy link
Member

bgrins commented Jun 17, 2022

We're generally supportive of the goal here, and when I initially looked at the data I found top 10 most common aria roles on HTTP archive I found this element really compelling (~18% of pages have a role=search and it's the most common role other than presentation which doesn't have an element).

However, when digging deeper into the data I believe that form role=search is much more common than div role=search. From a preliminary analysis on HTTP Archive that @rviscomi was kind enough to help with it appears that for the search role, ~16% of pages use form and ~2% use div. I'm not saying I'm opposed to the new element, but that does seem to limit the benefit as compared to i.e. nav which doesn't have this split behavior with forms. And, could there be confusion with pages currently using the form with role knowing whether or not they should be migrating from <form role=search> to <search><form> or <form><search>? @domenic I didn't see discussion about this in the issue but may be missing it - has this already been considered?

@domenic
Copy link
Contributor Author

domenic commented Jun 17, 2022

Yeah, that was discussed around whatwg/html#5811 (comment) and subsequent comments. Apparent either <search><form> or <form><search> are exposed the same way to AT. We have an example in the spec draft of the former.

@zcorpan
Copy link
Member

zcorpan commented Dec 19, 2022

Apparent either <search><form> or <form><search> are exposed the same way to AT.

@jcsteh commented on this point in whatwg/html#5811 (comment) , but the conclusion still seems to be that the experience for AT users is probably the same. I don't see any impact on the spec PR for this point, though, but can keep in mind when explaining or documenting the element.

I've discussed with @hsivonen and @jcsteh; we're not completely sold on the idea that all ARIA roles must have an HTML equivalent, but also not opposed.

"worth prototyping" is now called "positive". I'll add the label; no dashboard entry (unless requested).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants