That framing cuts through a lot of the marketing nonsense. The promise is always that AI will help people do their jobs better. The deployment story, far too often, is that a human gets stuck reviewing machine output at impossible speed while absorbing the blame when things go wrong. That’s not augmentation; it’s a liability dump.

In this piece, Eric digs into accessible name length, accidental activation, stacking context weirdness, and progressive enhancement too. That kind of thoroughness matters because patterns like this can go sideways in a hurry when folks cargo-cult only the CSS and skip the reasoning.

What’s exciting to me here is not “AI turned a PDF into an app” so much as what made that possible: components, tokens, utilities, and enough design-system clarity to give the model something useful to work with. That’s a big part of the story so many people miss. If your system is inconsistent, vague, or poorly documented, AI is just going to amplify that mess.

What I especially like here is the framing: not simply “supported” or “unsupported,” but whether a feature is actually advisable in Shadow DOM, how it crosses boundaries, and where browsers still disagree. That’s the kind of nuance you need when you’re building real components instead of admiring specs from afar.

This is not a minor bug trend. It is a systematic civil-rights failure that has now found its way into software as a whole, through lightning-fast adoption of AI systems that are trained on over 20 years of institutional barriers.

The numbers here are bad enough on their own, but what makes this especially troubling is where these systems are being deployed: education, healthcare, finance, employment, and other places people can’t simply opt out of. That’s why I appreciate how direct this project is about accountability. If we automate interface generation without putting accessibility at the center, we’re automating exclusion.

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.

If 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.

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.

We 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.

I also appreciate the callback in the title. We’ve been here before. The particulars may be new, but the core challenge is familiar: how do we build resilient, inclusive systems when the output is fluid, personalized, or otherwise beyond a designer’s exact control? Accessibility is not a bolt-on answer to that question; it’s where the answer has to begin.

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.

There are a lot of grim numbers in here, but the one that really sticks with me is how many of the same, eminently-fixable issues continue to dominate year after year. We’re still talking about contrast, missing labels, empty buttons, and missing alt text. In other words, this is not a story about edge cases. It’s a story about fundamentals.

I particularly appreciated how plainly this post describes a mismatch a lot of teams create for themselves: wrapping largely-static content in an app shell, then shipping a pile of JavaScript just to re-assert what the server already knew. MDN’s new approach feels refreshing, despite being grounded in age-old best practices: Keep the content first-class, treat interactivity as optional (and isolated), and only ship what the page actually needs.

There’s a lot to like here, but more than anything I love seeing MDN embrace an architecture that’s truly aligned with the platform it documents.

I appreciate how clearly Anil connects dots that too many people are still treating as separate problems. This isn’t just about AI summaries siphoning traffic from publishers or slop code drowning maintainers or bad actors ignoring long-standing norms like robots.txt. It’s all of those things at once. The through-line is extraction: taking value from open systems without giving anything back, then undermining the very ecosystems that made that extraction possible in the first place.

The good of the web only exists because of the openness of the web. They can’t just keep on taking and taking without expecting people to finally draw a line and saying “enough”.

If you care about the web as a public good, this post is worth your time.

It’s one of those tools that immediately makes me want to crack open a demo and start playing. What’s especially nice is that it doesn’t ask you to invent some parallel configuration universe if you don’t want to; it can just inspect the variables you already have and give you a UI for experimenting with them. That makes it feel less like a framework and more like a really practical enhancement to the way many of us already work.

In other words, AI use is reinforcing what good documentation has always required: clear structure, explicit language, sensible headings, and fewer assumptions about what the reader already knows. That’s good for machines, sure, but it’s even better for people navigating with assistive tech, reading in a second language, or simply trying to get an answer quickly.

AI has not invented new rules for writing, it has made the cost of ignoring the old ones obvious.

This is the part too many teams miss: accessibility doesn’t end at the component boundary. A well-built component library can give you a stronger foundation, but it can’t guarantee the right labels, the right heading structure, the right focus management, or the right overall experience once those pieces are assembled into an interface. That work still requires judgment, care, and testing with actual people.

I also appreciate Mark’s call for more ambition here. Too often, we talk about the web as if it’s destined to be an OS for web apps rather than a public-interest platform in its own right. That’s not inevitable. But getting somewhere better requires recognizing that refusal, delay, and strategic disinterest can be every bit as consequential as formal opposition.

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.

Update: This post has been refreshed to cover the component’s current loading options, throttled input behavior, accessibility model, and localization hooks.

This is a modern replacement for my old jQuery Easy Validation Rules plugin, reimagined as a web component with native form validation integration.

To get started, associate the component with an input element using the for attribute and define your validation rules:

<form><labelfor=“username”>Username:</label><inputtype=“text”id=“username”name=“username”required/><form-validation-listfor=“username”><ul><lidata-pattern=“[A-Z]+”>At least one capital letter</li><lidata-pattern=“[a-z]+”>At least one lowercase letter</li><lidata-pattern=“[\d]+”>At least one number</li></ul></form-validation-list><buttontype=“submit”>Submit</button></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.

# What’s happening under the hood?

The component:

1. Associates with an input via the for attribute (just like a label element)
2. Finds all elements with data-pattern attributes
3. Tests the input value against each pattern when the configured trigger fires
4. Adds validation-matched or validation-unmatched classes and visual indicators accordingly
5. Inserts localized, visually hidden state text once the field has a value
6. Updates a single polite live region while users type
7. Uses setCustomValidity() to integrate with native form validation
8. Prevents form submission until all rules match

The cascade animation, controlled by each-delay, creates a pleasant visual effect as rules are checked sequentially. It is a small touch, but a nice one.

# Whose rules? Your rules.

Define rules using regular expression patterns in the data-pattern attribute:

<form-validation-listfor=“password”><ul><!-- Length requirements --><lidata-pattern=“.{8,}”>At least 8 characters</li><lidata-pattern=“.{8,32}”>Between 8 and 32 characters</li><!-- Character type requirements --><lidata-pattern=“[A-Z]+”>At least one uppercase letter</li><lidata-pattern=“[a-z]+”>At least one lowercase letter</li><lidata-pattern=“[\d]+”>At least one number</li><lidata-pattern=“[!@#$%^&]+“>At least one special character</li><!-- Format requirements --><lidata-pattern=”.+@.+..+“>Valid email format</li><lidata-pattern=”+$“>Only letters and numbers</li></ul></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.

# Input event too noisy? No worries.

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-listfor=”email“trigger-event=”blur“><ul><lidata-pattern=”.+@.+“>Contains @ symbol</li><lidata-pattern=”.+@.+..+“>Valid email format</li></ul></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.

# Wanna adjust the cascade delay? Go for it.

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-listfor=”password“each-delay=”100“><!-- rules --></form-validation-list>

Set it to “0” to remove the cascade effect entirely and check all rules simultaneously.

# Need full design control? You got it.

If 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:

<style>.is-valid{border-color: green;}.is-invalid{border-color: red;}.rule-pass{color: green;}.rule-fail{color: red;}</style><form-validation-listfor=”username“field-valid-class=”is-valid“field-invalid-class=”is-invalid“rule-matched-class=”rule-pass“rule-unmatched-class=”rule-fail“><ul><lidata-pattern=”.{5,}“>At least 5 characters</li><lidata-pattern=”[!@#]+">Special char (!@#)</li></ul></form-validation-list>

This approach lets you use class names that match your existing CSS architecture, rather than 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:

form-validation-list{–rule-matched-icon:”✅“;–rule-unmatched-icon:”❌“;–rule-icon-size: 1.2em;–rule-matched-color: #28a745;–rule-unmatched-color: #dc3545;}

# TypeScript or framework project? You’re covered.

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.

# Bit of a control freak? There’s an API.

If you really want to get into the weeds, you can also listen for validation changes in your JavaScript code:

const validationList = document.querySelector(“form-validation-list”);validationList.addEventListener(“form-validation-list:validated”,(event)=>{const{ isValid, matchedRules, totalRules, field }= event.detail;console.log(</span><span class="token string">Matched </span><span class="token interpolation"><span class="token interpolation-punctuation punctuation">${</span>matchedRules<span class="token interpolation-punctuation punctuation">}</span></span><span class="token string"> of </span><span class="token interpolation"><span class="token interpolation-punctuation punctuation">${</span>totalRules<span class="token interpolation-punctuation punctuation">}</span></span><span class="token string"> rules</span><span class="token template-punctuation string">);console.log(</span><span class="token string">Field is </span><span class="token interpolation"><span class="token interpolation-punctuation punctuation">${</span>isValid <span class="token operator">?</span> <span class="token string">"valid"</span> <span class="token operator">:</span> <span class="token string">"invalid"</span><span class="token interpolation-punctuation punctuation">}</span></span><span class="token template-punctuation string">);});

The event fires after validation completes and gives you the current state. Nice and tidy.

You can also manually trigger validation and check the element’s current state at any time:

const validationList = document.querySelector(“form-validation-list”);// Trigger validationconst isValid = validationList.validate();console.log(“Is valid:”, isValid);// Check current stateconsole.log(“Current state:”, validationList.isValid);

# Global site? Relaje!

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 --><form-validation-listfor=”contrasena“announcement=”{matched} de {total} criterios cumplidos“rule-matched-alt=”Criterio cumplido“rule-unmatched-alt=”Criterio pendiente“validation-message=”Por favor, cumple todos los requisitos ({matched} de {total})“><ul><lidata-pattern=”[A-Z]+“>Al menos una letra mayúscula</li><lidata-pattern=”[a-z]+“>Al menos una letra minúscula</li><lidata-pattern=”[\d]+“>Al menos un número</li></ul></form-validation-list><!-- French --><form-validation-listfor=”mot-de-passe“announcement=”{matched} critères satisfaits sur {total}“rule-matched-alt=”Critère satisfait“rule-unmatched-alt=”Critère non satisfait“validation-message=”Veuillez satisfaire à toutes les exigences ({matched} sur {total})“><ul><lidata-pattern=”[A-Z]+“>Au moins une lettre majuscule</li><lidata-pattern=”[a-z]+“>Au moins une lettre minuscule</li><lidata-pattern=”[\d]+“>Au moins un chiffre</li></ul></form-validation-list>

# Is it a progressive enhancement? Heck yeah!

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?

# Is it screen reader accessible? Yep.

The component is built with accessibility in mind:

• Proper description support: The validation list is automatically associated with the input via aria-describedby, and if the field already has aria-describedby, the original value is preserved.
• A concise announcement model: With the default 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.
• State restoration on blur: When focus leaves the field, any pending validation timeouts are cleared and the full criteria list is restored so returning to the field announces the final criteria state.
• Localized rule state: Once the field has a value, each rule gets visually hidden localized state text in the DOM, which is more robust than relying on CSS-generated content alone.

If you have suggestions for other ways to improve the accessibility of this component, please open an issue on GitHub.

# Does it integrate with the browser’s validation engine? Naturally.

The component uses setCustomValidity() to participate in native form validation:

• When all rules match, custom validity is cleared
• When rules don’t match, a custom validity message is set
• Form submission is prevented until all rules pass
• Works with :valid and :invalid CSS pseudo-classes
• Compatible with the Constraint Validation API

const form = document.querySelector(“form”);const field = document.getElementById(“username”);form.addEventListener(“submit”,(e)=>{if(!form.checkValidity()){e.preventDefault();console.log(“Validation failed:”, field.validationMessage);}});

# Here’s a real-world example

Here’s a complete password validation setup:

<form><labelfor=”password“>Password:</label><inputtype=”password“id=”password“name=”password“required/><form-validation-listfor=”password“><ul><lidata-pattern=”.{8,}“>At least 8 characters</li><lidata-pattern=”[A-Z]+“>At least one uppercase letter</li><lidata-pattern=”[a-z]+“>At least one lowercase letter</li><lidata-pattern=”[\d]+“>At least one number</li><lidata-pattern=”[!@#$%^&]+">At least one special character (!@#$%^&)</li></ul></form-validation-list><buttontype=“submit”>Submit</button></form>

Users see exactly which requirements they have met and which they still need to satisfy. That tends to be a lot kinder than springing the whole list on them after submit.

# Play with it

Check out the demo with various examples:

# Grab it

View the project on GitHub.

Install via npm:

npminstall @aarongustafson/form-validation-list

For most projects, import the guarded auto-definition helper:

import“@aarongustafson/form-validation-list/define.js”;

If you want to control the tag name yourself, import FormValidationListElement and register it manually.

Happy validating!

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.

# Basic usage

All you need to do is wrap your form in the component:

<form-saver><formaction=“/contact”method=“post”><label>Name<inputname=“name”autocomplete=“name”/></label><label>Email<inputname=“email”type=“email”autocomplete=“email”/></label><label>Message<textareaname=“message”></textarea></label><buttontype=“submit”>Send</button></form></form-saver>

That’s it. The component targets the first descendant form, saves values as users 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 have 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.

# What actually gets saved?

form-saver supports the controls most of us reach for every day:

• Text-style input fields
• textarea elements,
• select elements (including multi-selects), and
• checkbox and radio controls.

File inputs are intentionally excluded.

Because 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.

# Want to keep a few fields after submit?

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.

That is what the retain attribute is for:

<form-saverretain=“name email”><formaction=“/contact”method=“post”>…</form></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 betrayed them personally.

# Better yet, let users decide

Persisting form data can be incredibly helpful, but there is a human side to this too. Just because we can keep someone’s information around does not necessarily mean we should do it without asking. That is where retain-choice comes in. It lets you be useful without getting presumptuous.

Add it alongside retain and form-saver will inject an opt-in checkbox for the user. Nice and easy:

<form-saverretain=“name email”retain-choiceretain-choice-label=“Store my contact information for later”><formaction=“/contact”method=“post”>…</form></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. Gotta love a little informed consent.

Need to place that control somewhere more appropriate in your layout? Use retain-choice-container to point to a CSS selector:

<form-saverretain=“name email”retain-choiceretain-choice-label=“Remember my details next time”retain-choice-container=“.form-footer”><formaction=“/contact”method=“post”>…<divclass=“form-footer”><buttontype=“submit”>Send</button></div></form></form-saver>

That gives you a lot more control over the experience without making you build the retention UI yourself.

# Need a custom storage key?

By 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-saverstorage-key=“checkout:shipping-address”><formaction=“/checkout/shipping”method=“post”><label>Street Address<inputname=“street-address”autocomplete=“street-address”/></label><label>Postal Code<inputname=“postal-code”autocomplete=“postal-code”/></label><buttontype=“submit”>Continue</button></form></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. Sometimes explicit is just easier. Sometimes it is the only way to stay sane.

# Want to drive it yourself?

If you need more direct control, the component exposes a few methods:

const saver = document.querySelector(“form-saver”);// Persist the current statesaver.saveFormState();// Restore previously saved valuessaver.restoreFormState();// Clear out anything stored for this formsaver.clearSavedData();

That can be useful when you want to pair it with your own UI, analytics, or some custom workflow around save and restore. Or when you just like being the one driving and do not fully trust anything labeled “automatic.”

# Progressive enhancement, as usual

This 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.

That’s a pretty good trade-off.

And 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.

# Demo

If you want to kick the tires, I put together a live demo with examples of the retention options as well:

# Grab it

The project is available on GitHub, and you can install it from npm:

npminstall @aarongustafson/form-saver

If you want the easiest path, just import it and let the component register itself:

import“@aarongustafson/form-saver”;

If you would rather define it yourself, you can import the class directly:

import{ FormSaverElement }from“@aarongustafson/form-saver/form-saver.js”;customElements.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.

I know someone that uses her screen reader on her mobile phone, but when she’s on her desktop computer, she uses a mangifier.

Different contexts, different tools, same person.

I know someone that uses voice controls on his computer. He uses direct commands like “Click Contact Us” when he’s near the start of his day, and commands like “Click link, twelve” when he’s near the end of his day with lower energy and less clear speech and a dry mouth.

Different energy/capacity, same tools, same person.

I know someone that uses a switch on his computer. He also uses the onscreen keyboard on his computer. The one that he chooses reflects the task he’s trying to accomplish and how he can minimize switching between the tools.

Different task, same context, same tools, same person.

Disability is not black and white… it’s every shade of every colour.

We’re in the process of a major overhaul to this plugin. There was a lot of infrastructural work to do to modernize the plugin and set the stage for a host of new features to make designers more productive when it comes to making their designs more accessible. This release incorporates a lot of that foundational work, notably:

• Annotations are now presented as Figma-native Dev Mode annotations; this greatly reduces the working overhead of the plugin and reduces visual clutter in the document. We’ve also color-coordinated the icons in the Annotation Set viewer to the labels you see in the Dev Mode annotations, making it easier to scan.
• Legacy annotation tables will automatically be migrated into the new system. The visual readout tables will be hidden when this happens, but are still accessible if you need to copy or reference them. We’ve also included a tool to clean up these old layers when you’re ready.
• Annotations are now managed in a single UI rather than being separated, based on whether they impact focus order. This means you don’t need to jump back & forth between tools to properly annotate your designs.
• We’ve organized and expanded the list of W3C roles available in the role picker. Additionally, the form now adapts to the role, offering you only the relevant fields and reducing distraction. We also added a description field, should you need it.

We also fixed bugs related to duplicating layers. You can now copy layers and the annotations will go along for the ride, becoming a new Annotation Set. Similarly, you can now duplicate pages and the annotations — which are page-bound — will be re-generated. It’s worth noting that this may take some time on particularly large pages.

This release has been a long time coming, but I’m incredibly proud of the team that’s been working so diligently on this, particularly Ashish Singh from HCL and Michael Fairchild, Scott O’Hara, and Ben Truelove from Microsoft. Their attention to detail and encyclopedic knowledge of accessibility has been instrumental in getting this project to the place that it is.

And there’s more to come!