HTML forms are the primary way that web pages collect information from people: a search box, a login screen, a checkout page, and a survey are all forms. At its core, a form is a container element, <form>, that groups a set of controls (text boxes, checkboxes, radio buttons, drop-down lists, buttons) and defines what should happen when the user submits them. Two attributes on the <form> element do most of that work: action, which names the URL that will receive the data, and method, which says how the data travels (most commonly GET or POST).
In this course, forms are the bridge between the browser and server-side processing. Before you can validate input or handle it in application code, you need a clear mental model of form structure: the <form> wrapper, the controls inside it, the name attribute that labels each piece of submitted data, the <label> elements that connect text to controls, and the submit button that triggers the request. Getting this structure right from the start makes later work on accessibility and validation far easier.
As you watch the videos below, pay attention to a few things: how the <form> tag is opened and closed and what sits inside it, where action and method appear and how they are described, how each input is given a name and an associated label, and how different input types change what the user sees and what gets sent. Try typing along with at least one example rather than only watching.
A tutorial from CodeWithHarry's Sigma Web Development series covering forms and input tags in HTML. Based on its title and series position, it should introduce the <form> element, walk through the common input tags and their type values, and show how these pieces fit together into a working form. At roughly fifteen minutes, it has room to demonstrate several control types and discuss submission attributes.
CodeWithHarry is a widely followed web development channel, and this lesson sits inside a structured beginner course, so the material is presented in sequence rather than in isolation — a good match for the "What Is an HTML Form?" and "Overview of Form Structure" subtopics.
This Code Range tutorial builds a basic sign-up form from scratch using the form, label, input, and button elements. The description indicates it also covers different input types, so you should see how a realistic form is assembled control by control. It is part of a numbered HTML tutorial series aimed at beginners.
Building one complete form end to end is the clearest way to see overall form structure, and the explicit focus on label and button elements supports the semantic and accessibility habits emphasized in this module.
A condensed seven-minute overview from Learndev that moves through form basics, a login form example, input labels, and placeholder text, according to its listed chapters. It is organized with timestamps, so you can jump directly to the segment you need. Expect a fast but focused tour of the essential pieces.
This is a useful quick review or first pass before the longer tutorials, and its chapter markers make it easy to revisit specific subtopics such as the form element or labeling inputs.
Together these videos establish the foundation that the rest of the module builds on. All three demonstrate constructing a form from the <form> element, inputs, labels, and buttons, which directly supports MO1's emphasis on well-structured, semantic forms; the discussion of action and method introduces the submission mechanics you will compare in detail for MO2. They do not themselves cover HTML5 validation attributes, the Constraint Validation API, or accessible error-feedback strategies (MO3, MO4, MO5) — those build on the structural understanding you gain here, so treat these videos as the necessary starting point rather than the full picture.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Forms are the main way users send data to a web application. Every search box, login screen, checkout page, and survey is built from the same small set of HTML elements: the form element itself, plus input, select, option, textarea, button, and label. What makes forms interesting is that a single element — input — changes behavior entirely based on its type attribute, producing anything from a simple text box to a date picker, a color swatch, a file chooser, or an invisible field that carries data the user never sees.
In this course, this topic is the foundation for everything that follows in the module. Before you can validate input, choose between GET and POST, or wire up the Constraint Validation API in JavaScript, you need to know which control to reach for and how to mark it up correctly. Choosing the right input type is also your first accessibility and usability decision: type="email" and type="tel" change the on-screen keyboard on mobile devices, radio buttons communicate mutually exclusive choices, and a properly associated label makes a control usable with a screen reader or by clicking the text next to it.
As you watch the videos below, pay attention to a few recurring details: how the name attribute (not the id) determines what gets submitted, how label and id are paired, how radio buttons in the same group share a name while checkboxes usually do not, and how select/option differ from a list of radios. Try pausing and rebuilding each example yourself — a registration or contact form that uses text, password, email, radio, checkbox, select, textarea, and submit is a good practice target.
A thorough tutorial lesson on the form element and the input tag, covering how forms are structured and how different input types behave. Based on its length and series format, it likely walks through building a form from scratch and demonstrates a range of attributes and control types rather than just listing them. It is part of CodeWithHarry's larger web development course, so concepts are introduced in sequence with hands-on coding.
CodeWithHarry is a widely followed instructor with a very large audience for this lesson, and the extended runtime allows coverage of multiple input types in one place, making it a strong primary overview for this topic.
This lesson builds a basic sign-up form using form, label, input, and button elements, and introduces several different input types along the way. The sign-up scenario naturally brings in text and password fields plus a submit control, so you see the elements working together rather than in isolation. It is presented as part of a beginner-oriented HTML tutorial series.
It explicitly pairs labels with inputs, which directly supports the semantic and accessibility expectations of this module, and the single realistic form example ties the separate subtopics into one coherent structure.
A compact, seven-minute explanation that starts by clarifying what an HTML form actually is and then moves directly into the markup. Expect a fast-paced tour of the form element and common input controls rather than a slow, step-by-step build. Its brevity makes it well suited to a first pass or to a quick review before an assignment.
It is an efficient summary that reinforces the same core elements covered in the longer videos, which is useful either as a preview of the topic or as a refresher when you are coding your own form.
These videos target MO1 most directly: they demonstrate how to assemble a working form from the correct elements — form, input across multiple types, select, textarea, label, and submit — which is the prerequisite skill for producing well-structured, semantically labeled forms. By showing the form element and its attributes, they also preview the submission concepts formalized in MO2. Because input type choice is itself the first layer of data constraint (an email field accepts different content than a plain text field), the material lays the groundwork for the HTML5 validation attributes in MO3 and for the JavaScript-driven validation and feedback strategies in MO4 and MO5, which build on correctly marked-up controls and their associated labels.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
A form is only usable if every control tells the user what it is for. The label element is the HTML mechanism that creates that connection: it attaches visible text to a specific input so that screen readers announce the right name, and so that clicking the text moves focus into (or toggles) the control. You can associate a label explicitly, by matching the label's for attribute to the input's id, or implicitly, by nesting the input inside the label element. Both approaches are valid, but explicit association is generally safer and easier to style.
Some controls only make sense as a set. Radio buttons for a shipping method, or checkboxes for a list of interests, need a group-level question in addition to individual labels. That is the job of fieldset, which wraps related controls, and legend, which supplies the group's name. Without them, a screen reader user may hear "Standard, radio button" with no idea what question is being answered.
As you watch the videos below, pay attention to three things: how each presenter writes the markup (for and id pairs, nested labels, fieldset and legend structure), how assistive technology announces a labeled versus an unlabeled control, and the common mistakes they warn against, such as using placeholder text as a substitute for a label, mismatched or duplicated id values, or relying only on visual proximity. These same habits carry directly into the validation work later in this module, since error messages also need to be tied to the control they describe.
A short, focused overview of what makes a web form accessible, with specific attention to using the label element correctly so that every control has a programmatically associated name. In under five minutes it frames the problem from the user's point of view: who struggles with poorly built forms and why proper labeling fixes it. Expect practical guidance you can apply immediately to the markup you write in this module.
Aquent Gymnasium produces professional training on web accessibility, and this clip targets exactly the core subtopic of the lesson, the purpose and correct use of the label element, in a concise format that works well as an introduction before the longer tutorials.
A longer walkthrough aimed at transforming an ordinary HTML form into an accessible one, covering how form elements should be marked up and connected to their descriptive text. Being part of a broader accessibility playlist, it situates form labeling within general accessibility practice rather than treating it as an isolated trick. Expect hands-on demonstration of markup changes and the reasoning behind them.
Its sixteen-minute length allows the presenter to work through association techniques and structural grouping in more depth than a quick overview, which supports the explicit, implicit, and fieldset or legend subtopics.
This tutorial narrows in on specific control types, including text boxes, checkboxes, and buttons, and shows how to make each of them fully accessible. Because checkboxes and radio buttons are the controls that most often need group-level naming, this is where grouping concerns typically surface alongside individual labeling. Expect control-by-control treatment with demonstrations of the correct markup.
It complements the previous video by moving from general form accessibility to the particular controls where labeling mistakes are most common, reinforcing both individual labels and the need to name groups of related inputs.
These three videos support MO1 most directly: together they demonstrate how labels, fieldsets, and legends combine with appropriate input types to produce a semantically correct, accessible form, and they model the markup patterns you will be expected to write. The emphasis on associating descriptive text with a specific control also prepares you for MO4 and MO5, where inline error messages and ARIA announcements must be tied to the field they refer to in order to be announced correctly by assistive technology. They do not address GET versus POST (MO2) or HTML5 validation attributes (MO3); those outcomes are covered by other materials in this module.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
A form is only useful if the data it collects actually reaches somewhere. That delivery is controlled by a small set of attributes on the form element: action tells the browser where to send the data, method tells it how to send it (most commonly GET or POST), and enctype tells it how the data should be encoded on the way. Together these three attributes determine the shape of the HTTP request your server receives.
In this course the distinction matters because you will build both the front end and the code that consumes the submitted data. GET appends name/value pairs to the URL as a query string, which makes it visible, bookmarkable, cacheable, and limited in length — fine for searches and filters, wrong for passwords or anything that changes state. POST places the data in the request body, which suits larger payloads, sensitive values, and file uploads. File uploads in particular require enctype set to multipart/form-data, while the default application/x-www-form-urlencoded handles ordinary text fields.
As you watch the videos below, pay attention to three things: what the URL looks like after submission, what the request actually contains, and which attribute combination the presenter uses for each scenario. Also notice how submission is triggered — a submit button, the Enter key inside a text input, or JavaScript — because later in this module you will intercept that moment to run validation.
A beginner-friendly walkthrough of HTML forms and input tags from CodeWithHarry's Sigma Web Development series. Based on its title and placement early in the course, it is likely to cover building a form element, the common input types, and the attributes that control submission such as action and method, with hands-on code examples.
It gives you a clear, example-driven foundation for the form element and its submission attributes, which is the starting point for every other subtopic here.
Austin Gil walks through what it takes to upload a file using plain HTML, describing three main steps. Expect coverage of the file input type together with the form attributes required for uploads — notably setting the method to POST and the enctype to multipart/form-data so the binary data is encoded correctly.
This is the clearest practical demonstration of the enctype subtopic, showing exactly why the default encoding fails for files and what to use instead.
This video asks how a server can tell whether an incoming HTTP request came from a standard HTML form submission or from JavaScript. It is likely to inspect the request headers and content type produced by each path, highlighting how the browser's native submission behavior differs from a scripted fetch.
It reinforces how the browser triggers submission and what encoding it applies by default, connecting the action/method/enctype attributes to the actual HTTP request your server sees.
These videos support MO2 most directly: the CodeWithHarry tutorial establishes the action and method attributes and lets you observe the difference between a query string and a request body, while the Akamai DevRel videos extend that into encoding choices, showing why multipart/form-data is required for file uploads and how browser-generated requests differ from JavaScript-generated ones. The form-building walkthrough also reinforces MO1 by modeling well-structured markup with appropriate input types, and the discussion of how submission is triggered prepares you for the validation work in MO3 and MO4, where you will hook into the submit event before data ever leaves the page.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
HTML5 gives you a surprising amount of validation power before you write a single line of JavaScript. By adding attributes directly to your input elements — required, minlength, maxlength, pattern, min, max, and the input type itself — you tell the browser what counts as acceptable data, and the browser enforces it at submission time with built-in error messages. This is called constraint validation, and it is the foundation layer that any custom JavaScript validation you write later should build on, not replace.
In this course, built-in validation matters for two reasons. First, it is the cheapest possible way to protect data integrity and guide users: a single required or type="email" attribute catches a large share of common mistakes. Second, it is accessible by default — browsers surface these constraints to assistive technology and handle focus management for you, which is harder to get right by hand. Remember, though, that client-side validation is a usability feature, never a security boundary; server-side validation is still mandatory.
As you watch the videos below, pay attention to a few things: which attributes apply to which input types (minlength and maxlength work on text-like fields, while min and max work on numbers and dates), how pattern uses a regular expression that must match the entire value, and how title supplies the hint text that browsers show when a pattern fails. Also notice the difference between placeholder (a disposable example inside the field) and a real label — placeholder is a hint, not a substitute for labeling.
A focused, short tutorial on the pattern attribute: how to attach a regular expression to a text input so the browser rejects values that do not match the required format. Based on the title and description, it should walk through writing patterns for common cases and customizing how validation behaves on a form. Expect discussion of how pattern interacts with the field's value and the message shown when the pattern fails.
Pattern is the most conceptually difficult subtopic here, and this video isolates it rather than burying it in a general forms overview. Envato Tuts+ is an established production channel with concise, well-edited tutorials, which makes this a good targeted companion to the broader videos.
A beginner-oriented tutorial devoted specifically to HTML form validation, covering the built-in attributes you use to constrain input without scripting. Given its length and framing as part of a full HTML course, it likely demonstrates required, length limits, type-based checks, and format constraints across a sample form. The video closes with interview-style questions that let you self-check your recall of the attributes.
It is the closest match to the topic as a whole, treating validation as the main subject rather than a side note, and the end-of-video questions give you a quick way to test whether the attribute rules actually stuck.
A widely watched walkthrough of HTML forms and input tags: the form element, the range of input types, and the attributes that configure them. As a general forms lesson it establishes the markup context — fields, types, and attributes like placeholder — that validation attributes are attached to. It is the broadest of the three videos and the best starting point if forms are still new to you.
CodeWithHarry's tutorial is clear and extremely well-reviewed by learners, and it grounds the semantic type constraints and placeholder subtopics in the overall structure of a form, so the validation-specific videos make more sense afterward.
Together these videos target MO3 most directly: the beginner validation tutorial surveys required, length, and type-based constraints, while the pattern-focused video goes deep on format enforcement with regular expressions and title-based hints. The CodeWithHarry forms overview supports MO1 by reviewing input types and form markup, which is the structure validation attributes are applied to, and it also helps you distinguish placeholder hints from proper labels. None of these videos covers GET versus POST in depth (MO2) or the JavaScript Constraint Validation API and feedback strategies (MO4, MO5) — those outcomes are addressed in other resources for this module, and the built-in attributes you learn here are the layer that your later JavaScript work will extend.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
HTML5 validation attributes like required, pattern, and min cover many common cases, but real applications often need more: passwords that must match, fields that are required only when another option is selected, usernames checked against a format your business defines, or error messages worded for your users rather than the browser's defaults. Custom JavaScript validation fills that gap. Using the Constraint Validation API (properties and methods such as validity, checkValidity(), and setCustomValidity()) together with event listeners, you can intercept form submission, run your own validation functions, and decide exactly what the user sees and when.
In this module you are building on the semantic, accessible forms from earlier topics, so the goal is not just "stop bad data" but "tell the user clearly what went wrong." That means inline error messages placed near the field they describe, markup that screen readers can announce (labels, aria-describedby, aria-invalid, live regions), and a feedback strategy that balances on-submit checking with real-time input and blur events so users are not scolded mid-typing. Finally, you will see why it pays to organize this logic into a reusable validation module instead of copy-pasting the same if-statements for every field.
The three videos below walk through practical implementations. As you watch, pay attention to the HTML structure that makes inline errors possible (where the error container sits relative to the input), which events the author listens for, how error text is added and cleared, and where the demonstrated approach could be improved for accessibility or reuse. Treat the code as a starting point you will refactor, not a final answer.
This tutorial focuses on structuring an HTML form so that an error message can be displayed directly beneath each input field, then using JavaScript to populate and clear those messages. Expect to see the markup pattern (input plus a dedicated error element), the script that checks each field, and how the message is shown when validation fails. Downloadable source code is referenced in the description so you can follow along.
It targets the inline error message subtopic head-on, and because it starts from the HTML structure it shows why markup decisions determine how easily you can attach per-field feedback.
Part of a short series, this video sets up the HTML structure of a registration form as the foundation for JavaScript validation. It is likely to cover the form fields, labels, and containers you need in place before any validation script is written, giving you the scaffolding used in the follow-up video.
It reinforces the connection between well-formed markup and maintainable validation code, which is exactly the groundwork needed before writing custom validation functions or a reusable module.
The follow-up installment applies JavaScript validation to the registration form, concentrating on email validation. Expect a demonstration of reading the field value, testing it against a pattern or rule, and reporting the result back to the user on the page.
Email checking is a classic case where you decide between a browser default message and your own logic, making it a compact example of writing a custom validation function and wiring it to form events.
These videos sit squarely on MO4: each one demonstrates intercepting a form with JavaScript, running custom checks, and rendering inline error messages rather than relying solely on browser defaults. The Step by Step pair also reinforces MO1 by showing that accessible, well-structured markup is a prerequisite for per-field error reporting, while the Digital Fox video gives you a concrete pattern to evaluate against the usability and accessibility trade-offs discussed in MO5 — compare its on-submit messaging to real-time input and blur feedback, and consider what ARIA attributes you would add. Together they complement, rather than replace, the HTML5 attribute work in MO3: use built-in constraints first, then layer custom logic where the attributes cannot express the rule.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
A form that rejects input without explaining why is a dead end for the user. Validation feedback is the layer of messaging and visual cues that tells someone what went wrong, where it went wrong, and how to fix it. In this topic you will look at inline error messages placed next to the field they describe, visual indicators of field state (valid, invalid, required, focused), and the trade-offs between validating as the user types versus waiting until submit.
You will also work with the HTML5 Constraint Validation API, which gives you programmatic access to validity states and lets you replace the browser's default bubble messages with your own styled, well-placed text. Because error text that is only visible is not enough, the topic extends into accessible error announcements using ARIA attributes such as aria-invalid, aria-describedby, and live regions, plus summary error lists at the top of long or complex forms. Finally, you will consider when placeholder text helps and when it quietly hurts, and how persistent helper text is usually the safer choice.
The three videos below come from Pope Tech, a producer focused on web accessibility testing. They approach the topic from the evaluation side: how to check whether a form actually communicates its errors to all users, what ARIA is really for, and how an automated tool reports form problems. While watching, pay attention to the checks being performed and ask yourself how you would build a form that passes them the first time, and note any guidance about labels, error identification, and ARIA misuse that you can apply to your own validation code.
A walkthrough of what makes an HTML form accessible, paired with a demonstration of how to test one against a checklist. Expect coverage of items such as labeling, keyboard operation, required field indication, and whether errors are identified and described in a way assistive technology can reach.
It gives you a concrete evaluation checklist you can run against your own forms, which directly supports the inline error message, field state, and accessible announcement subtopics.
An introduction to ARIA: what the specification is for, the first rule of ARIA (do not use ARIA when native HTML will do), and examples of how incorrect ARIA degrades the experience for assistive technology users. It frames ARIA as a supplement to semantic markup rather than a replacement for it.
Accessible error announcements depend on correct ARIA usage, and this video sets the ground rules so you apply attributes like aria-invalid and aria-describedby intentionally instead of by habit.
A practical demonstration of testing a form with the WAVE browser extension, reviewing the kinds of results WAVE returns for form elements and how to interpret and fix them. The video reflects the updated version of the tool and connects each reported issue back to a remedy in markup.
It turns accessibility feedback into something you can check immediately in the browser, giving you a fast feedback loop while building and validating the forms assigned in this module.
These videos reinforce the accessibility half of the module's outcomes. The form accessibility checklist and WAVE testing demonstrations help you verify that the labels, fieldsets, and semantic structure required by MO1 are actually present and announced, and that error identification works for the inline messages you build with the Constraint Validation API in MO4. The ARIA video supplies the conceptual grounding needed to choose appropriate attributes for error announcements rather than over-applying them. Together they give you the evaluation criteria called for in MO5, so you can weigh real-time versus on-submit feedback, ARIA live announcements, and summary error lists against measurable usability and accessibility outcomes instead of personal preference.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.