A resource library can have two different searches on one page: a site-wide search for articles and a filter for the currently displayed equipment manuals. Giving both fields the label "Search" leaves their scope unclear. Name each region and field for the collection it actually searches.
Give the site-wide search a real destination
For an application that already implements /find, this original markup submits the query as q:
<search aria-label="Entire resource library">
<form action="/find" method="get">
<label for="library-query">Find library articles</label>
<input id="library-query" type="search" name="q">
<button type="submit">Find articles</button>
</form>
</search>
The input's label identifies what to type. The container's accessible name identifies the search region when someone navigates by landmarks. The button identifies the action. These are related pieces, but they do different jobs.
The /find route is an integration placeholder, not an endpoint supplied by HTML. Implement that destination before using the fragment on a public site. For the form's submission details, see how HTML forms submit named values.
Keep the manual filter local
For the equipment-manual filter, a separate region can contain the query and an additional checkbox:
<search aria-labelledby="manual-filter-heading">
<h2 id="manual-filter-heading">Filter equipment manuals</h2>
<label for="manual-query">Manual title or equipment code</label>
<input id="manual-query" type="search">
<label>
<input id="current-only" type="checkbox">
Current editions only
</label>
</search>
<section aria-labelledby="manual-results-heading">
<h2 id="manual-results-heading">Equipment manuals</h2>
<!-- The application's manual list belongs here. -->
</section>
This fragment marks the interface; it deliberately contains no filtering script. Connect both controls to the application's existing filter routine. Keep the same underlying manual list available if that enhancement fails, rather than shipping an empty list that only JavaScript can reveal.
Place the main results after the controls, in the page's content. A compact suggestion menu that belongs to the search interface can remain inside the search region. Do not wrap the entire page in <search> merely because it contains matching articles.
Distinguish multiple search regions
The names "Entire resource library" and "Filter equipment manuals" distinguish different scopes. If the same site search is repeated in the header and footer, use the same landmark name for those identical functions. MDN's search-role guidance explains that distinction.
An existing form with role="search" is another way to expose a search landmark. Choose that form or a surrounding <search> element rather than adding redundant nested search landmarks. Label the actual field in either version; placeholder text disappears as someone types.
When reviewing the library page, submit a site-wide query and confirm the destination receives it. Then filter the manual list and confirm that its controls affect only that list. Finally, inspect the page's landmarks with the accessibility tools used by your team. The names should make it clear which collection each search operates on before anyone enters a query.