In an original equipment-return page, the return reference sits in the main panel while the condition note and submit button sit in a review panel. All three belong to one return. A separate stock-search form on the page must keep its query out of the return request.
Give each outside control the same owner
<form id="equipment-return" action="/returns" method="post">
<label for="return-reference">Return reference</label>
<input id="return-reference" name="reference" required>
</form>
<section aria-labelledby="condition-heading">
<h2 id="condition-heading">Condition on return</h2>
<label for="condition-note">Condition note</label>
<textarea id="condition-note" name="condition"
form="equipment-return" required></textarea>
<button type="submit" form="equipment-return"
name="intent" value="record-return">Record return</button>
</section>
<form id="stock-search" action="/stock" method="get">
<label>Find equipment <input name="q" type="search"></label>
<button type="submit">Search stock</button>
</form>
The routes above are illustrative and require the application's real handlers. The outside textarea belongs to equipment-return even though it is not a descendant. The button submits that same form. form="equipment-return" is an ID reference, so do not include a CSS selector's # prefix.
The explicit association also means an outside required control can block that form's native submission. Keep the condition note visible and reachable; a distant validation error is easy to miss when a layout moves controls between panels.
Inspect ownership before debugging the request
In the running page's console:
const returnForm = document.getElementById('equipment-return');
const note = document.getElementById('condition-note');
console.log(note.form === returnForm);
console.log([...returnForm.elements].map(control => control.name));
The first value should be true. The collection should include the reference, condition note, and return button. The stock-search query should remain associated with stock-search.
form.elements lists associated controls; it is not itself the outgoing payload. A named disabled input is still excluded from submitted data. An output or fieldset can appear in the collection without contributing a submitted value. The form submission guide covers those successful-control rules and including the actual submit button when constructing FormData.
A fieldset does not assign its children's owner
This change would leave an outside note unassociated:
<fieldset form="equipment-return">
<legend>Condition on return</legend>
<textarea name="condition"></textarea>
</fieldset>
Put form="equipment-return" on the textarea too, or place the fieldset and its controls inside the form. The fieldset's own association does not make its descendants inherit that association.
A control can also explicitly belong to a different form from its nearest ancestor. Check the control's .form property when a field appears in the wrong request. Keep form IDs unique, and avoid nested forms, which introduce parsing problems rather than creating a supported grouping mechanism.
For the equipment-return check, enter a reference and leave the outside note empty. The return submission should be blocked by that required note. Fill it, submit through the actual handler, and inspect the request. The reference and note must arrive together; the stock query must stay in its own search request.