HTML forms let users enter information, make choices, search, sign in, and submit data on websites. This cheat sheet helps students build forms that are organized, readable, and usable for many different people. It focuses on the tags, attributes, and accessibility habits that appear in real web projects.
Students need these skills to create pages that work with browsers, keyboards, screen readers, and form validation.
Key Facts
- A basic form uses <form action="/submit" method="post"> to send user input to a server location.
- Every important input should have a matching label using <label for="email">Email</label> and <input id="email" name="email" type="email">.
- The name attribute is the key sent with form data, so <input name="username"> creates a submitted value called username.
- Use type="email", type="number", type="date", type="checkbox", and type="radio" to give the browser the right controls and built-in checks.
- The required attribute stops submission when a field is empty, and minlength, maxlength, min, max, and pattern add more validation rules.
- Related controls should be grouped with <fieldset> and described with <legend>, especially radio buttons and checkboxes.
- Accessible forms must be usable with the keyboard, so focus order should follow the visual order and visible focus styles should not be removed.
- ARIA can add helpful information, such as aria-describedby="hint", but native HTML labels and controls should be used first.
Vocabulary
- Form
- A form is an HTML section that collects user input and can submit that input for processing.
- Label
- A label is text connected to a form control so users and assistive technology know what information is requested.
- Input Type
- An input type is an attribute value that tells the browser what kind of data or control to use.
- Validation
- Validation is the process of checking whether user input meets required rules before it is accepted.
- Fieldset
- A fieldset is an HTML element that groups related form controls together.
- ARIA
- ARIA is a set of attributes that can improve accessibility when native HTML alone does not provide enough meaning.
Common Mistakes to Avoid
- Leaving inputs without labels is wrong because screen readers may announce only a vague control name, making the form hard to complete.
- Using placeholder text as the only label is wrong because placeholders disappear when users type and may not be announced reliably.
- Forgetting the name attribute is wrong because the input value may appear on the page but will not be submitted as usable form data.
- Removing the focus outline is wrong because keyboard users need a visible indicator of which control is currently active.
- Using ARIA instead of native HTML is wrong when a real label, button, fieldset, or input type can provide the same meaning more reliably.
Practice Questions
- 1 Write the HTML for a required email field with a visible label and the input name set to studentEmail.
- 2 A password field must be at least 8 characters and at most 20 characters. Write an input element that enforces these two length rules.
- 3 Create a radio button group with two choices, Yes and No, using one fieldset and one legend that asks, Do you want reminders?
- 4 Explain why a form with labels, fieldsets, and keyboard focus styles is more accessible than a form that only looks neat visually.
Understanding HTML Forms & Accessibility
A form has two jobs. It collects information in the browser, then it gives that information to a program that can process it. The browser does not decide whether an account can be created or whether a password is correct.
It can catch simple mistakes before submission, but the server must check every value again. Someone can alter page code or send a request without using the form at all.
This is why client-side validation improves the experience, while server-side validation protects the system. A well-built form gives clear feedback near the field where a problem occurred.
Labels do more than place words beside a box. They give each control an accessible name. A screen reader uses that name when it announces the control.
Clicking a properly connected label can place the cursor in its field or select its option. Placeholder text is not a replacement for a label. It often disappears when typing starts, may have weak contrast, and is not handled consistently by assistive technology.
Use placeholder text only for a short example of the expected format. Put instructions that users need before typing in visible text or in a linked hint.
Choices need careful design. Radio buttons represent one choice from a small set, such as a preferred contact method. Checkboxes represent independent choices, such as agreeing to terms or selecting interests.
A select menu can save space when there are many options, though it hides the choices until opened. Make option wording specific. Avoid labels such as Other when a user must explain what Other means.
When a choice reveals another field, the new field should appear clearly and receive sensible focus only when appropriate. Do not rely on color alone to show selected, required, or invalid states.
Keyboard testing finds problems quickly. Start at the browser address bar, press Tab, and move through the page as a keyboard user would. Every usable control should receive focus in a predictable sequence.
The focused item needs a clear outline or other visible indicator. Test Enter and Space because controls respond differently to these keys. A custom control made from a generic box often fails this test.
Native buttons, inputs, and details elements already contain behavior that would otherwise take substantial code to recreate. ARIA describes meaning for assistive technology, but it does not automatically create keyboard behavior, validation, or good error handling. Use it to fill a real gap, not to replace standard HTML.
Real forms often collect personal data, so every field should earn its place. Asking for less information reduces user effort and lowers privacy risk. Use autocomplete values when they fit, since browsers can fill common details accurately for many users.
Explain why unusual information is needed, especially phone numbers, dates of birth, or addresses. Error messages should state the problem and the fix. A message such as Enter a date after today gives useful direction.
After submission, provide a confirmation that says what happened. For important actions, include enough detail for the user to check the result without guessing.