I recently turned a design in to HTML and CSS to be implemented by our back-end developers. For a search result page I used two form tags. One for the search bar and one for the sidebar with filters.

The back-end devs requested if I could just wrap everything in one form tag instead.

Due to the layout and not yet available CSS subgrid the only way to get both parts in one form wrapper is to wrap the entire content (the search results) in a form tag.

Something about this doesn't feel right even though I can't seem to find anything online other than that it is allowed to have regular HTML-tags in a form element.

My solution would be to turn both the form tags into fieldsets with each a legend to indicate what part of the form it is.

Would this be okay accessibility wise? VoiceOver doesn't seem to care about what's inside the form tag. All form fields are listed separately in the Form Controls menu.

Visualization of the page HTML

  • Form tags can indeed have (almost) any HTML tag inside, that should not be a problem here. I wonder, is this a two-step form? First search and then filter the results? Or can you select filters even without searching?
    – jazZRo
    Oct 4, 2022 at 12:00
  • 1
    Not to disrispect your devs, but they clearly have no idea. This kind of design (and its implementation) is quite common. I can't even imagine why search results and filters should be inside the same form element and honestly can't find any reason, no matter how hard I try to think about it. Also, how will they paginate or sort results inside a form tag? not that it can't be done, but it's super weird, not accessible at all and a plain nightmare altogether.
    – Devin
    Oct 4, 2022 at 17:44
  • @Sean I've posted there too! Dec 5, 2022 at 19:22

1 Answer 1


interesting problem. A few thoughts/considerations:

Yes, HTML allows you to do it

HTML is like an old dog who still loves you no matter how often you beat it with your slippers, so it takes no offense with this. You can have all kind of stuff in forms, multiple submit buttons, all that. That said...

Accessibility-wise, this is so-so

I haven't tested this, but I can't imagine this being a great experience with a screen reader. And even for the sighted; say the layout breaks down on an older device or CSS not loading, suddenly you have this weird giant form which kind of belongs together but not really...I foresee some mean edge cases here.

That said, it is also not obviously breaking any specific rules or guidelines I am aware of. Apart from that, I think the technical side deserves some consideration here:

What exactly is the gain from doing it in one form?

  • I am pretty sure your devs are not doing themselves a favor when they tie two semi-related forms together, because you kind of need to save the state of the other whenever you submit one of them, create interdependence for little reason and multiply possible states.
  • Is the sidebar even a real form? Does it have a submit button? If it's just filtering the articles with JavaScript w/o doing an HTTP request I don't think it should be a form as per the HTML spec. If the filtering option are only applied when one presses Search again, I fear that might be not clear from an UX perspective?
  • Is the Search even an actual form that is submitted? Nowadays that is actually kind of rare, a lot of search is handled with god knows what libraries and methods (mostly js). If not, some other way might open up anyways.

TLDR: This is mostly alright, see if it survives a screen reader and adapt if necessary. Clarify the technical specs and what exactly does what upon what interaction, and pick the most pragmatic solution.

  • 1
    Thanks for the reply and questions, I will look into this! Oct 10, 2022 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.