A button labelled “Show example” may look like a harmless helper, yet unexpectedly submit the surrounding form. The visible words describe an intention; the button’s HTML type helps determine its built-in behaviour.
The MDN button reference documents submit, reset and ordinary button behaviour. In a conventional form, an associated button without an appropriate explicit type can act as a submit button.
For a fictional sign-up form, imagine a helper that reveals a sample username. That action should not send the visitor’s unfinished details. An explicit ordinary button type, with the intended interaction implemented separately, makes the role clearer.
Test the complete form rather than the isolated button. Enter harmless sample text, activate the helper with a mouse and keyboard, and check whether navigation or submission occurs. A visual inspection alone will not reveal an unintended request.
Keep the real submit control clearly labelled too. Changing a button’s colour does not change its type, and a label such as “Continue” still needs context about what will happen next.
This small distinction often explains why a page seems to refresh when someone only wanted help. The repair begins by matching each control’s actual behaviour to its stated job. It also gives testers a concrete question: did this interaction merely change the page, or did it send the form’s data somewhere?
Editorial illustration from the site library.