When researching how to write forms in HTML I see mention of the term "form control".
In particular using Twitter Bootstrap which has classes like form-control and control-label.
What exactly is a "form control"?
A form is a component of a Web page that has form controls, such as text fields, buttons, checkboxes, range controls, or color pickers. A user can interact with such a form, providing data that can then be sent to the server for further processing (e.g., returning the results of a search or calculation). No client-side scripting is needed in many cases, though an API is available so that scripts can augment the user experience or use forms for purposes other than submitting data to a server.
A form control is a user interface control that serves as the point of connection between the user and the server. Interactions vary by control type: buttons: button file handling: input type="file" menus: select, etc. And are also grouped into categories
Controls are essentially an API of key-value pairs for pinging back and forth to the server.
W3C's Form Section is incredibly informative in its walk through of forms, form elements, form controls, form owners, and more insight to the inner workings of the Internet's workhorse: the humble HTML form.
References:
Forms
HTMLFormElement
Association of Controls and Forms
XForms Glossary
Form Controls Infrastructure
For Bootstrap it seems to be a styling thing: From bootstrap's page:
Individual form controls automatically receive some global styling. All textual <input>, <textarea>, and <select> elements with .form-control are set to width: 100%; by default. Wrap labels and controls in .form-group for optimum spacing.
But more broadly it seems to be more, as per #the_velour_fog 's comment:
it seems to be more than just a styling thing: it seems form control just refers to the individual HTML elements in a HTML form e.g. from https://html.spec.whatwg.org/multipage/forms.html; A form is a component of a Web page that has form controls, such as text fields, buttons, checkboxes, range controls, or colour pickers.
The term has very little to do with styling, though styling forms is a special art.
'Form elements' are the (usually interactive) controls whose values are submitted automatically with the http request that is initiated by clicking the "submit" button - even without javaScript. Most commonly this would be button, input, textarea and similar element types. MDN has this entry with hyperlinks to documentation of each type.
Anything where a value attribute is meaningful or expected can be a form element. The name attribute is also important, since this is used (e.g. on the server side) as a 'key' for the value in the form data.
The supporting elements such as label, fieldset and legend are commonly regarded as form elements, since they exist to name and group the other form elements from the user's point of view, although they contribute nothing to the submitted form data.
There may be elements in the form which have no 'value' attribute (e.g. headings, hyperlinks or images), but strictly speaking, these are not 'form elements'. They may however contribute to the form data via client-side javaScript.
And you can use form elements in something which is not a form, or which makes parameterised http requests without an explicit form element. This is very common.
Related
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's 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.
I believe you’re suggesting a good solution and it shouldn’t pose any issues to assistive technology, if you’re respecting some points:
The form should use role="search" or have an accessible name
The form elements must stay at the beginning of that landmark
Each field needs a label, in the wireframe the text input doesn’t have one
Also each group of checkboxes needs a fieldset, since otherwise the headlines (type, category) will not be announced
You find a solution for the immediate submission of the form when changing a value (if applicable)
Any form elements inside the form will be submitted as well, so beware of their names to not overwrite form data (numbers per page)
Functions of the form tag
The form role is a landmark role, meaning it’s purpose for accessibility is to provide an anchor to jump to the form via shortcuts or from an index of forms.
What’s included in the form also determines which values will be submitted to the server, if that’s not done via JavaScript. And last but not least, it determines what elements trigger implicit submission, f.e. when pressing Enter or the Return key on a touch keyboard while inside a text input.
I do not believe assistive technology does anything other than use the landmark role.
In your case, you should use the search role instead, since it is a search form. If you don’t, you need to provide a name for the form via aria-label or aria-labelledby.
Since the form elements are at the beginning of the search or form landmark, it should be fine. The end of a landmark is not announced.
<form role="search">
<input type="search" aria-label="Search for">
<button>Search</button>
<fieldset aria-label="Filters">
<fieldset>Type</fieldset>
<label><input type="checkbox"> Type filter 1</label>
Changes of context on input
The wireframe suggests that changing the value of a checkbox’ or the select, the form is submitted automatically.
If this is so, you also need to mind that for users of assistive technology, this change of context can be disorienting and unexpected.
Understanding Success Criterion 3.2.2: On Input explains that you can work around this by indicating that the form will update immediately, or by using an additional button.
See also Does faceted search fail accessibility?
I am trying to understand how the HTML form standard works in relation to select boxes. And the question is how does HTML form know which value a select box has as selected value in order to submit it when the form is submitted. I am inspecting a form with developer tools and I do not see anything changed whenever I change the select box selected option.
This is a pure HTML question and it should be pretty basic for those that they know the HTML standard well. Note that I am not asking for a JavaScript answer on how to get the selected option. I am asking a question in order to understand how does HTML form know which of the options is selected.
If you also have pointers to any documentation, that would be much appreciated.
You could ask the same question about how does a form know a checkbox is checked, or what text has been typed into an input field. The HTML for a web page gets parsed into a DOM (Document Object Model), and there are objects behind the scenes representing DOM elements. These objects, among other things, save state information about DOM elements such as selected options and the checking of checkboxes.
Those states don't show up just by viewing the source of a webpage, or necessarily even when using an inspect tool. But the info is there in the DOM for the browser to assemble into the HTTP request that is generated when you submit a form.
I am planning on setting up multiple forms on a page and wanted to make sure that this is ok. Do submit buttons act only on the form they are inside of or do they apply to all the forms on a page?
A submit button submits a form. It seems that the specifications do not clearly say that this means the enclosing form element, probably because this was taken as self-evident. And it’s certainly what browsers do.
HTML5 drafts make this a bit clearer by introducing the concept of “form owner” of a field (such as a submit button). By default, the form owner is the enclosing form element, though the proposed form attribute of a field could change this. And a submit button is defined as submitting the form owner.
As far as I know (and I'm pretty sure), submit buttons/inputs will by default only act on it's parent form. You can read more about forms in the W3 specifications.
So if you just wonder if it's ok to have multiple forms in your page, then yes, it is.
I have a HTML form which allows a radio button selection of two products. After the product is selected, the user has the option of digital download or delivery of which there is a separate form for each asking different questions.
I need to ensure that the product selection is passed to either of the two form for when the user makes the decision on which delivery option to opt for. Only one of the forms is submitted.
Basically I have:
Form1: Product Selection Radio Button (2 Options)
// Choice of delivery options hidden by a javascript reveal of the relevant form
Form2a: Digital download form fields with actions for validation and submission to Paypal
Form2b: Regualar delivery form fields with actions for validation and submission to Paypal
I look forward to a solution from the excellent minds on this site!
Assuming this is all on a single page, it sounds like you don't really need multiple forms. I would suggest just including everything in a single form, wrapping the applicable questions for each selection in separate <div> tags and using some JavaScript to present the applicable <div> when either radio button is selected. When the form is submitted, check the radio button selection on the server side to determine which other form fields to utilise.
Several radio buttons with the same name act as a set, where checking one unchecks the others.
What is the scope of this behavior?
The form in which the button resides
The page / document on which the button resides
Does scope pass into iframes?
I have always used them in forms, but now writing formless HTML (using ajax for posting), and everything seems to be working just fine, so my guess is #2.
Radio buttons with the same name in the same form act as a set, but not with those of different forms. Radio buttons with no form act as a set with those with no forms.
test it yourself:
http://jsfiddle.net/8qqNC/1/
Radio buttons are scoped to the form they are in.
Frames contain external documents, and nothing in them is considered part of the current document, let alone an element within that document.