Sometimes the simplest form pattern is the one you repeat ad infinitum: “Type it once, then type it again.” We do it for password confirmations, email verification, and any flow where a typo creates expensive follow-up work. I released a small web component to handle that pattern cleanly: form-matching-fields.
Sometimes the simplest form pattern is the one you repeat ad infinitum: “Type it once, then type it again.” We do it for password confirmations, email verification, and any flow where a typo creates expensive follow-up work. I released a small web component to handle that pattern cleanly: form-matching-fields.
Sometimes the simplest form pattern is the one you repeat ad infinitum: “Type it once, then type it again.” We do it for password confirmations, email verification, and any flow where a typo creates expensive follow-up work. I released a small web component to handle that pattern cleanly: form-matching-fields.
The component wraps two related form fields and adds validation to ensure they match. It’s intentionally additive, which means it works with native browser validation rather than trying to replace it.
\nThe API is intentionally simple:
\n<form-matching-fields>\n <label for=\"password\">Password</label>\n <input id=\"password\" type=\"password\" required />\n\n <label for=\"password-again\">Password again</label>\n <input id=\"password-again\" type=\"password\" required />\n</form-matching-fields>The component evaluates the first two eligible text-type inputs it contains and applies mismatch validation to the second one when both fields have values.
\nTo keep behavior predictable, the component only considers descendant input elements of these types:
It ignores disabled and readonly controls, which helps prevent false positives when you have conditional or locked fields in the same wrapper.
One of the core goals here was to avoid stepping on existing validation rules. In practice, that means:
\nrequired or type mismatch), this component won’t mask it.That last point is especially useful in larger forms where multiple constraints overlap. You don’t want one helper trying to be the sole source of truth.
\nBy default, the component uses this template for the validation message:
\n\n\nThe fields “{label_1}” and “{label_2}” should match
\n
It smartly resolves the labels ({label_1} and {label_2}) from your markup in this order:
<label for> text<label> textaria-labelnameidYou can override it with the validation-message attribute:
<form-matching-fields\n validation-message=\"Please ensure {label_2} matches {label_1}.\"\n>\n <label for=\"email\">Email</label>\n <input id=\"email\" type=\"email\" required />\n\n <label for=\"verify-email\">Verify email</label>\n <input id=\"verify-email\" type=\"email\" required />\n</form-matching-fields>In most forms, that gives you a clear error message without extra setup.
\nI put together a demo of the web component over on GitHub:
\nYou can explore the source, file issues, and suggest enhancements in the form-matching-fields repository.
It’s just a radio button. Paul’s teardown is a good illustration of how far modern front-end practice can drift from the simple, robust platform primitives we already have.
","content_html":"It’s just a radio button.
\nPaul’s teardown is a good illustration of how far modern front-end practice can drift from the simple, robust platform primitives we already have.
\n\n\nIf you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
\n
Reading this reminded me of a pair of pieces I’ve linked to before: Making radio buttons and checkboxes easier to use and There can be only one: Options for building “choose one” fields.
\nWe have spent an astonishing amount of time and energy overcomplicating a control HTML already gives us, often in the name of developer experience or styleability. More often than not, all we’re really doing is trading resilience for ceremony.
\n","social_text":"It’s just a radio button. We really don’t need two component libraries, ARIA role remapping, and client-side JS to do what HTML already does.","url":"https://www.aaron-gustafson.com/notebook/links/the-incredible-overcomplexity-of-the-shadcn-radio-button/","external_url":"https://paulmakeswebsites.com/writing/shadcn-radio-button/","tags":["HTML","accessibility","web development"],"date_published":"2026-04-29T12:15:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/making-keyboard-navigation-effortless/","title":"🔗 Making keyboard navigation effortless","summary":"I’m very excited by focusgroup: a declarative way to handle a bunch of keyboard-navigation patterns that currently require a lot of brittle JavaScript.
I’m very excited by focusgroup: a declarative way to handle a bunch of keyboard-navigation patterns that currently require a lot of brittle JavaScript.
This is exactly the sort of thing I want to see the platform absorb. We’ve spent years rebuilding common interaction patterns with roving tabindex, focus management, and piles of event handling code. If the browser can take more of that on, we get lighter pages, more consistent experiences, and fewer opportunities for developers to get keyboard support wrong.
This is a terrific demonstration of how far the platform has come: a richly styled select that leans on native semantics, native accessibility, and progressive enhancement instead of fighting the browser.
This is a terrific demonstration of how far the platform has come: a richly styled select that leans on native semantics, native accessibility, and progressive enhancement instead of fighting the browser.
What I especially appreciate here is the restraint. Yes, there’s some clever CSS and a little JavaScript to help with positioning, but the whole thing is built on top of the platform, not in spite of it. That’s the interesting takeaway for me: we can build interfaces that feel bespoke without throwing away the reliability and accessibility native controls already give us.
\n","social_text":"This is exactly the sort of UI work I love seeing: ambitious, polished, and still rooted in native controls and progressive enhancement.","url":"https://www.aaron-gustafson.com/notebook/links/nice-select/","external_url":"https://nerdy.dev/nice-select","tags":["CSS","HTML","progressive enhancement"],"image":"https://nerdy.dev/media/nice-selects.jpg","date_published":"2026-04-23T12:00:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/visual-validation-feedback-for-form-fields/","title":"✍🏻 Visual Validation Feedback for Form Fields","excerpt":"Password requirements, username rules, and format constraints tend to pile up fast. Too often, people only learn whether they met them after they hit submit. The form-validation-list web component changes that by providing real-time feedback as someone types, showing exactly which requirements are met, and which still need work.
Password requirements, username rules, and format constraints tend to pile up fast. Too often, people only learn whether they met them after they hit submit. The form-validation-list web component changes that by providing real-time feedback as someone types, showing exactly which requirements are met, and which still need work.
Password requirements, username rules, and format constraints tend to pile up fast. Too often, people only learn whether they met them after they hit submit. The form-validation-list web component changes that by providing real-time feedback as someone types, showing exactly which requirements are met, and which still need work.
Update: This post has been refreshed to cover the component’s current loading options, throttled input behavior, accessibility model, and localization hooks.
\nThis is a modern replacement for my old jQuery Easy Validation Rules plugin, reimagined as a web component with native form validation integration.
\nTo get started, associate the component with an input element using the for attribute and define your validation rules:
<form>\n <label for=\"username\">Username:</label>\n <input type=\"text\" id=\"username\" name=\"username\" required />\n\n <form-validation-list for=\"username\">\n <ul>\n <li data-pattern=\"[A-Z]+\">At least one capital letter</li>\n <li data-pattern=\"[a-z]+\">At least one lowercase letter</li>\n <li data-pattern=\"[\\d]+\">At least one number</li>\n </ul>\n </form-validation-list>\n\n <button type=\"submit\">Submit</button>\n</form>By default, validation runs on the input event with a 250ms throttle. Matched rules get a checkmark (✓), unmatched rules get an X (✗), and while someone is typing the component announces a concise progress summary instead of repeatedly re-reading the whole rule list. When all rules match, the field is valid and the form can be submitted.
The component:
\nfor attribute (just like a label element)data-pattern attributesvalidation-matched or validation-unmatched classes and visual indicators accordinglysetCustomValidity() to integrate with native form validationThe cascade animation, controlled by each-delay, adds a subtle sequential effect as rules are checked. Small detail, meaningful feedback.
Define rules using regular expression patterns in the data-pattern attribute:
<form-validation-list for=\"password\">\n <ul>\n <!-- Length requirements -->\n <li data-pattern=\".{8,}\">At least 8 characters</li>\n <li data-pattern=\".{8,32}\">Between 8 and 32 characters</li>\n\n <!-- Character type requirements -->\n <li data-pattern=\"[A-Z]+\">At least one uppercase letter</li>\n <li data-pattern=\"[a-z]+\">At least one lowercase letter</li>\n <li data-pattern=\"[\\d]+\">At least one number</li>\n <li data-pattern=\"[!@#$%^&*]+\">At least one special character</li>\n\n <!-- Format requirements -->\n <li data-pattern=\".+@.+\\..+\">Valid email format</li>\n <li data-pattern=\"^[a-zA-Z0-9]+$\">Only letters and numbers</li>\n </ul>\n</form-validation-list>Each pattern is a standard JavaScript regular expression. The component tests the input value against all patterns on the configured trigger, using throttled input events by default.
By default, validation runs on the input event with a 250ms throttle. If you want immediate feedback while typing, set input-throttle="0". If you’d rather wait until the field loses focus, switch the trigger-event to "blur":
<form-validation-list for=\"email\" trigger-event=\"blur\">\n <ul>\n <li data-pattern=\".+@.+\">Contains @ symbol</li>\n <li data-pattern=\".+@.+\\..+\">Valid email format</li>\n </ul>\n</form-validation-list>With this attribute in place, validation runs immediately when the field loses focus. In this mode, input-throttle is ignored and the component keeps the full criteria list available to assistive technology while someone types.
Use the each-delay attribute to control the delay between checking each rule. The default speed is 150ms, but you can tune it to any number of milliseconds:
<form-validation-list for=\"password\" each-delay=\"100\">\n <!-- rules -->\n</form-validation-list>Set it to “0” to remove the cascade effect entirely and check all rules simultaneously.
\nIf you want full design control over the component, you can absolutely have it. The whole component operates in light DOM, so your styles will pierce through. And you can customize class names for integration with CSS frameworks using a set of attributes on the form-validation-list element. The field-valid-class and field-invalid-class attributes control the class names applied to the input field itself, while the rule-matched-class and rule-unmatched-class attributes control the class names applied to each rule item.
Here’s a complete example:
\n<style>\n .is-valid {\n border-color: green;\n }\n .is-invalid {\n border-color: red;\n }\n .rule-pass {\n color: green;\n }\n .rule-fail {\n color: red;\n }\n</style>\n\n<form-validation-list\n for=\"username\"\n field-valid-class=\"is-valid\"\n field-invalid-class=\"is-invalid\"\n rule-matched-class=\"rule-pass\"\n rule-unmatched-class=\"rule-fail\"\n>\n <ul>\n <li data-pattern=\".{5,}\">At least 5 characters</li>\n <li data-pattern=\"[!@#]+\">Special char (!@#)</li>\n </ul>\n</form-validation-list>This approach lets you use class names that match your existing CSS architecture instead of making one small component dictate terms to the rest of your styles.
You can also override the per-instance icon glyphs with the rule-matched-icon and rule-unmatched-icon attributes, or control the shared visual styling using CSS custom properties:
--rule-matched-icon - Content for matched state (default: “✓”)--rule-unmatched-icon - Content for unmatched state (default: “✗”)--rule-icon-size - Size of icons (default: 1em)--rule-matched-color - Color for matched rules (default: green)--rule-unmatched-color - Color for unmatched rules (default: red)The older --validation-* custom property names are still supported as legacy aliases.
Here’s an example of that:
\nform-validation-list {\n --rule-matched-icon: \"✅\";\n --rule-unmatched-icon: \"❌\";\n --rule-icon-size: 1.2em;\n --rule-matched-color: #28a745;\n --rule-unmatched-color: #dc3545;\n}The package now ships with bundled type definitions and reflects its core properties and attributes in both directions. That makes it a much better fit for TypeScript, JSX, SSR, and declarative framework setups where properties may be assigned before the custom element upgrades.
\nIf you really want to get into the weeds, you can also listen for validation changes in your JavaScript code:
\nconst validationList = document.querySelector(\"form-validation-list\");\n\nvalidationList.addEventListener(\"form-validation-list:validated\", (event) => {\n const { isValid, matchedRules, totalRules, field } = event.detail;\n console.log(`Matched ${matchedRules} of ${totalRules} rules`);\n console.log(`Field is ${isValid ? \"valid\" : \"invalid\"}`);\n});The event fires after validation completes and gives you the current state. Nice and tidy.
\nYou can also manually trigger validation and check the element’s current state at any time:
\nconst validationList = document.querySelector(\"form-validation-list\");\n\n// Trigger validation\nconst isValid = validationList.validate();\nconsole.log(\"Is valid:\", isValid);\n\n// Check current state\nconsole.log(\"Current state:\", validationList.isValid);If you need the component to work in different languages, that’s totally doable. You can customize three separate pieces of copy: the browser validation message (validation-message), the live summary announced while typing (announcement), and the per-rule hidden status text (rule-matched-alt and rule-unmatched-alt). All of the message templates support the {matched} and {total} placeholders:
<!-- Spanish -->\n<form-validation-list\n for=\"contrasena\"\n announcement=\"{matched} de {total} criterios cumplidos\"\n rule-matched-alt=\"Criterio cumplido\"\n rule-unmatched-alt=\"Criterio pendiente\"\n validation-message=\"Por favor, cumple todos los requisitos ({matched} de {total})\"\n>\n <ul>\n <li data-pattern=\"[A-Z]+\">Al menos una letra mayúscula</li>\n <li data-pattern=\"[a-z]+\">Al menos una letra minúscula</li>\n <li data-pattern=\"[\\d]+\">Al menos un número</li>\n </ul>\n</form-validation-list>\n\n<!-- French -->\n<form-validation-list\n for=\"mot-de-passe\"\n announcement=\"{matched} critères satisfaits sur {total}\"\n rule-matched-alt=\"Critère satisfait\"\n rule-unmatched-alt=\"Critère non satisfait\"\n validation-message=\"Veuillez satisfaire à toutes les exigences ({matched} sur {total})\"\n>\n <ul>\n <li data-pattern=\"[A-Z]+\">Au moins une lettre majuscule</li>\n <li data-pattern=\"[a-z]+\">Au moins une lettre minuscule</li>\n <li data-pattern=\"[\\d]+\">Au moins un chiffre</li>\n </ul>\n</form-validation-list>The component uses light DOM, so if JavaScript fails, users still see the validation requirements as a standard list. They can read what is expected even without the visual feedback. Your server-side validation still does the important enforcement work regardless… right? Right?
\nThe component is built with accessibility in mind:
\ninput via aria-describedby, and if the field already has aria-describedby, the original value is preserved.trigger-event="input", the component temporarily suspends the full criteria list from aria-describedby while someone types and uses a single polite live region to announce progress instead.If you have suggestions for other ways to improve the accessibility of this component, please open an issue on GitHub.
\nThe component uses setCustomValidity() to participate in native form validation:
:valid and :invalid CSS pseudo-classesconst form = document.querySelector(\"form\");\nconst field = document.getElementById(\"username\");\n\nform.addEventListener(\"submit\", (e) => {\n if (!form.checkValidity()) {\n e.preventDefault();\n console.log(\"Validation failed:\", field.validationMessage);\n }\n});Here’s a complete password validation setup:
\n<form>\n <label for=\"password\">Password:</label>\n <input type=\"password\" id=\"password\" name=\"password\" required />\n\n <form-validation-list for=\"password\">\n <ul>\n <li data-pattern=\".{8,}\">At least 8 characters</li>\n <li data-pattern=\"[A-Z]+\">At least one uppercase letter</li>\n <li data-pattern=\"[a-z]+\">At least one lowercase letter</li>\n <li data-pattern=\"[\\d]+\">At least one number</li>\n <li data-pattern=\"[!@#$%^&*]+\">\n At least one special character (!@#$%^&*)\n </li>\n </ul>\n </form-validation-list>\n\n <button type=\"submit\">Submit</button>\n</form>Users see exactly which requirements they have met, and which they still need to satisfy. That is usually a lot kinder than springing the whole list on them after submit.
\nCheck out the demo with various examples:
\nView the project on GitHub.
\nInstall via npm:
npm install @aarongustafson/form-validation-listFor most projects, import the guarded auto-definition helper:
\nimport \"@aarongustafson/form-validation-list/define.js\";If you want to control the tag name yourself, import FormValidationListElement and register it manually.
If you give it a spin, I’d love to hear how it works in your forms. Happy validating!
\n","social_text":"New #WebComponent: Show users which validation requirements they’ve met—as they type.","url":"https://www.aaron-gustafson.com/notebook/visual-validation-feedback-for-form-fields/","tags":["web components","progressive enhancement","forms","HTML","JavaScript","web forms","user experience"],"date_published":"2026-04-22T20:17:47Z"},{"id":"https://www.aaron-gustafson.com/notebook/never-lose-form-progress-again/","title":"✍🏻 Never Lose Form Progress Again","excerpt":"Few things are more annoying than losing your progress halfway through a form. Maybe the browser crashes. Maybe the tab closes. Maybe your kid yells from the other room, and you come back three hours later wondering why you thought now was a good time to fill out a mortgage application. Whatever the cause, form-saver makes those interruptions a lot less painful, which helps because forms are usually frustrating enough on their own.
Few things are more annoying than losing your progress halfway through a form. Maybe the browser crashes. Maybe the tab closes. Maybe your kid yells from the other room, and you come back three hours later wondering why you thought now was a good time to fill out a mortgage application. Whatever the cause, form-saver makes those interruptions a lot less painful, which helps because forms are usually frustrating enough on their own.
Few things are more annoying than losing your progress halfway through a form. Maybe the browser crashes. Maybe the tab closes. Maybe your kid yells from the other room, and you come back three hours later wondering why you thought now was a good time to fill out a mortgage application. Whatever the cause, form-saver makes those interruptions a lot less painful, which helps because forms are usually frustrating enough on their own.
At its core, form-saver is a small web component that wraps a form, keeps an eye on it, stores values in localStorage, and restores them when the page loads again. Better yet, it clears out saved data after a successful submission so you’re not accidentally resurrecting stale information the next time someone stops by. Nobody wants yesterday’s half-finished support request shambling back to life.
All you need to do is wrap your form in the component:
\n<form-saver>\n <form action=\"/contact\" method=\"post\">\n <label>\n Name\n <input name=\"name\" autocomplete=\"name\" />\n </label>\n <label>\n Email\n <input name=\"email\" type=\"email\" autocomplete=\"email\" />\n </label>\n <label>\n Message\n <textarea name=\"message\"></textarea>\n </label>\n <button type=\"submit\">Send</button>\n </form>\n</form-saver>That’s it. The component targets the first descendant form, saves values as people type or make changes, and restores them when they come back. No extra plumbing, just a form with a slightly better memory than most of us before coffee. Depending on the day, that may not be a terribly high bar, but still.
This is especially handy for forms that are a little more involved than a simple email signup. Job applications, checkout flows, support requests, and multi-question onboarding forms all benefit from a little resilience. So do the people filling them out, who generally have better things to do than retype the same answers because a tab got squirrelly.
\nform-saver supports the controls most of us reach for every day:
input fieldstextarea elements,select elements (including multi-selects), andcheckbox and radio controls.File inputs are intentionally excluded.
\nBecause the component works in light DOM, your form remains your form. Your labels, validation, layout, and CSS continue to work exactly as they did before. form-saver just adds a bit of memory and, ideally, cuts down on a few muttered curses.
In many cases, clearing everything after a successful submission is the right call. Sometimes, though, it makes sense to keep a few details around. Maybe you want to preserve a visitor’s name and email address on a contact form while clearing the message body. That way they do not have to keep retyping the boring bits. Nobody wakes up excited to enter their email address for the fourth time.
\nThat is what the retain attribute is for:
<form-saver retain=\"name email\">\n <form action=\"/contact\" method=\"post\">\n …\n </form>\n</form-saver>After a successful submission, name and email stick around, but message gets cleared. Simple, sensible, and less likely to leave someone staring at your form like it just read their credit card number aloud in a bus station.
Persisting form data can be incredibly helpful, but there is a human side to this. Just because we can keep someone’s information around doesn’t mean we should do it without asking. That is where retain-choice comes in: it lets you be useful without being presumptuous.
Add it alongside retain and form-saver will inject an opt-in checkbox for the user. Nice and easy:
<form-saver\n retain=\"name email\"\n retain-choice\n retain-choice-label=\"Store my contact information for later\"\n>\n <form action=\"/contact\" method=\"post\">\n …\n </form>\n</form-saver>By default, that checkbox is inserted just before the first submit control. If the user leaves it unchecked, the retained fields are cleared along with everything else after submit. If they opt in, those selected fields remain. Their call, as it should be.
\nNeed to place that control somewhere more appropriate in your layout? Use retain-choice-container to point to a CSS selector:
<form-saver\n retain=\"name email\"\n retain-choice\n retain-choice-label=\"Remember my details next time\"\n retain-choice-container=\".form-footer\"\n>\n <form action=\"/contact\" method=\"post\">\n …\n <div class=\"form-footer\">\n <button type=\"submit\">Send</button>\n </div>\n </form>\n</form-saver>That gives you a lot more control over the experience without making you build the retention UI yourself.
\nBy default, form-saver derives its storage key from the wrapped form’s method and action, which is usually exactly what you want. It keeps different forms from stepping on one another and keeps the setup nice and boring. Boring is good.
If you need something more explicit, you can provide your own storage-key:
<form-saver storage-key=\"checkout:shipping-address\">\n <form action=\"/checkout/shipping\" method=\"post\">\n <label>\n Street Address\n <input name=\"street-address\" autocomplete=\"street-address\" />\n </label>\n <label>\n Postal Code\n <input name=\"postal-code\" autocomplete=\"postal-code\" />\n </label>\n <button type=\"submit\">Continue</button>\n </form>\n</form-saver>This is useful when a form’s URL is not stable, or when you want multiple views to intentionally share the same saved state.
\nIf you need more direct control, the component exposes a few methods:
\nconst saver = document.querySelector(\"form-saver\");\n\n// Persist the current state\nsaver.saveFormState();\n\n// Restore previously saved values\nsaver.restoreFormState();\n\n// Clear out anything stored for this form\nsaver.clearSavedData();That can be useful when you want to pair it with your own UI, analytics, or custom workflow around save and restore.
\nThis component follows a pattern I am always going to favor: start with a perfectly ordinary form, then layer on the enhancement. If JavaScript fails, the form still works. Users can still fill it out and submit it. They just will not get the recovery behavior. Annoying, perhaps, but not catastrophic. And that is very much the point.
\nThat’s a pretty good trade-off.
\nAnd because saved values are only cleared after a successful submit flow, you do not lose everything just because client-side validation blocked submission or some other script got clever at exactly the wrong moment. That matters. A lot of “smart” form experiences are only smart right up until they are not.
\nIf you want to kick the tires, I put together a live demo with examples of the retention options as well:
\nThe project is available on GitHub, and you can install it from npm:
\nnpm install @aarongustafson/form-saverIf you want the easiest path, just import it and let the component register itself:
\nimport \"@aarongustafson/form-saver\";If you would rather define it yourself, you can import the class directly:
\nimport { FormSaverElement } from \"@aarongustafson/form-saver/form-saver.js\";\n\ncustomElements.define(\"form-saver\", FormSaverElement);Either way, you wind up with a more forgiving form experience and a little less needless frustration for the people filling it out. Which, in my book, is a pretty solid deal. The bar for delight in forms is often just “don’t make me do that again,” and honestly, I’ll take it.
\n","social_text":"Browsers crash. Tabs close. Life happens. Here’s a web component that saves form progress so your users don’t have to start over from scratch.","url":"https://www.aaron-gustafson.com/notebook/never-lose-form-progress-again/","tags":["web components","forms","HTML","JavaScript","progressive enhancement","web forms","user experience"],"date_published":"2026-04-20T23:59:08Z"},{"id":"https://www.aaron-gustafson.com/notebook/repeatable-form-fields-made-simple/","title":"✍🏻 Repeatable Form Fields Made Simple","excerpt":"Sometimes you need people to provide multiple instances of the same information: email addresses, phone numbers, team members, or emergency contacts. The form-repeatable web component handles that cleanly, including duplication, renumbering, and seamless form submission via the ElementInternals API.
Sometimes you need people to provide multiple instances of the same information: email addresses, phone numbers, team members, or emergency contacts. The form-repeatable web component handles that cleanly, including duplication, renumbering, and seamless form submission via the ElementInternals API.
Sometimes you need people to provide multiple instances of the same information: email addresses, phone numbers, team members, or emergency contacts. The form-repeatable web component handles that cleanly, including duplication, renumbering, and seamless form submission via the ElementInternals API.
All you need to do is provide a single field group and the component handles the rest:
\n<form>\n <form-repeatable>\n <div>\n <label for=\"stop-1\">Stop 1</label>\n <input id=\"stop-1\" type=\"text\" name=\"stops[]\">\n </div>\n </form-repeatable>\n</form>The form-repeatable component treats its first child as a template and injects a button that allows users to repeat the field. When users click “Add Another” (the default “add” button text), the following happens:
stop-1 → stop-2),ElementInternals.That last piece is crucial. The plugin is a fully-participating member in the parent form:
\nFormDataNo special handling required; it works like a native form control.
\nIf you don’t like the default text, or your site is in another language, you can define your own button labels using the add-label and remove-label attributes:
<form-repeatable add-label=\"Add Another Item\" remove-label=\"Delete\">\n <div>\n <label for=\"item-1\">Item 1</label>\n <input id=\"item-1\" type=\"text\" name=\"items[]\" />\n </div>\n</form-repeatable>With that simple change, the add button reads “Add Another Item” and each remove button reads “Delete”. To improve the experience for screen reader users, the remove-label value is combined with the associated label/legend to create accessible names like “Delete Item 1” which is far more helpful.
If your form needs to start with multiple groups already filled in, just provide them as child elements:
\n<form>\n <form-repeatable min=\"2\">\n <div>\n <label for=\"phone-1\">Phone 1</label>\n <input id=\"phone-1\" type=\"tel\" name=\"phones[]\" value=\"555-0100\">\n </div>\n <div>\n <label for=\"phone-2\">Phone 2</label>\n <input id=\"phone-2\" type=\"tel\" name=\"phones[]\" value=\"555-0101\">\n </div>\n <div>\n <label for=\"phone-3\">Phone 3</label>\n <input id=\"phone-3\" type=\"tel\" name=\"phones[]\">\n </div>\n </form-repeatable>\n</form>All child elements become managed groups, and existing values are preserved. Perfect progressive enhancement!
\nYou’re not limited to repeating a single field. Each group can contain multiple, related fields. Here’s an example with a fieldset for guest information:
<form-repeatable>\n <fieldset>\n <legend>Guest 1</legend>\n <label for=\"guest-name-1\">Name</label>\n <input id=\"guest-name-1\" type=\"text\" name=\"guest-name-1\">\n\n <label for=\"guest-email-1\">Email</label>\n <input id=\"guest-email-1\" type=\"email\" name=\"guest-email-1\">\n </fieldset>\n</form-repeatable>When the component initializes, the whole fieldset becomes the template. As users add guests, numeric values in text and attributes increment automatically. In this example, that means the legend, for, id, and name values all stay in sync.
Use the min and max attributes to control the number of allowed groups:
<form-repeatable\n min=\"2\"\n max=\"5\"\n add-label=\"Add Team Member\"\n remove-label=\"Remove\"\n>\n <div>\n <label for=\"member-1\">Team Member 1</label>\n <input id=\"member-1\" type=\"text\" name=\"members[]\" />\n </div>\n</form-repeatable>This creates a component that:
\nmin threshold (2) is met,The remove buttons are not shown when at the minimum threshold (1 by default) and the add button disappears when you hit the maximum.
\ntemplate? Bring it!This component can accept a template element containing the fields you want to repeat. Just drop in {n} placeholders where you want the sequential numbers to appear:
<form-repeatable>\n <template>\n <div>\n <label for=\"email-{n}\">Email {n}</label>\n <input id=\"email-{n}\" type=\"email\" name=\"emails[]\">\n </div>\n </template>\n</form-repeatable>When hoisted into the component, the template element is removed from the light DOM and used internally.
The component uses Shadow DOM to encapsulate its internal structure, but you can style it using CSS parts and custom properties. It also adopts your global styles automatically.
\nThe component uses CSS Grid by default:
\nsubgrid to align with parent gridYou can use CSS parts to style the buttons and field groups. Here are some examples:
\n/* Style all buttons */\nform-repeatable::part(button) {\n padding: 0.5rem 1rem;\n border-radius: 4px;\n cursor: pointer;\n}\n\n/* Style the add button */\nform-repeatable::part(add-button) {\n background: #28a745;\n color: white;\n}\n\n/* Style remove buttons */\nform-repeatable::part(remove-button) {\n background: #dc3545;\n color: white;\n}\n\n/* Customize the grid layout */\nform-repeatable::part(groups) {\n grid-template-columns: 1fr auto;\n gap: 1rem;\n}\n\n/* Style each group */\nform-repeatable::part(group) {\n padding: 1rem;\n background: #f8f9fa;\n border-radius: 4px;\n margin-bottom: 0.5rem;\n}Available parts:
\ngroups - Container for all groups (CSS grid by default)group - Each repeatable group wrappercontent - Container for group’s fieldsgroup-controls - Container for the remove buttoncontrols - Container for the add buttonbutton - All buttonsadd-button - The add buttonremove-button - All remove buttonsYou can listen for when groups are added or removed and run your own custom code:
\nconst repeatable = document.querySelector(\"form-repeatable\");\n\nrepeatable.addEventListener(\"form-repeatable:added\", (event) => {\n console.log(\"Group added. Total groups:\", event.detail.groupCount);\n});\n\nrepeatable.addEventListener(\"form-repeatable:removed\", (event) => {\n console.log(\"Group removed. Total groups:\", event.detail.groupCount);\n});If JavaScript fails, users still see the initial field group(s) and can complete the form. They won’t be able to add more, but nothing breaks. Set your minimums accordingly.
\nExplore the demo with various examples:
\nCheck out the project on GitHub. Install via npm:
\nnpm install @aarongustafson/form-repeatableImport and go:
\nimport \"@aarongustafson/form-repeatable\";This single component manages repeatable field groups with native form participation, no framework required.
\n","social_text":"Add repeatable form field groups with automatic numbering and native form participation.","url":"https://www.aaron-gustafson.com/notebook/repeatable-form-fields-made-simple/","tags":["forms","HTML","JavaScript","progressive enhancement","web components","web forms"],"date_published":"2026-01-31T00:04:36Z"},{"id":"https://www.aaron-gustafson.com/notebook/fullscreen-video-and-iframes-made-easy/","title":"✍🏻 Fullscreen Video and Iframes Made Easy","excerpt":"Adding fullscreen capabilities to videos and embedded iframes shouldn’t require wrestling with prefixed APIs or managing focus states. The fullscreen-control web component handles all of that for you — just wrap it around the element. The component handles the rest as a discrete progressive enhancement.
Adding fullscreen capabilities to videos and embedded iframes shouldn’t require wrestling with prefixed APIs or managing focus states. The fullscreen-control web component handles all of that for you — just wrap it around the element. The component handles the rest as a discrete progressive enhancement.
Adding fullscreen capabilities to videos and embedded iframes shouldn’t require wrestling with prefixed APIs or managing focus states. The fullscreen-control web component handles all of that for you — just wrap it around the element. The component handles the rest as a discrete progressive enhancement.
Here’s a simple example using a video element:
<fullscreen-control>\n <video src=\"video.mp4\"></video>\n</fullscreen-control>With that in place, the component
\nThe component uses light DOM, so your video stays in the regular DOM tree and all your existing CSS continues to work.
Need to embed a YouTube video, slide deck, or code demo? The component works with iframe elements too:
<fullscreen-control>\n <iframe\n src=\"https://www.youtube.com/embed/dQw4w9WgXcQ\"\n width=\"560\"\n height=\"315\"\n title=\"YouTube video player\"\n >\n </iframe>\n</fullscreen-control>The component automatically adds the necessary allow="fullscreen" and allowfullscreen attributes, including prefixed versions for broader compatibility.
button textYou can change the button label to match your site’s language or writing style by setting the button-text attribute:
<fullscreen-control button-text=\"全画面表示\">\n <video src=\"video.mp4\"></video>\n</fullscreen-control>The default button label is “View fullscreen,” but you can use this attribute to customize it to anything you like. You can even dynamically inject the accessible name of the contained element, using the {name} token. For example:
<fullscreen-control button-text=\"View {name} fullscreen\">\n <video src=\"video.mp4\" aria-label=\"Product demo\"></video>\n</fullscreen-control>This creates a button with the text “View Product demo fullscreen”. The component looks for aria-label, title, or other native naming on the wrapped element and uses that to make the button contextual.
If you want the visible label and accessible button name to differ, use the button-label attribute. Like button-text, it can also inject the accessible name of the controlled element using the {name} token:
<fullscreen-control\n button-text=\"Fullscreen\"\n button-label=\"View {name} in fullscreen mode\"\n>\n <iframe src=\"https://example.com\" title=\"Product teaser\"> </iframe>\n</fullscreen-control>This code will generate a button that visually reads “Fullscreen”, but is announced as “View Product teaser in fullscreen mode” to screen readers. In mode cases, button-text will suffice, but this option is available if you need to distinguish the buttons of multiple fullscreen controls from one another and don’t have visual space to display their accessible names.
If users activate fullscreen using the button, focus will automatically return to the button upon exiting fullscreen. This ensures keyboard users don’t lose their place.
\nWant to manage the component yourself? The component exposes three methods:
\nconst control = document.querySelector(\"fullscreen-control\");\n\n// Enter fullscreen\nawait control.enterFullscreen();\n\n// Exit fullscreen\nawait control.exitFullscreen();\n\n// Toggle fullscreen state\ncontrol.toggleFullscreen();These handle all the browser prefixes and error handling for you.
\nThere are also a set of events you can tap into when the fullscreen state changes:
\nconst control = document.querySelector(\"fullscreen-control\");\n\ncontrol.addEventListener(\"fullscreen-control:enter\", () => {\n console.log(\"Entered fullscreen mode\");\n});\n\ncontrol.addEventListener(\"fullscreen-control:exit\", () => {\n console.log(\"Exited fullscreen mode\");\n});These events give you the ability to pause other media, track analytics, and the like.
\nSince the component uses light DOM, you can style the button directly with CSS:
\nfullscreen-control button {\n background: #ff6b6b;\n color: white;\n border: none;\n padding: 0.75rem 1.5rem;\n border-radius: 20px;\n font-weight: bold;\n}\n\nfullscreen-control button:hover {\n background: #ff5252;\n}The button is positioned absolutely by default (top-right corner), but you can adjust this with CSS custom properties:
\nfullscreen-control {\n --fullscreen-control-button-inset-block-start: 1rem;\n --fullscreen-control-button-inset-inline-end: 1rem;\n}This uses logical properties, so it adapts automatically to different writing modes.
\nInstall via npm:
\nnpm install @aarongustafson/fullscreen-controlThen import it in your JavaScript:
\nimport \"@aarongustafson/fullscreen-control/define.js\";Or load it from a CDN for quick prototyping:
\n<script type=\"module\">\n import { defineFullscreenControl } from \"https://unpkg.com/@aarongustafson/fullscreen-control@latest/define.js?module\";\n defineFullscreenControl();\n</script>The component uses modern web standards (Custom Elements v1, ES Modules) and handles browser-prefixed fullscreen APIs internally. For older browsers, you may need polyfills, but the component gracefully handles missing APIs with console warnings rather than breaking your page.
\nCheck out the live demo to see all the features in action, or grab the code from GitHub.
\n","social_text":"Add fullscreen controls to videos and iframes with progressive enhancement. One wrapper, zero hassle.","url":"https://www.aaron-gustafson.com/notebook/fullscreen-video-and-iframes-made-easy/","tags":["web components","progressive enhancement","HTML","video","accessibility","media"],"date_published":"2025-12-29T17:17:27Z"},{"id":"https://www.aaron-gustafson.com/notebook/dynamic-datalist-autocomplete-from-an-api/","title":"✍🏻 Dynamic Datalist: Autocomplete from an API","excerpt":"HTML’s datalist element provides native autocomplete functionality, but it’s entirely static—you have to know all the options up front. The dynamic-datalist web component solves this by fetching suggestions from an API endpoint as users type, giving you the benefits of native autocomplete with the flexibility of dynamic data.
HTML’s datalist element provides native autocomplete functionality, but it’s entirely static—you have to know all the options up front. The dynamic-datalist web component solves this by fetching suggestions from an API endpoint as users type, giving you the benefits of native autocomplete with the flexibility of dynamic data.
HTML’s datalist element provides native autocomplete functionality, but it’s entirely static—you have to know all the options up front. The dynamic-datalist web component solves this by fetching suggestions from an API endpoint as users type, giving you the benefits of native autocomplete with the flexibility of dynamic data.
This component is a modern replacement for my old jQuery predictive typing plugin. I’ve reimagined it as a standards-based web component.
\nTo use the component, wrap it around your input field and specify an endpoint:
<dynamic-datalist endpoint=\"/api/search\">\n <label for=\"search\"\n >Search\n <input\n type=\"text\"\n id=\"search\"\n name=\"search\"\n placeholder=\"Type to search...\"\n />\n </label>\n</dynamic-datalist>As users type, the component makes GET requests to that endpoint, passing in the typed value as the “query” parameter (e.g., /api/search?query=WHAT_THE_USER_TYPED). The response from the endpoint is used to populates a dynamic datalist element with the results.
The structure of the response should be JSON with an options array of string values:
{\n \"options\": [\"option 1\", \"option 2\", \"option 3\"]\n}Under the hood, the component:
\ndatalist element for your input,input,datalist option elements, andAll of this happens transparently—users just see autocomplete suggestions appearing as they type.
\nYou can change the submission method via the method attribute:
<dynamic-datalist endpoint=\"/api/lookup\" method=\"post\">\n <label for=\"lookup\"\n >Lookup\n <input type=\"text\" id=\"lookup\" name=\"lookup\" />\n </label>\n</dynamic-datalist>This sends a POST request with a JSON body: { "query": "..." }. Currently GET and POST are supported, but I could add more if folks want them.
As I mentioned, the component uses “query” as the parameter name by default, but you can easily change it via the key attribute:
<dynamic-datalist endpoint=\"/api/terms\" key=\"term\">\n <label for=\"search\"\n >Term search\n <input type=\"text\" id=\"search\" name=\"term\" />\n </label>\n</dynamic-datalist>This sends the GET request /api/terms?term=....
If your input already has a datalist defined, the component will inherit it and replace the existing options with the fetched results, which makes for a nice progressive enhancement:
<dynamic-datalist endpoint=\"/api/cities\">\n <label for=\"city\"\n >City\n <input\n type=\"text\"\n id=\"city\"\n list=\"cities-list\"\n placeholder=\"Type a city…\"\n />\n </label>\n <datalist id=\"cities-list\">\n <option>New York</option>\n <option>Los Angeles</option>\n <option>Chicago</option>\n </datalist>\n</dynamic-datalist>Users see the pre-populated cities immediately, and as they type, API results supplement the list. If JavaScript fails or the web component doesn’t load, users still get the static options. Nothing breaks.
\nIf you want to tap into the component’s event system, it fires three custom events:
\ndynamic-datalist:ready - Fired when the component initializesdynamic-datalist:update - Fired when the datalist is updated with new optionsdynamic-datalist:error - Fired when an error occurs fetching dataconst element = document.querySelector(\"dynamic-datalist\");\n\nelement.addEventListener(\"dynamic-datalist:ready\", (e) => {\n console.log(\"Component ready:\", e.detail);\n});\n\nelement.addEventListener(\"dynamic-datalist:update\", (e) => {\n console.log(\"Options updated:\", e.detail.options);\n});\n\nelement.addEventListener(\"dynamic-datalist:error\", (e) => {\n console.error(\"Error:\", e.detail.error);\n});Each event provides helpful detail objects with references to the input, datalist, and other relevant data.
Check out the demo for live examples (there are also unpkg and ESM builds if you want to test CDN delivery):
\nThe project is available on GitHub. You can also install via npm:
\nnpm install @aarongustafson/dynamic-datalistIf you go that route, there are a few ways to register the element depending on your build setup:
\nimport { DynamicDatalistElement } from \"@aarongustafson/dynamic-datalist\";\n\ncustomElements.define(\"dynamic-datalist\", DynamicDatalistElement);import \"@aarongustafson/dynamic-datalist/define.js\";\n// or, when you need to wait:\nimport { defineDynamicDatalist } from \"@aarongustafson/dynamic-datalist/define.js\";\n\ndefineDynamicDatalist();<script> tag<script\n src=\"./node_modules/@aarongustafson/dynamic-datalist/define.js\"\n type=\"module\"\n></script>Regardless of how you register it, there are no framework dependencies—just clean autocomplete powered by your API. As I mentioned, it’s also available via CDNs, such as unpkg too, if you’d prefer to go that route.
\n","social_text":"Want API-driven autocomplete suggestions in your forms? Here’s a web component that makes it happen.","url":"https://www.aaron-gustafson.com/notebook/dynamic-datalist-autocomplete-from-an-api/","tags":["forms","HTML","JavaScript","progressive enhancement","web components","web forms","API"],"date_published":"2025-12-16T19:46:29Z"},{"id":"https://www.aaron-gustafson.com/notebook/lazy-loading-images-based-on-screen-size/","title":"✍🏻 Lazy Loading Images Based on Screen Size","excerpt":"Native lazy loading and srcset are great, but they have a limitation: they always load some variant of the image. The lazy-img web component takes a different approach—it can completely skip loading images when they don’t meet your criteria, whether that’s screen size, container size, or visibility in the viewport.
This is particularly valuable for mobile users on slow connections or limited data plans. If an image is only meaningful on larger screens, why waste their bandwidth loading it at all?
","summary":"Native lazy loading and srcset are great, but they have a limitation: they always load some variant of the image. The lazy-img web component takes a different approach—it can completely skip loading images when they don’t meet your criteria, whether that’s screen size, container size, or visibility in the viewport.
This is particularly valuable for mobile users on slow connections or limited data plans. If an image is only meaningful on larger screens, why waste their bandwidth loading it at all?
","content_html":"Native lazy loading and srcset are great, but they have a limitation: they always load some variant of the image. The lazy-img web component takes a different approach—it can completely skip loading images when they don’t meet your criteria, whether that’s screen size, container size, or visibility in the viewport.
This is particularly valuable for mobile users on slow connections or limited data plans. If an image is only meaningful on larger screens, why waste their bandwidth loading it at all?
\nUnlike picture or srcset, which always load some image variant, lazy-img can completely skip loading images on screens or containers below your specified threshold. Set min-inline-size="768px" and mobile users will never download that image at all—saving data and speeding up page loads.
Once an image is loaded, however, it remains loaded even if the viewport or container is resized below the threshold. This is intentional—the component prevents unnecessary downloads but doesn’t unload images already in memory. You can control visibility with CSS if needed using the loaded and qualifies attributes (which we’ll get to shortly).
The lazy-img works pretty much identically to a regular img element, with all the attributes you know and love:
<lazy-img src=\"image.jpg\" alt=\"A beautiful image\"> </lazy-img>But that’s not very interesting. The real power comes from conditional loading.
\nLoad an image only when its container reaches a minimum width:
\n<lazy-img src=\"large-image.jpg\" alt=\"Large image\" min-inline-size=\"500px\">\n</lazy-img>The image loads when the lazy-img element’s container reaches 500px wide. This is the default query mode—it uses ResizeObserver to watch the container size.
You can lazy load images based on viewport width instead by switching to media query mode:
\n<lazy-img\n src=\"desktop-image.jpg\"\n alt=\"Desktop image\"\n min-inline-size=\"768px\"\n query=\"media\"\n>\n</lazy-img>With this configuration, the image loads when the browser window is at least 768px wide.
\nLoad images when they scroll into view using IntersectionObserver by switching to the “view” query type:
<lazy-img src=\"image.jpg\" alt=\"Loads when scrolled into view\" query=\"view\">\n</lazy-img>The default behavior (view-range-start="entry 0%") loads as soon as any part of the image enters the viewport.
Control when images load with the view-range-start attribute:
Load when 50% visible:
\n<lazy-img\n src=\"image.jpg\"\n alt=\"Loads when half visible\"\n query=\"view\"\n view-range-start=\"entry 50%\"\n>\n</lazy-img>Preload before entering viewport:
\n<lazy-img\n src=\"image.jpg\"\n alt=\"Preloads 200px before visible\"\n query=\"view\"\n view-range-start=\"entry -200px\"\n>\n</lazy-img>This creates a smooth user experience—images are already loaded by the time users scroll to them.
\nAs with regular images, you can use srcset and sizes for responsive images:
<lazy-img\n src=\"image-800.jpg\"\n srcset=\"image-400.jpg 400w,\n image-800.jpg 800w,\n image-1200.jpg 1200w\"\n sizes=\"(max-width: 600px) 400px,\n (max-width: 1000px) 800px,\n 1200px\"\n alt=\"Responsive image\"\n min-inline-size=\"400px\"\n>\n</lazy-img>The component waits until the conditions are met before loading a real image and the browser takes over from there.
\nYou can also define named breakpoints using CSS custom properties:
\n:root {\n --lazy-img-mq: small;\n}\n\n@media (min-width: 768px) {\n :root {\n --lazy-img-mq: medium;\n }\n}\n\n@media (min-width: 1024px) {\n :root {\n --lazy-img-mq: large;\n }\n}Then reference them in your markup:
\n<lazy-img\n src=\"image.jpg\"\n alt=\"Image with named breakpoints\"\n named-breakpoints=\"medium, large\"\n query=\"media\"\n>\n</lazy-img>The image loads when --lazy-img-mq matches “medium” or “large”.
As with regular images, don’t forget to use width and height attributes to prevent Cumulative Layout Shift (CLS):
<lazy-img\n src=\"image.jpg\"\n alt=\"A beautiful image\"\n width=\"800\"\n height=\"600\"\n min-inline-size=\"768px\"\n>\n</lazy-img>The browser reserves the correct space while the image loads, preventing content from jumping around.
\nThe component provides loaded and qualifies attributes you can use in CSS:
/* Hide images that loaded but no longer meet conditions */\nlazy-img[loaded]:not([qualifies]) {\n display: none;\n}\n\n/* Show a placeholder for images that qualify but haven't loaded */\nlazy-img[qualifies]:not([loaded])::before {\n content: \"Loading…\";\n display: block;\n padding: 2em;\n background: #f0f0f0;\n text-align: center;\n}If you crave control, you can add your own functionality by listening for when images load:
\nconst lazyImg = document.querySelector(\"lazy-img\");\nlazyImg.addEventListener(\"lazy-img:loaded\", (event) => {\n console.log(\"Image loaded:\", event.detail.src);\n});The component is highly optimized:
\nResizeObserver: Multiple images observing the same container share a single ResizeObserverIntersectionObserver: View mode with the same view-range-start shares an IntersectionObserverEven with hundreds of lazy-img elements on a page, performance remains excellent.
If JavaScript fails to load, images simply don’t appear (unless using immediate loading mode). This might sound problematic, but for non-critical images—decorative graphics, supplementary screenshots, marketing imagery—it’s often exactly what you want. Your content remains accessible; you just lose the enhancements.
\nFor critical images that are part of your content, use standard img tags. Use lazy-img for conditional enhancements.
Explore the demo to see container queries, media queries, scroll-based loading, and more in action:
\nCheck out the project on GitHub. Install via npm:
\nnpm install @aarongustafson/lazy-imgImport and use:
\nimport \"@aarongustafson/lazy-img\";Based on my original Easy Lazy Images concept, reimagined as a modern custom element.
\n","social_text":"Want to skip loading images entirely on mobile? Here’s a web component that does just that.","url":"https://www.aaron-gustafson.com/notebook/lazy-loading-images-based-on-screen-size/","tags":["web components","progressive enhancement","HTML","performance","images","responsive design"],"date_published":"2025-12-10T17:15:54Z"},{"id":"https://www.aaron-gustafson.com/notebook/a-web-component-for-obfuscating-form-fields/","title":"✍🏻 A Web Component for Obfuscating Form Fields","excerpt":"We have the password reveal pattern for passwords, but what about other sensitive fields that need to be readable while editing and obfuscated while at rest? The form-obfuscator web component does exactly that.
We have the password reveal pattern for passwords, but what about other sensitive fields that need to be readable while editing and obfuscated while at rest? The form-obfuscator web component does exactly that.
We have the password reveal pattern for passwords, but what about other sensitive fields that need to be readable while editing and obfuscated while at rest? The form-obfuscator web component does exactly that.
Wrap any text field in the component and it will automatically obfuscate the value when the field loses focus:
\n<form-obfuscator>\n <label for=\"secret-key-1\">What was your first pet’s name?</label>\n <input type=\"text\" id=\"secret-key-1\" name=\"secret-key-1\" />\n</form-obfuscator>When users click into the field, they see the actual value. When they click away, it’s replaced with asterisks (*). The real value is preserved in a hidden field for form submission.
\nIf you don’t like asterisks, you can specify any character you like:
\n<form-obfuscator character=\"•\">\n <label for=\"account\">Account Number</label>\n <input type=\"text\" id=\"account\" name=\"account\" />\n</form-obfuscator>Or get creative:
\n<form-obfuscator character=\"🤐\">\n <label for=\"ssn\">Social Security Number</label>\n <input type=\"text\" id=\"ssn\" name=\"ssn\" />\n</form-obfuscator>Sometimes you want to show part of the value while hiding the rest. The pattern attribute lets you specify which characters to keep visible:
<form-obfuscator pattern=\"\\d{4}$\">\n <label for=\"ssn\">Social Security Number</label>\n <input type=\"text\" id=\"ssn\" name=\"ssn\" />\n</form-obfuscator>This keeps the last four digits visible while replacing everything else with your obfuscation character. Perfect for Social Security Numbers, credit cards, or phone numbers where showing the last few digits helps users confirm they’ve entered the right value.
\nUse the maxlength attribute to cap how many characters appear when obfuscated:
<form-obfuscator maxlength=\"4\">\n <label for=\"password\">Password</label>\n <input type=\"text\" id=\"password\" name=\"password\" />\n</form-obfuscator>Even if the user enters a 20-character value, only four asterisks will be displayed when the field is obfuscated. This prevents giving away information about the length of the information entered.
\nFor complete control, you can provide a JavaScript function via the replacer attribute:
<script>\n window.emailReplacer = function () {\n var username = arguments[0][1];\n var domain = arguments[0][2];\n return username.replace(/./g, \"*\") + domain;\n };\n</script>\n\n<form-obfuscator\n pattern=\"^(.*?)(@.+)$\"\n replacer=\"return emailReplacer(arguments)\"\n>\n <label for=\"email\">Email Address</label>\n <input type=\"text\" id=\"email\" name=\"email\" value=\"user@example.com\" />\n</form-obfuscator>This example uses a pattern to separate the username from the domain, then obfuscates only the username portion, leaving @example.com visible.
Here’s another practical example for credit cards:
\n<script>\n function cardNumberReplacer() {\n var beginning = arguments[0][1];\n var final_digits = arguments[0][2];\n return beginning.replace(/\\d/g, \"*\") + final_digits;\n }\n</script>\n\n<form-obfuscator\n pattern=\"^((?:[\\d]+\\-)+)(\\d+)$\"\n replacer=\"return cardNumberReplacer(arguments)\"\n>\n <label for=\"cc\">Credit Card</label>\n <input type=\"text\" id=\"cc\" name=\"cc\" value=\"1234-5678-9012-3456\" />\n</form-obfuscator>This displays as ****-****-****-3456, showing only the last group of digits.
You can combine these attributes for sophisticated obfuscation patterns:
\n<form-obfuscator pattern=\"\\d{4}$\" character=\"•\" maxlength=\"16\">\n <label for=\"card\">Credit Card</label>\n <input type=\"text\" id=\"card\" name=\"card\" />\n</form-obfuscator>This keeps the last 4 digits visible, uses bullets for obfuscation, and limits the display to 16 characters total.
\nThe component dispatches custom events when values are hidden or revealed:
\nconst obfuscator = document.querySelector(\"form-obfuscator\");\n\nobfuscator.addEventListener(\"form-obfuscator:hide\", (e) => {\n console.log(\"Field obfuscated:\", e.detail.field.value);\n});\n\nobfuscator.addEventListener(\"form-obfuscator:reveal\", (e) => {\n console.log(\"Field revealed:\", e.detail.field.value);\n});You can access both the visible field and the hidden field through event.detail.field and event.detail.hidden respectively.
The component creates a hidden input field to store the actual value for form submission. When the visible field loses focus, it:
form-obfuscator:hide eventWhen the field gains focus, it:
\nform-obfuscator:reveal eventThe source order ensures the hidden field is the one that gets submitted with the form.
\nThe component makes no assumptions about your markup—it works with any text-style input element. If JavaScript fails to load, the field behaves like a normal input, which is exactly what you want. Users can still enter and submit values; they just won’t get the obfuscation behavior.
I’ve created a comprehensive demo page showing the various configuration options over on GitHub:
\nCheck out the full project over on GitHub or install via npm:
npm install @aarongustafson/form-obfuscatorImport and use:
\nimport \"@aarongustafson/form-obfuscator\";No dependencies, just a straightforward way to add field obfuscation to your forms.
\n","social_text":"Need to obfuscate form field values when they’re not being edited? Here’s a web component for that.","url":"https://www.aaron-gustafson.com/notebook/a-web-component-for-obfuscating-form-fields/","tags":["forms","HTML","JavaScript","progressive enhancement","web components","web forms","security"],"date_published":"2025-12-06T20:03:47Z"},{"id":"https://www.aaron-gustafson.com/notebook/a-web-component-for-conditionally-displaying-fields/","title":"✍🏻 A Web Component for Conditionally Displaying Fields","excerpt":"Building on my recent work in the form utility space, I’ve created a new web component that allows you to conditionally display form fields based on the values of other fields: form-show-if.
Building on my recent work in the form utility space, I’ve created a new web component that allows you to conditionally display form fields based on the values of other fields: form-show-if.
Building on my recent work in the form utility space, I’ve created a new web component that allows you to conditionally display form fields based on the values of other fields: form-show-if.
This component tackles a common UX pattern that HTML doesn’t natively support. You know the scenario—you have a form where certain fields should only appear when specific conditions are met. Maybe you want to show shipping address fields only when someone checks “Ship to different address,” or display a text input for “Other” when someone selects that option from a dropdown. This web component makes that setup effortless — and declarative.
\nYou set up form-show-if like this:
<form-show-if conditions=\"contact_method=phone\">\n <label for=\"phone\"\n >Phone Number\n <input type=\"tel\" id=\"phone\" name=\"phone\" />\n </label>\n</form-show-if>You wrap any field and its label in the component and then declare the conditions under which it should be displayed in the conditions attribute.
Each condition is a key/value pair where the key aligns to the name of the field you need to observe and the value is the value that triggers the display. If any value should trigger the display, use an asterisk (*) as the value. In the example above, the field will become visible only if — in a theoretical contact method choice — a user chooses “phone” as the method they want used.
The conditions attribute can be populated with as many dependencies as you need. Multiple conditions are separated by double vertical pipes (||), as in this example:
<form-show-if conditions=\"contact_method=phone||contact_method=text_message\">\n <label for=\"phone-number\"\n >Phone Number\n <input type=\"tel\" id=\"phone\" name=\"phone\" />\n </label>\n</form-show-if>Here the field depends on one of the following conditions being true:
\n[name="contact_method"] has a value of “phone” or[name="contact_method"] has a value of “text_message”If the field you reference doesn’t exist, no errors will be thrown—it will just quietly exit.
\nBy default, the component uses the hidden attribute to hide the wrapped content when it’s not needed. But you can customize this behavior using CSS classes instead:
<form-show-if\n conditions=\"shipping-method=express\"\n disabled-class=\"fade-out\"\n enabled-class=\"fade-in\"\n>\n <label for=\"delivery-date\"\n >Express Delivery Date\n <input type=\"date\" id=\"delivery-date\" name=\"delivery-date\" />\n </label>\n</form-show-if>When using custom classes:
\ndisabled-class is applied when the condition is not met (field should be hidden)enabled-class is applied when the condition is met (field should be shown)Both are optional. Just remember that if you define a disabled-class, the hidden attribute will not be used — you will need to accessibly hide the content yourself.
This gives you complete control over the visual presentation. You could use CSS transitions for smooth animations, apply different styling states, or integrate with your existing design system’s utility classes.
\nThe component doesn’t just toggle visibility—it also manages the form state correctly. When fields are hidden, they’re automatically disabled using the disabled attribute. If there are any sibling fields in the component, they will be disabled as well. This prevents these fields from being submitted with the form and ensures they don’t interfere with form validation.
When conditions are met and fields become visible, they’re re-enabled automatically. This behavior works seamlessly with both native form validation and custom validation scripts.
\nHere are some practical use cases where this component shines:
\n“Other” option handling:
\n<fieldset>\n <legend>How did you hear about us?</legend>\n\n <label><input type=\"radio\" name=\"source\" value=\"google\" /> Google</label>\n <label><input type=\"radio\" name=\"source\" value=\"friend\" /> Friend</label>\n <label><input type=\"radio\" name=\"source\" value=\"other\" /> Other</label>\n\n <form-show-if conditions=\"source=other\">\n <label for=\"source-other\"\n >Please specify\n <input type=\"text\" id=\"source-other\" name=\"source-other\" />\n </label>\n </form-show-if>\n</fieldset>Specific value matching:
\n<form-show-if conditions=\"email=test@example.com\">\n <label for=\"debug-info\"\n >Debug Information\n <textarea id=\"debug-info\" name=\"debug-info\"></textarea>\n </label>\n <small>This field only shows for test accounts</small>\n</form-show-if>Like all good web components, form-show-if follows progressive enhancement principles. If JavaScript fails to load or the browser doesn’t support custom elements, your form still works—users just see all the fields all the time. Not ideal for the user experience, but nothing breaks either.
The component is lightweight, has no dependencies, and works in all modern browsers.
\nI’ve put together a comprehensive demo showing various use cases and configurations over on GitHub.
\nThe demo includes examples of:
\nYou can view the entire project (and suggest enhancements) over on the form-show-if component’s GitHub repo. The component is available as both a standard script and an ES module, so you can integrate it however works best for your project.
\nInstallation is straightforward—just include the script in your page and start using the form-show-if element. No build step required, no framework dependencies, just clean, standards-based progressive enhancement.
Late last year, I probed an LLM’s responses to HTML code generation prompts to assess its adherence to accessibility best practices. The results were unsurprisingly disappointing — roughly what I’d expect from a developer aware of accessibility but unsure how to implement it. The study highlighted key areas where training data needs improvement.
","summary":"Late last year, I probed an LLM’s responses to HTML code generation prompts to assess its adherence to accessibility best practices. The results were unsurprisingly disappointing — roughly what I’d expect from a developer aware of accessibility but unsure how to implement it. The study highlighted key areas where training data needs improvement.
","content_html":"Late last year, I probed an LLM’s responses to HTML code generation prompts to assess its adherence to accessibility best practices. The results were unsurprisingly disappointing — roughly what I’d expect from a developer aware of accessibility but unsure how to implement it. The study highlighted key areas where training data needs improvement.
\nI get it — you probably rolled your eyes at yet another “AI and accessibility” post. Maybe you think AI-assisted coding is overhyped, environmentally harmful, unreliable, or just plain dangerous for our craft. I share many of those concerns. But here’s the thing: whether we like it or not, codegen models aren’t going anywhere. GitHub Copilot has millions of users, and tools like Claude Code and Cursor are rapidly gaining popularity.
\nSo we have a choice: we can complain about the inevitable tide of AI-generated garbage code, or we can get in there and figure out how to make it better — especially when it comes to accessibility.
\nWe’re facing a looming wave of inaccessible code that will be extremely difficult to remediate later. The foundation models are already being trained on the collective output of the web’s development community — a community that doesn’t have a high bar high for accessibility already. Codegen models are a massive consultancy staffed with full StackOverflow developers. We need to figure out how to make them part of the solution, not part of the problem.
\nIt’s also worth noting that the better we make the output of these models, the fewer bugs will be generated. That, in turn, means fewer accessibility issues to fix later. If we don’t, there are plenty of AI-assisted scanners out there happy to burn the rainforest to find and remediate the bugs after the fact. We risk doubling the environmental impact—once to generate the bug, and again to fix it. That’s not the future I want. The reality here is that the only way to deal with this flood of AI-generated code is to make sure it’s good code in the first place.
\nRather than relying on anecdotal evidence or cherry-picked examples, I built a systematic approach to evaluate how well LLMs — starting with GPT-4 — generate accessible HTML. The methodology is straightforward but comprehensive: I created a Python testing framework that sent carefully crafted prompts to Azure OpenAI’s GPT 4 model, collected the generated HTML responses, and then manually analyzed these responses for accessibility compliance.
\nHere’s how it works:
\nPrompt Engineering: I designed prompts that ask for specific UI components—form fields, navigation menus, interactive elements—without explicitly mentioning accessibility requirements. This gives us a baseline of what the model considers “standard” output. I included one prompt that specifically requested accessibility features to see if the model could improve when guided. I suspected it would often add ARIA attributes without addressing underlying issues, but I wanted to validate that too.
\nResponse Collection: For each prompt, I generated 10 iterations at high temperature (0.95) to capture the model’s range of responses. Each unique response got saved as an individual HTML file for analysis.
\nSystematic Analysis: I manually review each generated code snippet, cataloging accessibility errors, warnings, and missed opportunities. I tried using the LLM as a judge, but even with a detailed rubric, the results were poor. My eval looked specifically for things like:
\nWhen I identified errors, I remediated them and committed the remediated file to the repo with a commit message that included all of the issues and warnings on its own line.
\nDiff-Based Retesting: I wanted to see if diff data could improve future codegen requests, so I created a tool to generate a collection of .diff files for each pattern that included the commit message as a header in each file. I then used those diff files as part of a new instance of the prompt to test whether the model can improve its output when guided.
After analyzing hundreds of generated code snippets, the results are sobering. The model consistently demonstrates what I’d describe as superficial awareness without true understanding — it knows accessibility concepts exist but fundamentally misunderstands their purpose and proper implementation.
\nHere are some of the patterns I’ve documented:
\nForm Label Disasters: When asked to create a required text field, the model failed to include a visible label:
\n<input\n type=\"text\"\n id=\"orangeColor\"\n name=\"orangeColor\"\n required\n placeholder=\"What color is an orange?\"\n/>Sure, the placeholder attribute is there, and in a pinch it will be included in a field’s accessible name calculation, but sighted users will lose the label as soon as they start typing.
ARIA Attribute Confusion: The model would routinely involve ARIA for no reason:
\n<label for=\"color-question\"\n >What color is an orange? <span style=\"color: red;\">*</span></label\n>\n<input\n type=\"text\"\n id=\"color-question\"\n name=\"color-question\"\n required\n aria-required=\"true\"\n aria-labelledby=\"color-question\"\n/>Here the for attribute already establishes the relationship between the label and input, so aria-labelledby is redundant. A bit of a nitpick, but the aria-required="true" is also unnecessary since the native required attribute already conveys that information to assistive technologies. aria-required="true" is only needed when creating custom form controls non-semantic markup.
Redundant ARIA: Keeping on the ARIA redundancy, consider examples like this:
\n<input\n type=\"radio\"\n id=\"option1\"\n aria-labelledby=\"label1\"\n aria-label=\"Option 1\"\n/>\n<label for=\"option1\" id=\"label1\">Option 1</label>This redundancy raises the question why‽
\nRequired Field Misapplication: For checkbox groups where users need to select “one or more,” the model often adds required to individual checkboxes:
<fieldset>\n <legend>What fruits do you like?</legend>\n <div>\n <input\n type=\"checkbox\"\n id=\"bananas\"\n name=\"fruits\"\n value=\"bananas\"\n required\n />\n <label for=\"bananas\">Bananas</label>\n </div>\n <div>\n <input\n type=\"checkbox\"\n id=\"oranges\"\n name=\"fruits\"\n value=\"oranges\"\n required\n />\n <label for=\"oranges\">Oranges</label>\n </div>\n <div>\n <input type=\"checkbox\" id=\"apples\" name=\"fruits\" value=\"apples\" required />\n <label for=\"apples\">Apples</label>\n </div>\n <div style=\"color: red; display: none;\" id=\"validation-error\">\n You must choose one or more fruits\n </div>\n</fieldset>This breaks the intended behavior—if any checkbox is marked required, it must be checked for form validation to pass. For a web component that addresses this limitation in HTML, see my post “Requirement Rules for Checkboxes.”
\nGrouped Field Confusion: Not understanding when to use fieldset and legend (or at least using role="group" and aria-labelledby) on a field group:
<div>\n <label>Select Theme:</label>\n <div>\n <input type=\"radio\" id=\"light\" name=\"theme\" value=\"light\" />\n <label for=\"light\">Light</label>\n </div>\n <div>\n <input type=\"radio\" id=\"dark\" name=\"theme\" value=\"dark\" />\n <label for=\"dark\">Dark</label>\n </div>\n <div>\n <input type=\"radio\" id=\"high-contrast\" name=\"theme\" value=\"high-contrast\" />\n <label for=\"high-contrast\">High Contrast</label>\n </div>\n <p>You can change this later</p>\n</div>Ideally, this would be a fieldset with a legend and the descriptive text would appear right after the legend and be associated with the group using aria-describedby.
Color-Only Error Indication: Generating error states that rely solely on color changes without text indicators or proper ARIA attributes to convey the error state to screen readers.
\nUnnecessary Role Additions: Adding redundant roles like role="radiogroup" to properly structured fieldsets containing radio inputs, where the native semantics already provide the correct accessibility tree.
Missing Error State Management: Failing to include aria-invalid="true" on fields with errors or properly associate error messages with their corresponding form controls.
Lack of Wayfinding Help: Failing to include navigational labels and aria-current="page" in a breadcrumb nav.
Adding Unnecessary JavaScript: Even though it was instructed to only generate JavaScript when absolutely necessary, the model would often inject JavaScript for simple tasks that could be handled with HTML and CSS alone.
\nHere’s where things get interesting — and hopeful. When I retested using prompts that included accessibility hints, the model’s output improved dramatically. Not just slightly better, but often going from fundamentally broken to genuinely accessible.
\nFor example, when I added diff data related to fieldset use to a prompt about radio button groups, the model switched from generating meaningless div wrappers to proper semantic structures.
This suggests the model can produce quality code if properly primed. It also indicates that the training data likely lacks sufficient examples of well-implemented accessible components. If the model had been trained on a richer dataset of accessible code, it might not need such explicit guidance to produce good results.
\nThese findings point to several concrete approaches for improving accessibility in AI-generated code:
\nEnhanced Training Data: The models need exposure to more high-quality, accessible code examples. Current training data clearly overrepresents inaccessible implementations. We need comprehensive datasets of properly implemented accessible components across different frameworks and use cases.
\nAccessibility-Aware Fine-Tuning: Post-training refinement specifically focused on accessibility compliance could help models prioritize inclusive patterns. This could involve training on accessibility-annotated code pairs — showing inaccessible implementations alongside their accessible counterparts, like the diffs do.
\nPrompt Engineering Guidelines: Tool creators should integrate accessibility considerations into their default system prompts. Instead of just asking for “clean, semantic HTML,” prompts should provide detailed instructions to demonstrate accessibility best practices rather than pointing at often vague guidelines like WCAG.”
\nIntegrated Accessibility Validation: IDE integrations should include real-time accessibility linting of AI-generated code, providing immediate feedback and suggestions for improvement.
\nCommunity-Contributed Training Data: We should coordinate our efforts to produce an open source, high-quality accessible code dataset so that this data can be integrated into future models.
\nThe data from this project provides a roadmap for where to focus these efforts. We’re not dealing with models that are fundamentally incapable of generating accessible code — we’re dealing with models that haven’t been properly trained to prioritize accessibility by default.
\nIf you want to conduct similar evaluations with your preferred models or specific use cases, I’ve created a template repository with the testing framework: CodeGen Model Eval and Refine Tools. It includes the Python testing harness, prompt templates, and analysis guidelines to get you started.
\nThe complete findings, methodology details, and code samples for my research are available on GitHub. I encourage you to dig into the data — it’s eye-opening and frustrating, yes, but ultimately actionable.
\nThere are other projects and research exploring this space as well. A few worth checking out:
\nWe’re at a critical moment where the patterns established in AI-assisted development will shape the accessibility of the web for years to come. We can either let this technology amplify existing accessibility problems, or we can tackle the problems head-on and be part of the solution.
\n","social_text":"I probed an LLM’s responses to HTML code generation prompts to assess its adherence to accessibility best practices. The results showed key areas where better training data is needed.","url":"https://www.aaron-gustafson.com/notebook/identifying-accessibility-data-gaps-in-codegen-models/","tags":["accessibility","AI/ML","HTML"],"image":"https://www.aaron-gustafson.com/i/posts/2025-10-15/hero.png","date_published":"2025-10-16T19:12:02Z"},{"id":"https://www.aaron-gustafson.com/publications/books/learning-web-design-sixth-edition/","title":"📗 Learning Web Design","content_html":"Do you want to build web pages but have no prior experience? This friendly guide is the perfect place to start. You'll begin at square one, learning how the web and web pages work, and then steadily build from there. By the end of the book, you'll have the skills to create a simple site with multicolumn pages that adapt for mobile devices.
\n","url":"https://www.oreilly.com/library/view/learning-web-design/9781098137670/","tags":["accessibility","CSS","HTML","JavaScript","progressive enhancement","responsive web design","web design","web development","web standards"],"date_published":"2025-05-01T00:00:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/a-web-component-for-conditional-dependent-fields/","title":"✍🏻 A Web Component for Conditional Dependent Fields","excerpt":"A few weeks back I released a web component to enable you to add requirement rules to checkbox groups. Continuing in the form utility space, I’ve created a new web component that allows you to make fields required based on the values of other fields: form-required-if.
A few weeks back I released a web component to enable you to add requirement rules to checkbox groups. Continuing in the form utility space, I’ve created a new web component that allows you to make fields required based on the values of other fields: form-required-if.
A few weeks back I released a web component to enable you to add requirement rules to checkbox groups. Continuing in the form utility space, I’ve created a new web component that allows you to make fields required based on the values of other fields: form-required-if.
The form-required-if web component, which is based on a jQuery plugin I’d written in 2012, looks like this:
<form-required-if conditions=\"email=*\">\n <label\n >Required if there’s an email value\n <input name=\"depends-on-email\" />\n </label>\n</form-required-if>You wrap any field (and its label) in the component and then declare the conditions under which it should be required in the conditions attribute.
Each condition is a key/value pair where the key aligns to the name of the field you need to observe and the value is the value that could trigger the dependency. If any value should trigger the dependency, you use an asterisk (*) as the value. In the example above, the field will become required when any value is assigned to the field matching [name="email"].
This conditions attribute can be populated with as many or as few dependencies as make sense for your use case. Multiple conditions are separated by double vertical pipes (|| a.k.a. or) as in this example:
<form-required-if conditions=\"email=*||test=3\">\n <label\n >Depends on email or test field\n <input name=\"depends-on-email-or-test\" />\n </label>\n</form-required-if>Here the field depends on one of the following conditions being true:
\n[name="email"] has a value, or[name="test"] has a value of “3”If the field you reference doesn’t exist, no errors will be thrown, it will just quietly exit.
\nIf you typically use an asterisk or similar to indicate a field is required, this web component can support that through one or both of the following attributes:
\nindicator - This attribute is where you define the indicator itself. It could be something as simple as a string (e.g., *), or even full-blown HTML.indicator-placement - As you can probably guess, this attribute is used to set the position of the indicator. If you want it at the start of the label text, you give it the value “before.” If you want it after the text, you use “after” or don’t use the attribute at all. Indicators will be placed after the label text by default.Here’s an example with a custom indicator that is HTML:
\n<form-required-if conditions=\"email=*\" indicator=\"<b>*</b>\">\n <label\n >Depends on email\n <input name=\"dep2\" />\n </label>\n</form-required-if>If you don’t include markup in your indicator, it will be automatically wrapped in span when injected into the DOM. The hidden and aria-hidden attributes are used to toggle its visibility, relative to the requirement state of the field.
I put together a comprehensive demo of the web component over on GitHub:
\nYou can view the entire project (and suggest enhancements) over on the form-required-if component’s Github repo.
This is a fantastic run-through of HTML and CSS features that help reduce our dependence on JavaScript (and improve #accessibility). Great work Kilian!
\n","social_text":"This is a fantastic run-through of #HTML and #CSS features that help reduce our dependence on #JavaScript (and improve #accessibility).","url":"https://www.aaron-gustafson.com/notebook/links/don-t-use-js-for-that-moving-features-to-css-and-html-by-kilian-valkhof/","external_url":"https://www.youtube.com/watch?v=IP_rtWEMR0o","tags":["HTML","CSS","JavaScript","progressive enhancement"],"date_published":"2024-07-29T17:22:19Z"},{"id":"https://www.aaron-gustafson.com/notebook/requirement-rules-for-checkboxes/","title":"✍🏻 Requirement Rules for Checkboxes","excerpt":"HTML checkboxes debuted as part of HTML 2.0 in 1995. Our ability to mark an individual checkbox as being required became part of the HTML5 spec that published in 2014. A decade later, we can still only make checkboxes required on a case-by-case basis. To overcome this limitation, I had created a jQuery plugin that allowed me to indicate that a user should choose a specific number of items from within a checkbox group. Yesterday I turned that plugin into a web component: form-required-checkboxes.
HTML checkboxes debuted as part of HTML 2.0 in 1995. Our ability to mark an individual checkbox as being required became part of the HTML5 spec that published in 2014. A decade later, we can still only make checkboxes required on a case-by-case basis. To overcome this limitation, I had created a jQuery plugin that allowed me to indicate that a user should choose a specific number of items from within a checkbox group. Yesterday I turned that plugin into a web component: form-required-checkboxes.
HTML checkboxes debuted as part of HTML 2.0 in 1995. Our ability to mark an individual checkbox as being required became part of the HTML5 spec that published in 2014. A decade later, we can still only make checkboxes required on a case-by-case basis. To overcome this limitation, I had created a jQuery plugin that allowed me to indicate that a user should choose a specific number of items from within a checkbox group. Yesterday I turned that plugin into a web component: form-required-checkboxes.
Before I tuck into the details, I’ll start by saying that the web component begins with the assumption that you are following best practices with respect to form markup:
\nfieldset with a legendname (e.g., “foo[]”).In other words, they should look something like this:
\n<fieldset>\n <legend>Group 1 label</legend>\n <ul>\n <li>\n <label>\n <input type=\"checkbox\" name=\"foo[]\" value=\"1\" />\n First item\n </label>\n </li>\n <li>\n <label>\n <input type=\"checkbox\" name=\"foo[]\" value=\"2\" />\n Second item\n </label>\n </li>\n <!-- options continue -->\n </ul>\n</fieldset>To use the web component, you wrap the group in a form-required-checkboxes element and then include the JavaScript to initialize it.
<form-required-checkboxes>\n <fieldset>\n <legend>Group 1 label</legend>\n <!-- etc. -->\n </fieldset>\n</form-required-checkboxes>\n\n<!-- at the end of your document -->\n<script src=\"/js/web-components/form-required-checkboxes.js\" async></script>If you’re following right along, there’s an error waiting for you in the console — we need to set the requirement rules.
The form-required-checkboxes element requires at least one attribute to function, but using some of the others you can more fully customize the experience for users:
required - Represents the range of required values. You can set this up in one of three ways depending on your needs:\nnotice (optional) - This is a string description that explains details of the required value in plain language. If you don’t supply one, the component will create one for you based on the current language (if supported). This description will be added as a small element within the component (as a sibling to the fieldset).error (optional) - This is a string validation error you’d like to be shown when the validation criteria is not met. If not provided, an appropriate error message will be generated based on the current language (if supported).lang (optional) - Language code for localized messages (e.g., “en,” “es,” “fr,” “de”). Falls back to the nearest ancestor’s lang attribute or the document language.The component now includes built-in translations for 16 languages: English, Chinese (Mandarin), Hindi, Spanish, French, Arabic, Bengali, Portuguese, Russian, Japanese, German, Punjabi, Javanese, Korean, Vietnamese, and Italian. Messages are automatically generated based on the lang attribute.
You can use it like this:
\n<form-required-checkboxes required=\"3\" lang=\"es\">\n <fieldset>\n <legend>Opciones</legend>\n <!-- Will display: \"Elija 3 de la lista\" -->\n </fieldset>\n</form-required-checkboxes>The component automatically detects the language from the lang attribute on the element itself, the nearest ancestor element, or the document’s lang attribute, falling back to English if none is found.
You can also register custom translations or override existing ones using the FormRequiredCheckboxesElement.registerTranslations() static method. Regional language codes (e.g., en-US, es-MX) automatically fall back to their base language.
I put together a comprehensive demo of the web component over on GitHub:
\nYou can view the entire project (and suggest enhancements) over on the component’s Github repo.
\n","social_text":"Currently, we can only make checkboxes required or not, individually. In some cases you need to be able to set a specific number of checkboxes that need to be checked. My `form-required-checkboxes` web component enables that.","url":"https://www.aaron-gustafson.com/notebook/requirement-rules-for-checkboxes/","tags":["accessibility","forms","HTML","JavaScript","progressive enhancement","web components","web forms"],"date_published":"2024-07-05T21:08:34Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/an-even-faster-microsoft-edge/","title":"🔗 An even faster Microsoft Edge","content_html":"Progressive enhancement for the win! This post from the Edge team demonstrates that producing markup directly rather than relying on JavaScript to do it for you is faster — even in the browser UI!
\n\n\n","social_text":"Progressive enhancement for the win! This post from the Edge team demonstrates that producing markup directly rather than relying on JavaScript to do it for you is faster — even in the browser UI!","url":"https://www.aaron-gustafson.com/notebook/links/an-even-faster-microsoft-edge/","external_url":"https://blogs.windows.com/msedgedev/2024/05/28/an-even-faster-microsoft-edge/","tags":["progressive enhancement","browsers","HTML","CSS"],"date_published":"2024-05-29T16:32:54Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/purepwa-a-radical-u-turn-in-web-development/","title":"🔗 PurePWA — A Radical U-Turn in Web Development","content_html":"In this project, we built an entirely new markup-first architecture that minimizes the size of our bundles of code, and the amount of JavaScript code that runs during the initialization path of the UI. This new internal UI architecture is more modular, and we now rely on a repository of web components that are tuned for performance on modern web engines. We also came up with a set of web platform patterns that allow us to ship new browser features that stay within our markup-first architecture and that use optimal web platform capabilities.
\n
I love experiments that showcase the power of the web platform and this is no exception: a pure web standards-powered Progressive Web App (PWA) replete with straightforward web components, view transitions, and more.
\n","social_text":"I love experiments that showcase the power of the web platform and this is no exception: a pure #WebStandards-powered #ProgressiveWebApp","url":"https://www.aaron-gustafson.com/notebook/links/purepwa-a-radical-u-turn-in-web-development/","external_url":"https://medium.com/@neerventure/purepwa-a-radical-u-turn-in-web-development-a386c0dc092e","tags":["progressive web apps","HTML","web components","CSS","JavaScript"],"image":"https://miro.medium.com/v2/resize:fit:1200/1*ZEDw2ropDtOTGm_RUIMJlg.png","date_published":"2024-02-02T18:38:09Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/acessibilidade-o-verdadeiro-diferencial-dos-livros-digitais/","title":"🔗 Acessibilidade: O verdadeiro diferencial dos livros digitais","content_html":"It’s nice to see folks in the digital book space beginning to embrace the potential of their medium:
\n\n\n","social_text":"It's nice to see folks in the digital book space beginning to embrace the potential of their medium. (Original link in Brazilian Portuguese.)","url":"https://www.aaron-gustafson.com/notebook/links/acessibilidade-o-verdadeiro-diferencial-dos-livros-digitais/","external_url":"https://www.publishnews.com.br/materias/2023/12/18/acessibilidade-o-verdadeiro-diferencial-dos-livros-digitais","tags":["HTML","industry"],"image":"https://www.publishnews.com.br/estaticos/uploads/2023/12/NUnd53uTzgmyUSR0kQga1npwoiqlCK29dSDnFDRcdah5OQypkRpt8bYhzbjWxmDGF3E4PcPUAPnV4Mb4.jpg","date_published":"2024-01-06T05:06:26Z"}]}Para abraçar verdadeiramente o potencial do digital, é essencial adotar uma mentalidade ‘digital first’. Isso significa que o conteúdo digital não deve ser uma simples transposição do impresso, mas sim algo que aproveita ao máximo as funcionalidades únicas do meio digital.
\n