As I was reading the other comments,
• Position of the Submit Button at the bottom:
The problem with this is that every time user edits the form he might try to find submit
button, and for that he has to scroll at the bottom of the form.
• Floating Submit Button at the bottom left corner:
Floating position of the submit button on the lower left ...
The better solution is maintaining one concept throughout the application (this includes code scaling)
However, in critical cases styling can be changed - this requires a separate css code.
I wonder, however, in an aesthetic context, is the alignment to the right justified?
And whether just just left or above input would not be a better solution
Now that the forms are organized into cards, why not have a submit button for each card? This way, the submit button will always be located close to the user input.
As the typical use case is that the user will only modify a few elements at a time (hopefully all in the same card?), they won't need to click 3 times.
The button would be visible only once a ...
Both are good. But keeping the button active and providing an error message pointing to the error made is better.
This way the user also knows what is keeping them from changing the password when the error message pops.
Full Name > Email > Message. Don't forget to add mandatory stars to the input fields ;)
It's almost world standard to ask first name/surname to the user on the contact forms or registration forms. I've attached just one example. If you will google 'contact form examples' You will see also all of them start with the name. This is not a written rule. But ...
It depends on how you approach this component. Every component's identity, operation, and state should be available to assistive technology to make it accessible.
When an arrow is on keyboard focus, screen reader should inform the user about the identity of the element (Up arrow) its state (clicked/ unclicked) and operation (press enter to increase the ...