The one exception for me are forms. In that case I would rather use a div or section tag with role=“form”. I have seen less experienced developers do weird things with form tags and submit event and form tags have unique behaviors associated and requirements.
When a form requires JS to be submitted, there’s a high probably that I abandon that website instead. My expectations of working plain HTML are never higher than with regard to forms. By all means, progressively enhance, but don’t be tempted by the hubris of claiming to know better than the user-agent how the user-agent should work. It’s not just rude, it’s a slippery slope towards systematic incompatibility, weirder bugs than the ones you were afraid of, and security holes.
> When a form requires JS to be submitted, there’s a high probably that I abandon that website instead.
You say that, but I doubt that in practice. If the form is your bank login or bill pay or anything else you are locked into I really doubt you will give up because of some personal opinion on JavaScript and instead spend the next 30 minutes calling somebody to complete a similar action over the phone.
The goal is to achieve accessibility as equivalently as possible, with as little enhancement as possible, and yet often not force a page change because of form submission.
Does that still allow you to press "Enter" in an input field to submit the form, or do you have to build your own kludge to replicate that? If so, that sounds like that would invite only more weird things...
You are clearly underestimating the compatibility & accessibility challenges of reinventing the form submission code of a web browser from first principles.
Believing you can do so and not fuck it up is sheer hubris, not to mention, wrong. Doing so because you don't like the browser edge cases, is how websites end up suffering from even more edge cases, and harks back to the bad old days of "Sorry your browser is not supported".
Financial institutions are amongst the worst offenders - ironic since pulling this kind of naïve stunt vastly increases the attack surface. I've been in a position to redesign financial institution systems and rewrite their technology policies, and when doing so this kind of off-standard NIH crap is something I seek to stamp out.
Want to submit a form? Use a damn form, with a plain old submit button, and rely on the standard behaviour. Want to put some UI polish around it? Progressively enhance the standard behaviour.
What not to do: imagine you can write better UI<>protocol interaction code than that already in Chromium and Webkit, or hope to infer and reimplement the behaviours of any more specialised user-agents.
What you said. Most of what you said is common anti patterns. The reason is web technologies are built around a few set of standards that are designed for extension, such as the DOM and WCAG. Fearing those standards for a small set of static principles is common but that doesn’t make it smart. That’s why this technology space is so hostile to originality. You mentioned NIH but the more common problem is: https://en.m.wikipedia.org/wiki/Invented_here
Stop being so afraid and hostile. Embrace how these technologies work and more easily achieve accessibility with less effort. If you are waiting for some tool, NPM package, or framework to do it for you it’s not going to happen.
Abusing standards with shoddy inner-platform reimplementations doesn’t make someone an innovator, it makes them as much a fool as the cargo-cult of the NPM ecosystem.
So you think it's safer to rely on every engineer adding that (and the other facilities provided by web browsers by default when using native elements) to every input field in a form, than relying on them not doing weird things with that one form tag?
That doesn't sound worse than not naming the inputs or coding the buttons for keyboard interaction, things inexperienced developers will do if they're not educated in the basics of semantic HTML (even those who do use inputs too often neglect to associate a <label> where they're called for).
Forms cannot be nested. That is an html violation. That is because all submit events fire on all nodes contained by a form on submission even if the page does not go anywhere. Forms also require an action attribute that contains a submission address, which requests a new page on submission.
Not the same thing as nesting forms, but when faced with similar challenges I found the <input form="form-id" /> attribute[0] is a good solution.
The trade-off is that you have to specify it almost every single time, but it lets you group form elements that for UX purposes belong together, but for other reasons need different forms.
If a dev finds a form to be nested, it's usually because something was tacked on as an afterthought. I'm speaking from experience.
I had a project that had applications associated with it. Forms are the natural way to express this. There were some disclosures associated with the application, and there was a modal associated with emailing the disclosures. I needed to add some front end validations to this modal.
No matter what I tried, I could not get these validations to trigger correctly. I spent an entire work day on trying to get a library to work with this modal. It wouldn't work, because changing the modal's div to a form tag would cause errors or unexpected behavior due to the nested form tags.
TL;DR: Nothing requires it. Devs might not understand the implications.
