Show Accessible Form Validation Feedback

The experience you are building

This form will keep feedback beside each field after a submission attempt. As a learner corrects a value, that field’s message will disappear; a fully valid check will confirm a local validation result.

This is different from a browser’s temporary validation popup. A popup can help in the moment, but it is not persistent inline feedback that remains visible on the page until your code updates it.

“Persistent” here means within the current page session. It does not mean saving messages or values across refreshes or visits.

Create the local starter

Make one folder and create these three files inside it: index.html, styles.css, and app.js. Then open index.html in your browser.

This starter deliberately retains the browser’s normal constraint behavior for now. Its empty error and status elements are stable page structure that later steps will fill without replacing the inputs.

File: index.html

File: styles.css

File: app.js

Try the current starter

1. Refresh the page, leave both fields empty, and select Check form. Your browser may show its own temporary required-field feedback.
2. Enter Riley and not-an-email, then check again. The email input should receive the browser’s native feedback.
3. Replace the email with riley@example.com and check once more. The page should not navigate away.

At this point, the empty inline message areas are expected: later steps will turn them into the persistent feedback shown in the target diagram.

Native HTML constraints already answer a basic question: is this control valid right now?

Call field.checkValidity() for one control or form.checkValidity() for the form. Each returns a Boolean:

• true means the checked control, or every form control, currently passes its constraints.
• false means at least one relevant constraint fails.

For a field, field.validity explains which kind of constraint failed. In this form, an empty required control produces valueMissing, while an email value with the wrong format produces typeMismatch.

A field can be invalid even though its value is still present in the input. Validity describes the current value; it does not erase or replace it.

Add this temporary inspection helper after the existing DOM references in app.js. Refresh the page and inspect the console. With the initial empty form, both fields fail because they are required.

Calling checkValidity() tells you whether constraints pass. It does not build a stable inline error element, associate that element with a field, or keep feedback visible beside the field. Those are separate rendering tasks you will add later.

A custom validity message becomes part of the browser’s constraint validation result. When it is nonempty, the field has validity.customError === true and is invalid—even if its built-in constraints otherwise pass.

The browser does not remove an old custom message when a person changes the input. Refresh the custom rule from the current value every time you inspect this field:

1. Clear the previous custom message.
2. Check the current value against the reserved name.
3. Add the message only when the exact value is admin.
4. Then read the current validity result.

This rule is case-sensitive: admin is reserved; Admin is not.

Add these helpers to app.js after the existing DOM references. They update only the native custom-validity state; field messages will be rendered in a later step.

The starter already contains the stable feedback structure and the existing state.errors object. Reuse them—do not add another const state declaration, and do not paste a second copy of the field markup.

Input values stay in the native controls. state.errors stores only the messages currently displayed beside those controls. Each input keeps two descriptions at all times: its helpful hint and its initially empty error paragraph. Rendering changes the error paragraph's text; it does not replace the input or alter its aria-describedby value.

Reference only: this block already exists in index.html. Keep it in place; do not add a duplicate with the same IDs. The existing .hint and .error-message classes match the supplied CSS.

Use authored, concise messages rather than copying validationMessage, whose wording depends on the browser and locale. Before reading display-name validity, refresh its custom rule from the current value. This single validateField(field) path is then used by whole-form checks now and by recovery and submission behavior in later steps.

An empty string means no displayed error. The existing CSS makes the error words visible and adds a border only when aria-invalid="true"; color is reinforcement, not the only signal.

Add this one DOM reference alongside the existing references at the top of app.js. Do not change or redeclare the existing form, inputs, fields, or state.

Add these functions below the refreshDisplayNameRule() helper from the previous step. They store only field feedback in the existing state.errors object. The display-name rule is refreshed before any validity flag is inspected.

Add this renderer below the validation functions. It updates stable nodes with textContent, retains both existing aria-describedby references, and never changes focus. It also keeps the already-present status element synchronized with state.status, which is empty until a later step uses it.

An input event occurs while someone is still editing, so it should not introduce first-time errors. Use state.hasSubmitted as a gate: while it is false, typing leaves the displayed field errors empty.

Once an attempted check has occurred, the same event supports recovery. Revalidate only the field being edited, replace only its entry in state.errors, then render the updated state. A corrected field can recover immediately without erasing an error beside the other field.

Clear state.status on every edit. Any result text describes older values and must not remain visible after a value changes.

Add this complete registration after render() in app.js. It uses the existing fields, state, validateField(), and render() from earlier steps. The listener clears an older result on every edit, but changes displayed field feedback only after feedback is active.

The listener has a deliberately narrow responsibility. It does not validate every control, change hasSubmitted, or decide where focus belongs. Those actions belong to the submission path added later.

When the edited field is Display name, validateField(field) refreshes the custom rule before reading validity. Therefore, changing exact admin to Riley can clear that field’s displayed error. It must not clear an existing Email address error.

A form can be submitted by clicking Check form or by using the keyboard from a form control. Handle the form’s single submit event so both routes follow the same path.

On every attempt, prevent the browser’s default action first. Then mark that an attempt occurred, clear any result from an earlier form state, validate both fields, and render every current inline error. Only after rendering should a rejected attempt move focus.

This order means a person can see all problems at once, while focus starts at the first problem in document order: Display name, then Email address.

Add this after the existing field input listeners. The starter button remains disabled until this handler is attached. validateForm() refreshes both entries in state.errors; render() displays those current errors without replacing either input.

The Boolean captured in isValid decides whether focus moves. Because validation has already refreshed the custom rule, checking each field here identifies the current first invalid control.

Add after the existing input listeners in app.js.

Use the status region already in the document

index.html already contains an empty, stable result region:

<p id="form-status" role="status"></p>

Keep that element in the initial document. Do not create it only when the form becomes valid. Its role="status" communicates an update politely when its text changes.

The complete render() function from Step 4 already updates this region from state.status, after it renders field errors and aria-invalid. Reuse that complete renderer unchanged; do not redeclare formStatus or replace render() with a partial version.

A status update is non-urgent. Do not move focus to the status region and do not change it to role="alert".

A fresh whole-form pass is required before setting completion feedback. validateForm() refreshes both entries in state.errors; only when it returns true have all displayed field errors cleared.

This result says only that the browser checked the current local values. It does not mean data was sent, saved, registered, or accepted by a server. Browser validation is useful user feedback, not a security guarantee.

Replace the submit listener from Step 6 with this complete version. Keep the existing input listeners, complete render() function, form.noValidate = true, and enabled button code. Do not add a second submit listener.

On an invalid attempt, this handler still renders every field error and focuses the first invalid field. On a valid attempt, it sets state.status and renders, with no focus() call.

The existing input listener already clears state.status before it renders an edit. That removal matters because a prior result described an earlier set of values. Test a valid check with Riley and riley@example.com, then edit either field: the result should disappear while your typing focus stays put.

Run this compact matrix against the finished local page. The production implementation from the earlier steps already refreshes the reserved-name rule before it reads validity; do not remove or replace that working behavior.

Use browser developer tools only if you want to inspect attributes. In every case, each input must retain its two stable aria-describedby references: its hint ID and its error ID. The result is a local interface check only: no demonstration value is sent, saved, or registered.

A stale custom error is a diagnostic case, not a missing part of the finished implementation. Your existing refreshDisplayNameRule() should already clear an earlier custom-validity state before it evaluates the current display-name value.

Use the isolated exercise below to reconstruct the two missing expressions from a deliberately faulty version of that helper. If your live page ever keeps the reserved-name error after the value changes, compare its one existing helper with this pattern; do not add a second helper or a second listener.