Skip to content

Conversation

Josh-Cena
Copy link
Member

Fix #37799

@Josh-Cena Josh-Cena requested review from a team as code owners October 8, 2025 16:05
@Josh-Cena Josh-Cena requested review from estelle and hamishwillee and removed request for a team October 8, 2025 16:05
@github-actions github-actions bot added Content:HTML Hypertext Markup Language docs Content:Learn Learning area docs Content:Accessibility Accessibility docs labels Oct 8, 2025
@Josh-Cena Josh-Cena requested review from scottaohara and removed request for a team October 8, 2025 16:05
@github-actions github-actions bot added the size/s [PR only] 6-50 LoC changed label Oct 8, 2025
Copy link
Collaborator

@hamishwillee hamishwillee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks reasonable with the caveat that we should recommend search first (after all, that's the title) and this focusses on the role first. I understand the reasoning (depth of support) but that will become less significant over time, and I'm not particularly worried about relative terseness.

@github-actions github-actions bot added size/m [PR only] 51-500 LoC changed and removed size/s [PR only] 6-50 LoC changed labels Oct 10, 2025
@Josh-Cena
Copy link
Member Author

I think terseness is a big factor when judging two pieces of code that do the same thing. Someone telling me "prefer A over B" doesn't really matter, even if that someone is WAI, if there's no tangible reason for me as a developer or for my users. Also <search><form></form></search> provides more "freedom" because now extra content can either go inside the <form> or go outside the form but inside <search>, and I don't really like introducing unnecessary degrees of freedom, so in a sense terseness means restrictiveness which is nice.

@hamishwillee
Copy link
Collaborator

I think terseness is a big factor when judging two pieces of code that do the same thing.

I'm a bit meh. I'd probably just use the search element because its purpose is clear and obvious. But either way, sure, you're the author. Still worth wording search first.

@Josh-Cena
Copy link
Member Author

Yeah just did

Copy link
Collaborator

@hamishwillee hamishwillee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Josh-Cena Nice. I'd quite like a review from @scottohara or @estelle too.

Copy link
Member

@estelle estelle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a few nits....

This could, however, cause confusion for screen reader users, since they will not have any verbal indication of what the search input is. One way around this that won't impact on your visual design is to use [landmark elements](/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/landmark_role).

- A `role` attribute of value `search` on the `<form>` element will cause screen readers to announce that the form is a search form.
- Wrap the whole search functionality in a {{HTMLElement("search")}} element, which creates a landmark region that assistive technologies can announce and quickly navigate to. If your `<input>` is already in a `<form>`, you can alternatively add [`role="search"`](/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/search_role) to the `<form>` element, which also makes the `<form>` a search landmark. The `<search>` element uses native HTML semantics, while `role="search"` has more support and may be terser to type if you already have a `<form>` wrapper.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Wrap the whole search functionality in a {{HTMLElement("search")}} element, which creates a landmark region that assistive technologies can announce and quickly navigate to. If your `<input>` is already in a `<form>`, you can alternatively add [`role="search"`](/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/search_role) to the `<form>` element, which also makes the `<form>` a search landmark. The `<search>` element uses native HTML semantics, while `role="search"` has more support and may be terser to type if you already have a `<form>` wrapper.
- Wrap the whole search functionality in a {{HTMLElement("search")}} element, which creates a landmark region that assistive technologies can announce and quickly navigate to. If your `<input>` is already in a `<form>`, you can alternatively add [`role="search"`](/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/search_role) to the `<form>` element, which also makes the `<form>` a search landmark. The `<search>` element uses native HTML semantics, while `role="search"` is well supported and may be terser to type if you already have a `<form>` wrapper.

To future-proof, since they may soon be equally well supported (if not already the case)

Copy link
Member Author

@Josh-Cena Josh-Cena Oct 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While they can both be "well-supported", it is always the case that role="search" has "more support". Whenever we talk about AT, old browsers and ATs are still relevant.

Copy link
Member

@estelle estelle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! 🎉

@Josh-Cena Josh-Cena merged commit 6193c69 into mdn:main Oct 13, 2025
8 checks passed
@Josh-Cena Josh-Cena deleted the role-search branch October 13, 2025 22:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Content:Accessibility Accessibility docs Content:HTML Hypertext Markup Language docs Content:Learn Learning area docs size/m [PR only] 51-500 LoC changed

3 participants