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.