A design system needs inline, styled, consistently worded error messages on every form. How would you decide between keeping the browser's native validation bubbles and switching them off to render your own, and what must you reproduce if you take it over?

## What you get for free With no script at all, the browser already: blocks submission, picks the first invalid control, scrolls it into view, focuses it, and shows a message describing the failure in the user's own browser language. That is a complete, accessible, zero-maintenance error flow. Any decision to replace it starts by acknowledging that it is genuinely good. ## What it cannot do Five limits drive nearly every decision to replace it: 1. **No styling.** The bubble is browser chrome. You cannot change its font, colour, shape or position, and it looks different in every engine — an immediate mismatch with a design system. 2. **One at a time.** The browser reports the first failure only. A user fixing a six-field form gets six sequential submit-and-discover rounds instead of a list. 3. **Transient.** The bubble is dismissed on blur or after a short timeout, so the message is gone the moment the user looks away from the field to think. 4. **Wrong language.** The text comes from the browser's UI locale, not from the page's `lang`. A Spanish-language product viewed in an English browser shows English errors it never wrote. 5. **Not in the DOM.** You cannot select it, log it, test it with a DOM query, or reference it from the field. That last one matters most: a design system usually wants each field pointing at its own visible message. A sixth, quieter one: because the constraint text is the browser's, you cannot say anything domain-specific. "Please match the requested format" is not "Card numbers are 16 digits with no spaces." ## The decision Keep the native reporting when the form is short, internal, or a prototype; when localization tracks the browser anyway; when nobody is going to maintain custom error code. Its focus behaviour is correct out of the box and that is worth more than teams assume. Take it over when errors must be styled and inline, when several failures should be visible at once, when copy must be domain-specific and in the page's language, or when errors must persist while the user works. In practice a component library crosses that line almost immediately. What you should not do is mix them — a native bubble popping over your own inline message is worse than either alone. ## Taking it over without throwing away the API The crucial insight is that switching off the UI does not switch off the machinery. `novalidate` on the `<form>` stops the automatic validate-and-report at submit time; it does not stop constraints from being evaluated. `validity`, `checkValidity()`, `validationMessage`, `:invalid` and `:user-invalid` all keep working exactly as before. So the constraint attributes stay in the markup as the single declaration of the rules, and you supply only the presentation: ```html <form novalidate> <label for="email">Email</label> <input id="email" name="email" type="email" required aria-describedby="email-error"> <p id="email-error" hidden></p> <button>Sign up</button> </form> ``` ```js form.addEventListener('submit', (event) => { if (form.checkValidity()) return; // let it submit event.preventDefault(); const bad = [...form.elements].filter((el) => el.willValidate && !el.checkValidity()); bad.forEach(showInlineError); bad[0].focus(); // reproduce what the browser did }); ``` An alternative that keeps the browser's own trigger is to leave `novalidate` off and listen for the `invalid` event on each control, calling `preventDefault()` inside it to suppress that control's bubble while rendering your own. Both are legitimate; the `novalidate` route gives you full control of ordering and of showing all failures at once. ## The obligations you inherit Once you own the reporting you own everything it was doing: - **Focus.** Move focus to the first invalid control on a blocked submit. Skipping this is the single most common regression, and it strands keyboard and screen-reader users who have no idea where the problem is. - **Association.** Each field's message must be programmatically connected to the field, not merely adjacent to it, so it is conveyed when the field receives focus — and the field marked as invalid programmatically at the same moment it is marked visually. - **Timing.** Decide when errors appear and apply it uniformly. Silent until submit and eager afterwards is the usual rule; validating on every keystroke is noise. - **Copy.** You now write and translate every message, including the ones the browser used to generate for free. - **Multiple failures.** If several fields fail, decide whether a summary at the top of the form is warranted for longer forms. ## The line that must be said Whichever way you go, none of it is a security control. Every constraint expressed in markup is advisory — it exists to catch honest mistakes at the point of entry. The server enforces the same rules independently, and the two definitions should be generated from one source where possible so they cannot drift apart into a form that submits values the backend rejects. ## Weak answers "Add `novalidate` and write validation in JavaScript from scratch" throws away the declarative constraints for no reason. "Style the bubble with CSS" is not possible. And an answer that never mentions focus or programmatic association has not actually replaced the native behaviour — only its appearance.