Detected form widget required field asterisk explained

If you attach the detected form widget to a contact or quote form you already run, one of the first things visitors notice does not change: the little asterisk beside the fields they must fill in. The detected form widget required field asterisk explained here is really about two layers that have to agree. The visible marker tells sighted visitors "this one is mandatory." The underlying HTML required attribute is what actually blocks submission and lets assistive technology announce the requirement. The widget connects your existing form to WidgetJar for capture; it does not rewrite your labels, invent new validation rules, or replace the form's own markup. So if your asterisks were decorative before, they still are until you add the attribute and a legend that explains them.

This article walks through the label, legend, validation and error-message work that makes required fields make sense for every visitor, then gives you a short pre-launch test script. For the broader labelling picture, our guide to HTML form labels for lead forms covers wording and pairing; here we focus on the required state.

What the detected form widget does — and what it leaves alone

The detected form widget connects an existing HTML form to WidgetJar. You configure the widget in the panel, install the WidgetJar embed script on the registered website domain, and the form you already have becomes a capture point. Your field names, your action/method setup and your markup stay yours to edit.

That boundary matters. Validation is a property of your form, not of the widget. As MDN explains, HTML attributes define which controls are required and what format is acceptable, and the browser blocks submission and shows an error when the constraints fail (MDN: client-side form validation). The same page warns that client-side validation "should not be considered an exhaustive security measure" and that server-side checks still belong in the pipeline.

This is the same division of labour we describe in HTML form validation for static site contact forms: the browser gives instant feedback, and the receiving endpoint re-checks what it gets. MDN's walkthrough of how form data is sent and retrieved makes the same point from the other direction — the action value should point at something that can handle the data "including ensuring server-side validation." A visible asterisk does none of that work on its own.

A visible marker needs a programmatic flag behind it

An asterisk is a convention, not a mechanism. Screen readers do not announce a * character as "required" in any reliable, consistent way, and a visitor who cannot see the symbol gets no signal at all. The marker and the attribute do different jobs:

• The asterisk is a visual shorthand for sighted users scanning the form.
• The required attribute makes the field mandatory, exposes the :required state to CSS, and causes the browser to block submission with a message when the field is empty.
• A legend explains what the symbol means before the visitor hits it.

MDN notes that marking required fields is not just good practice but is required by WCAG accessibility guidelines, and that the common asterisk convention is exactly that — a convention you should explain (MDN: the required attribute).

Two practical rules fall out of this. First, only require what you actually need — every extra mandatory field is a visitor who abandons the form. Second, if a field is required, mark it in both places: required on the input and a visible cue on the label.

Write the legend once and place it before the fields

A legend is a single short sentence at the top of the form, not a tooltip hidden behind the asterisk. Something like:

Fields marked with an asterisk (*) are required.

Put it before the first field so the visitor reads it before they start filling anything in. If your design uses a different convention — a "(required)" suffix on each label instead of an asterisk — drop the legend, because the labels are now self-explanatory. What you must not do is use an asterisk with no explanation anywhere.

If a client insists on hiding the legend visually (some design systems do), render it in the DOM for assistive technology and keep it associated with the form's first field group. A common approach is a visually hidden element referenced from the form's help text. Whatever route you take, the explanation must exist in the accessibility tree even when it is not painted on screen.

Pair every label with its input so required state is announced

A label must be programmatically tied to its control with for and id, or by wrapping the input inside the <label>. When that pairing is correct, a screen reader announces the label text and the required state together as the visitor reaches the field. When it is missing — a <div> styled to look like a label, or placeholder text used as the only label — the visitor hears nothing useful.

A checklist for each field:

1. A real <label> element with for matching the input's id (or wrapping it).
2. The required attribute on the input itself.
3. The visible asterisk either inside the label text or next to it, with the legend above explaining it.
4. No placeholder acting as the label. Placeholders vanish as soon as typing starts and are inconsistently announced.
5. Grouped choices (radio buttons, consent checkboxes) wrapped in a <fieldset> with a <legend> describing the group.

Our accessible popup keyboard and focus checklist covers the same principle for dialogs: if a form appears inside a popup, focus has to land inside it and the labels have to be announced. The W3C's modal dialog pattern spells out the focus expectations for dialogs, including that focus moves into the dialog when it opens and returns to the invoking element when it closes.

Error messages must name the field and the fix

Native browser messages like "Please fill out this field" are a reasonable default, but they are generic. When you add your own message, make it specific and put it where the visitor can connect it to the field:

• Name the field and the problem. "Please enter your email address so we can reply" beats "Invalid input."
• Place the message next to the input, not at the top of the form or in a summary far away.
• Give the message a stable id and link it to the field with aria-describedby so it is announced when focus reaches the input.
• Move focus to the first invalid field on submit, so keyboard and screen-reader users land where the fix is needed.
• Do not rely on colour alone. Red borders need accompanying text.

Our contact form error messages guide goes deeper on wording and inline placement; the short version is that every message should answer "what is wrong" and "what do I type instead."

When native validation is enough and when to add a message

Start with the built-in constraints: required, type="email", minlength, maxlength, min, max, pattern. They are fast, they need no JavaScript, and browsers already know how to focus the offending field. Add a custom message only when the browser default would confuse a visitor — for example, a pattern field where the format needs explaining, or a consent checkbox where the wording matters legally.

If you do write custom validation in JavaScript, keep the HTML constraints in place as a fallback, and make sure the custom message is in the DOM and linked to the field before it is needed. Never suppress the native checks and leave nothing in their place.

A five-minute keyboard and screen-reader test before you publish

Run this on the live page, with the widget installed, after any change to the form:

1. Tab through the form without touching the mouse. Does focus reach every field in a logical order? Is the asterisk's meaning explained before the first field?
2. Submit the form empty. Does the browser stop submission, focus the first required field, and show a message you can read?
3. With a screen reader on (VoiceOver, NVDA or TalkBack), tab to each required field. Is the label read aloud, and is the required state announced?
4. Trigger each error. Does the message appear beside its field, and does it get announced when you return to the input?
5. Fill everything correctly and submit. Does the submission actually reach your endpoint? Check the network request in DevTools, as the MDN data-sending walkthrough shows how to inspect it.
6. Test one popup instance if you use one. Confirm focus enters the dialog and returns to the trigger on close, per the W3C dialog pattern.

Common mistakes to fix today

• An asterisk with no legend anywhere on the page.
• Placeholder text standing in for a label.
• Error text in a banner at the top of the page, far from the field it refers to.
• required on a field the label marks as optional (or the reverse).
• Colour-only error states with no text.
• Marking every field required "to be safe," which just drives visitors away.

Fix the labelling and the attribute first; the widget does not need to change for any of it.

Where to go next

Once your labels, legend and error messages line up, the detected form widget has a clean form to work with. Set it up from the detected form widget page, install the embed script on your registered domain, and connect the form you already run — no rebuild required. Then re-run the five-minute test script above, because a form that works with a mouse is not the same as a form that works for everyone.