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.