![\"Slide](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide3.png\")
Last week at Microsoft Build, Jessie Lorenz, Carie Fisher, and I gave a short talk on a question every AI-enabled product team should be asking: can your AI pass the accessibility test?
The core point was straightforward: AI does not fix a broken process; it accelerates whatever process you already have. If accessibility is already in the workflow, AI can help scale inclusion. If it’s not, AI will scale the same barriers teams are already shipping.
","summary":"Last week at Microsoft Build, Jessie Lorenz, Carie Fisher, and I gave a short talk on a question every AI-enabled product team should be asking: can your AI pass the accessibility test?
The core point was straightforward: AI does not fix a broken process; it accelerates whatever process you already have. If accessibility is already in the workflow, AI can help scale inclusion. If it’s not, AI will scale the same barriers teams are already shipping.
","content_html":"Last week at Microsoft Build, Jessie Lorenz, Carie Fisher, and I gave a short talk on a question every AI-enabled product team should be asking: can your AI pass the accessibility test?
\nThe core point was straightforward: AI does not fix a broken process; it accelerates whatever process you already have. If accessibility is already in the workflow, AI can help scale inclusion. If it’s not, AI will scale the same barriers teams are already shipping.
\n
Jessie Lorenz: Everybody here ships software on a pipeline that looks something like this, right? Planning, design, development and coding, code review and CI/CD, public release, and then feedback. And then you kind of turn around and start the whole merry-go-round again, incorporating feedback back into planning.
\nIt is a six-stage pipeline. You know it. I know it too. I know it as a blind PM at Microsoft and I know it as someone who was born blind and often encounters the accessibility errors or barriers that get shipped.
\nSo hold on to this pipeline, because everything we are about to talk about lands somewhere on it.
\n![\"Slide](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide4.png\")
Jessie: Let us look at what happens when you solve your accessibility issues in the planning process. If you do that, it is a conversation. It is usually free to fix.
\nWait until design? Well, it is going to cost you ten times more. Wait until it reaches development? One hundred times more. If you do not notice your accessibility barriers until they actually ship, it compounds even more: one thousand times more.
\nAnd each order of magnitude that compounds, if you really think about it, is a person, and multiples of people, being locked out of what you ship.
\nAccessibility debt is a lot like security debt, and you would not just let security debt lie. Accessibility debt should be treated the same.
\n![\"Slide](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide5.png\")
Jessie: So we’re all excited about AI, right? Well, it accelerates the pace of software development and it also accelerates the creation of accessibility barriers. Both sides of the coin are true.
\nWhy? AI is trained largely on a web that is inaccessible. AI learned from a web that is primarily inaccessible, full of barriers, and AI ships these barriers faster and in places where we’ve not seen them before.
\n![\"Slide](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide6.png\")
Jessie: Accessibility belongs in your workflow. We are talking today not about slowing things down, not about trying to make things harder. We are actually talking about catching things early, catching things when they are cheaper, and implementing accessibility checks in every stage of the workflow.
\nThat could be a lint rule in the editor. That could be a gate in CI. It could be a flag in code review. It is the same workflow that we talked about before, the same pipeline. It is just that each step has an accessibility check on it.
\n![\"Slide](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide7.png\")
Jessie: I really hope I can make this real for you.
\nPeople are always coming to talk to me about how to get money for their accessibility ideas. One guy came and talked to me and he was trying to get VC funding to re-carpet the San Francisco airport. He thought it would be a really good idea to give blind people canes that could guide them on this special carpet and the canes would have Bluetooth in them.
\nWell, I saw this guy’s demo. He actually had some investor money lined up, and I asked him one simple question. It is the question I ask everyone: Did you talk to a single person with disabilities before creating this demo?
\nThe answer to my question is all too often no. Unfortunately, this is an example of what ungrounded planning looks like. You have a clever solution, but you are not solving the right problem.
\nSo the first step in creating an accessible software development lifecycle is to make sure accessibility is in your planning documents. That could be a question about how your feature will serve people with disabilities in a PR/FAQ. But if you do not put us in the roadmap, you are going to end up building something really beautiful that is answering the wrong question.
\n![\"Slide](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide8.png\")
Jessie: My team in Microsoft AI is building voice-first features in Copilot, and we have data that shows 37% of voice-initiated tasks in Copilot are abandoned. That is not good.
\nWe also have data that shows that more than one billion people in the world live with some kind of disability, a limitation to one or more major life activities. And 76% of folks who have dyslexia or other neurological impairments say that they are better at work when they can use Copilot.
\nSo what the data shows us is that when Copilot voice breaks, it hits the people who need it most first and hardest. That is why we created a feature called Speak to Done, and that is how it got on our roadmap.
\nNow I am going to pass it to Aaron.
\n![\"Slide](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide9.png\")
Aaron Gustafson: Once the planning is done, most teams begin designing the user experience and the user interface. Now, whether they are using traditional design software or newer vibe-design approaches, it is imperative that designers have the right tools and information to help them make accessible choices.
\n![\"Slide](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide10.png\")
Aaron: One of the efforts that I have had the pleasure of working on in this space is the Accessibility Assistant plugin for Figma. It offers a suite of tools to help designers clarify the intent of their interface and assess the quality of their design when it comes to supporting people with disabilities.
\nHere on the screen I have a visual showing an annotated UI. Those annotations can actually act as an accessibility spec to guide engineering work. In fact, we are working on a new feature that will allow designers to export this accessibility information and hand that off to developers, whether they are human or whether they are agentic.
\nWe have seen some really positive results from our early tests of handing off that accessibility spec to agentic workflows, both in being able to fix existing bugs in the interface based on the accessibility spec and in being able to build interfaces from scratch. They are even able to take simple things like an example row in a grid and extrapolate the accessibility annotations for that one row out to all the rows within the grid, which is really exciting.
\nThe demo also shows one of the visualization tools that we have. We have a bunch of tools we are adding in for designers to help them understand how their designs end up being understood or experienced by people. In this case, we have done a focus order overlay to visually display how somebody would move through the interface.
\nBy having this information early, and as Jessie said, in a way that is very cheap to make changes, improving accessibility at the design stage can take mere moments, but it can have a huge impact. It costs a lot more to change that once it is already ensconced in code.
\n![\"Slide](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide11.png\")
Aaron: Even with a rigorous design system and robust accessibility specs, it’s still critical to embed accessibility into the coding process. As Jessie mentioned at the beginning of this talk, that becomes even more critical in the era of AI-assisted coding.
\n![\"Slide](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide12.png\")
Aaron: Out of the box, most coding agents are pretty terrible when it comes to accessibility. That’s not surprising though. As Jessie said, they’re trained on what we created, and the web we created has not been all that accessible, so they learned from us.
\nLeft to their own devices, most of the code they write only passes about 8–25% of automatable accessibility checks.
\nInstruction files are often touted for their ability to steer models toward better outcomes by teaching them what the accessibility expectations should be up front, but even with that the pass rate only climbs to 37–60% of automatable checks.
\nWhen you start imbuing agents with skills, you get closer to a pass rate of roughly 86%, but it is not until you give them actual deterministic tests to run, and instructions on how to use them, that you get them to iterate until the code passes all of those automatable checks.
\nBut even that only gets you so far because it takes you to the limit of what is testable purely in an automated fashion, via unit tests and integration tests. It does not cover things like usability, so I want to put it in context: automatable tests only cover about 50% of what you need for a UI to be considered truly accessible.
\nStill, every step in the right direction counts. And now that we have discussed accessibility in the code authoring context, I am going to hand it off to Carie to talk about embedding accessibility in the code review process.
\n![\"Slide](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide13.png\")
Carie Fisher: I am from GitHub, and we made an Accessibility Scanner. It’s open source. If you have not checked out the booth, we have a demo there.
\nWhat we are talking about here is bringing accessibility alongside the other feedback developers already expect. In pull requests, it should show up alongside code quality and security feedback. In CI/CD, accessibility checks should run where automation makes sense, whether you are using GitHub Actions, Azure Pipelines, browser tests, or deterministic tests. We want to be where you are and make sure accessibility is considered.
\nAfter release, issues and feedback should flow back into the backlog and into better patterns for next time. The PR is necessary, but it is not enough. If accessibility only appears at the end, we are still fixing after the fact.
\nThe bigger direction here is to embed accessibility into AI tooling and engineering practices so innovation scales inclusion, not exclusion.
\n![\"Slide](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide14.png\")
Carie: GitHub’s AI-powered Accessibility Scanner makes that workflow concrete with a simple loop: Find, File, Fix.
\nFirst, it helps find repeatable accessibility issues. Then it files actionable GitHub issues instead of leaving teams with a separate report that lives outside their workflow. And then those issues become useful context for fixing, including with Copilot-assisted remediation.
\nUnder the hood, we’re using Deque’s aXe ruleset, which is basically the gold standard for automated accessibility checks. It is free, it is open source, and we created the GitHub workflow around it so you can scan your page for accessibility errors, create issues, and then even assign those issues to Copilot to draft a pull request.
\nWe deliberately left a spot for a human to stay in the loop and make sure the result is truly accessible. As Aaron and Jessie have said, automated checks may only catch about half of the issues overall. You still need manual checks and you still need to work with people with disabilities to make sure your product is really inclusive.
\n![\"Screenshot](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide15.png\")
Carie: We don’t have time to run through the full demo on stage, but this is the workflow we wanted people to remember. Accessibility is not happening in a separate process. It is part of the same system teams already use to build, triage, review, automate, and ship.
\n![\"Slide](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide16.png\")
Carie: When accessibility is integrated, magic happens.
\n![\"Slide](\"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide17.png\")
Jessie: I am a blind PM at Microsoft and most days I spend them telling software what I want it to do and then spending an inordinate amount of time cleaning up what it did wrong.
\nMy team owns two really powerful features called Copilot Tasks and Copilot Cowork. They are super powerful. However, they did not have voice included in them, so we created a feature called Speak to Done, which is the voice layer over Copilot Tasks and Copilot Cowork.
\nI said, “Find that track meet email from three weeks ago, add it to my calendar, and text the other parent.”
\nCopilot did not lose context, did not break, found the track meet in the Gmail thread, put it on the calendar, and sent it to the other parent without breaking.
\nNow let me be clear: without the shift-left practices, without the tools that we talked about today, the Figma plugin at the design process, the deterministic testing, the code review, none of these features reach me.
\nSpeak to Done is really cool because it solves a problem that disproportionately impacts folks with disabilities, like we talked about earlier, but it also helps everybody who wants to use Copilot with their voice.
\nIn disability circles, we talk a lot about the curb-cut effect. Back in the 1960s, they did not have curb cuts. Wheelchair users in Berkeley literally started taking sledgehammers to the curbs and making them themselves. Now we see curb cuts everywhere, and who benefits? People who use strollers, delivery workers, all of society.
\nThat is a little bit of what we are trying to convey today. When we are talking about the things we build, we are not talking about tools. We are talking about who gets to use what we ship.
\nI encourage you to be conscious about creating a more accessible world, one code snippet at a time.
\nIf you want to dig into the tools we referenced, here is the resource page for the talk.
\n","social_text":"Last week at Microsoft Build, Jessie Lorenz, Carie Fisher, and I talked about how to build accessibility into AI-assisted software development from planning through code review and release.","url":"https://www.aaron-gustafson.com/notebook/can-your-ai-pass-the-accessibility-test/","tags":["accessibility","AI/ML","inclusive design","Microsoft","user experience"],"image":"https://www.aaron-gustafson.com/i/posts/2026-06-10/Slide2.png","date_published":"2026-06-10T18:32:00Z"},{"id":"https://www.aaron-gustafson.com/speaking-engagements/can-your-ai-pass-the-accessibility-test/","title":"📢 Can Your AI Pass the Accessibility Test?","summary":"At Microsoft Build 2026, Jessie Lorenz, Carie Fisher, and I explored how to embed accessibility across the software development lifecycle so AI scales inclusion rather than exclusion.
","content_html":"At Microsoft Build 2026, Jessie Lorenz, Carie Fisher, and I looked at what happens when AI accelerates software development without accessibility built into the workflow. We walked through the full software development lifecycle, from planning and design through coding, code review, CI/CD, and feedback loops, and showed how accessibility checks, tooling, and human review can help teams catch problems earlier.
\nAlong the way, we shared examples from Microsoft and GitHub, including the Accessibility Assistant for Figma, deterministic testing for AI-assisted coding workflows, and GitHub’s Accessibility Scanner. The through line was simple: if accessibility is part of the process, AI can help scale inclusion; if it is missing, AI can scale exclusion just as quickly.
\n","social_text":"At Microsoft Build 2026, Jessie Lorenz, Carie Fisher, and I explored how to embed accessibility across the software development lifecycle so AI scales inclusion rather than exclusion.","url":"https://www.aaron-gustafson.com/speaking-engagements/can-your-ai-pass-the-accessibility-test/","tags":["accessibility","AI/ML","inclusive design","Microsoft","user experience"],"image":"https://www.aaron-gustafson.com/undefined","date_published":"2026-06-02T00:09: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/accessibility-assistant-for-figma-v52/","title":"✍🏻 Accessibility Assistant for Figma v52","excerpt":"I just hit “publish” on Accessibility Assistant for Figma v52, and I wanted to share why this release matters so much to our team.
","summary":"I just hit “publish” on Accessibility Assistant for Figma v52, and I wanted to share why this release matters so much to our team.
","content_html":"I just hit “publish” on Accessibility Assistant for Figma v52, and I wanted to share why this release matters so much to our team.
\nWe’re in the middle of a major overhaul. To get there, we needed a lot of foundational infrastructure work to modernize the plugin and prepare for new features that help designers produce more accessible work, faster. This release includes a big chunk of that groundwork, notably:
\nWe also fixed duplication bugs. You can now copy layers and keep their annotations as a new Annotation Set. Similarly, duplicating pages now regenerates page-bound annotations automatically. On especially large pages, that regeneration may take a little time.
\nThis release has been a long time coming, and I’m incredibly proud of the team behind it, especially Ashish Singh from HCL, and Michael Fairchild, Scott O’Hara, and Ben Truelove from Microsoft. Their care, and their depth of accessibility knowledge, has been instrumental in getting this project to where it is today.
\nAnd there’s more to come!
\n","social_text":"I just hit “publish” on Accessibility Assistant for Figma v52 and I wanted to share some details on why this is a monumental release for us.","url":"https://www.aaron-gustafson.com/notebook/accessibility-assistant-for-figma-v52/","tags":["accessibility","design","inclusive design","Microsoft","user experience","WAI-ARIA"],"date_published":"2026-02-20T23:27:28Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/designing-for-distress-understanding-users-in-crisis/","title":"🔗 Designing for Distress: Understanding Users in Crisis","content_html":"\n\nIn a distressing moment, it’s like you’re rushing to the airport — you’re just looking for help right now. When you aren’t distressed, it’s like you’re on vacation. You can take your time, you’re more open to exploring.
\n
In a recent study, the VA learned a lot from users navigating acute distress — and why typical UX patterns fail. This is highly recommended reading for anyone working in the design space.
\n","social_text":"In a recent study, the VA learned a lot from users navigating acute distress — and why typical UX patterns fail.","url":"https://www.aaron-gustafson.com/notebook/links/designing-for-distress-understanding-users-in-crisis/","external_url":"https://medium.com/@codybolandphd/designing-for-distress-understanding-users-in-crisis-0e02466f1f5b","tags":["accessibility","user experience"],"date_published":"2025-10-10T18:52:07Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/disability-personas-from-a-web-for-everyone/","title":"🔗 Disability Personas from A Web for Everyone","summary":"The disability personas contained in Sarah Horton & Whitney Quesenbery’s A Web for Everyone are a terrific resource, so I’m thrilled their available beyond the book now too.
","content_html":"The disability personas contained in Sarah Horton & Whitney Quesenbery’s A Web for Everyone are a terrific resource, so I’m thrilled their available beyond the book now too.
\n","social_text":"I ❤️ these disability personas. What an amazing resource!","url":"https://www.aaron-gustafson.com/notebook/links/disability-personas-from-a-web-for-everyone/","external_url":"https://knowaboutaccessibility.org/category/resources/","tags":["accessibility","inclusive design","user experience"],"date_published":"2025-05-09T23:05:56Z"},{"id":"https://www.aaron-gustafson.com/speaking-engagements/expanding-accessibility-with-ai/","title":"📢 Expanding Accessibility with AI","summary":"This session, hosted by Aaron Gustafson and Ioana Tanase explores the transformative role of AI in enhancing accessibility. Together, you will uncover the pivotal role AI plays in crafting cutting-edge accessible technologies, learn about innovative AI tools that empower individuals with disabilities, and dive into best practices for creating inclusive AI solutions. Together, we will also explore the exciting future of AI in pushing the boundaries of accessibility.
","content_html":"This session, hosted by Aaron Gustafson and Ioana Tanase explores the transformative role of AI in enhancing accessibility. Together, you will uncover the pivotal role AI plays in crafting cutting-edge accessible technologies, learn about innovative AI tools that empower individuals with disabilities, and dive into best practices for creating inclusive AI solutions. Together, we will also explore the exciting future of AI in pushing the boundaries of accessibility.
\nLearning objectives:
\nIn this session, I discuss the many reasons companies should prioritize accessibility, how to build a culture of accessibility, and what it can mean for their bottom line.
","content_html":"In this session, I discuss the many reasons companies should prioritize accessibility, how to build a culture of accessibility, and what it can mean for their bottom line.
\n","social_text":"In this session, I discuss the many reasons companies should prioritize accessibility, how to build a culture of accessibility, and what it can mean for their bottom line.","url":"https://www.aaron-gustafson.com/speaking-engagements/embedding-accessibility/","tags":["accessibility","inclusion","inclusive design","progressive enhancement","user experience"],"image":"https://www.aaron-gustafson.com/undefined","date_published":"2024-01-19T08:08:00Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/the-ux-of-html/","title":"🔗 The UX of HTML","content_html":"\n\nSomehow my students are allergic to semantics and shit. And they’re not alone. If you look at 99% of all websites in the wild, everybody who worked on them seems to be allergic to semantics and shit. On most websites heading levels are just random numbers, loosely based on font-size. Form fields have no labels. Links and buttons are divs. It’s really pretty bad. So it’s not just my students, the whole industry doesn’t understand semantics and shit.
\n
I feel this… deeply. And I 100% agree with where Vasilis is coming from here. I do take a bit of umbrage with the idea that heading levels don’t matter—they really do—but his point about getting folks excited about the stuff they get for free by paying attention to their markup is something I’ve been pushing for years as well.
\nIf you’re interested in a related deep dive into HTML’s lack of dependencies, check out this piece I wrote for Smashing Magazine. If you’d like to dive deeper into forms, I have this talk you might like.
\n","social_text":"We should absolutely be (and continue) touting the #UX freebies we get with #HTML.","url":"https://www.aaron-gustafson.com/notebook/links/the-ux-of-html/","external_url":"https://www.htmhell.dev/adventcalendar/2023/1/","tags":["progressive enhancement","user experience","HTML"],"image":"https://www.htmhell.dev/images/og/advent23_1.png?s=011221s","date_published":"2024-01-05T22:52:50Z"},{"id":"https://www.aaron-gustafson.com/notebook/sharing-in-the-age-of-3p-cookie-mageddon/","title":"✍🏻 Sharing in the Age of 3p Cookie-mageddon","excerpt":"Over a decade ago, I wrote up detailed instructions on how to enable users to share your content on social media without allowing them to be tracked by every social media site via cookies. In a few short weeks “third party” cookies will get the boot in Chromium-based browsers. If you’re still relying on third party share widgets on your site, your users may start seeing problems. Now is a good time to replace them with code that Just Works™. Here’s how…
","summary":"Over a decade ago, I wrote up detailed instructions on how to enable users to share your content on social media without allowing them to be tracked by every social media site via cookies. In a few short weeks “third party” cookies will get the boot in Chromium-based browsers. If you’re still relying on third party share widgets on your site, your users may start seeing problems. Now is a good time to replace them with code that Just Works™. Here’s how…
","content_html":"Over a decade ago, I wrote up detailed instructions on how to enable users to share your content on social media without allowing them to be tracked by every social media site via cookies. In a few short weeks “third party” cookies will get the boot in Chromium-based browsers. If you’re still relying on third party share widgets on your site, your users may start seeing problems. Now is a good time to replace them with code that Just Works™. Here’s how…
\nWhen it comes to sharing, there are myriad ways to do it. If you’re at all familiar with my work, it should come as no surprise that I always start with a universally-useable and accessible baseline and then progressively enhance things from there. Thankfully, every social media site I commonly use (with the exception of the Fediverse) makes this pretty easy by providing a form that accepts inbound content via the query string.1 You can try LinkedIn’s to see it in action.
\nEach service is a little different, but all function similarly. I support the following ones in this site:
\n| Site | \nDestination | \nURL | \nOptional Params | \n
|---|---|---|---|
| Twitter / X | https://twitter.com/�4�intent/tweet�5��6��7�url�8��9��10��11��12�\n | ||
| Hacker News | https://news.ycombinator.com/�4�submitlink�5��6��7�u�8��9��10��11�t�12� = the title you want to share | ||
| https://www.facebook.com/�4�sharer.php�5��6��7�u�8��9��10��11��12�\n | |||
| https://www.linkedin.com/cws/share�4��5��6�url�7��8��9��10��11�\n | |||
https://pinterest.com/�4�pin/create/button/�5��6��7�url�8��9��10��11�media�12� = an image to sharedescription = the text you want to share |
Using this information, I created a partial template for use on any page in this site (though I mainly use it on blog posts right now). Each link includes useful text content (e.g., “Share on __”) and a local SVG of the service’s icon. Here’s a simplified overview of the markup I use:
\n<ul class=\"social-links social-links--share\">\n <li class=\"social-links__item\">\n <a href=\"{{ SHARE URL }}\" class=\"social-link\" rel=\"nofollow\">\n <svg>{{ SERVICE ICON }}</svg>\n <b class=\"social-link__text\">Share on {{ SERVICE NAME }}</b>\n </a>\n </li>\n</ul>You can check out the baseline experience on this very page by disabling JavaScript.
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2023-12-15/1.png\")
It’s worth noting that I have chosen not to enforce opening these links in a new tab. You can do that if you like, but on mobile devices I’d prefer the user just navigate to the share page directly. You may have a different preference, but if you decide to spawn a new tab, be sure your link text lets folks know that’s what will happen. I do include a rel="nofollow" on the link, however, to prevent search spiders from indexing the share forms.
If you test out these links, you’ll notice many of the target forms will pick up a ton of information from your page automatically. By and large, this info is grabbed from your page’s Open Graph data (stored in meta tags) or Linked Data (as JSON-LD). You can write that info to your page by hand or use a plugin to generate it for you automatically. There are a ton of options out there if you choose to go the later route (which I’d recommend).
If you played around with any of the various share forms, you probably noticed that they are, by and large, designed as discrete interactions best-suited to a narrow window (e.g., mobile) or popup. To provide that experience, I’ve long-relied on a little bit of JavaScript to launch them in a new, appropriately-sized window:
\nfunction popup(e) {\n var $link = e.target;\n while ($link.nodeName.toLowerCase() != \"a\") {\n $link = $link.parentNode;\n }\n e.preventDefault();\n var popup = window.open(\n $link.href,\n \"share\",\n \"height=500,width=600,status=no,toolbar=no,popup\",\n );\n try {\n popup.focus();\n e.preventDefault();\n } catch (e) {}\n}\n\nvar screen_width =\n \"visualViewport\" in window\n ? window.visualViewport.width\n : window.innerWidth,\n $links = document.querySelectorAll(\".social-links--share a\"),\n count = $links.length;\n\nif (screen_width > 600) {\n while (count--) {\n $links[count].addEventListener(\"click\", popup, false);\n $links[count].querySelector(\".social-link__text\").innerHTML +=\n \" (in a popup)\";\n }\n}The first chunk defines a new function called popup() that will act as the event listener. It takes the event (e) as an argument and then finds the associated link (bubbling up through the DOM as necessary in that while loop). Once it finds the link, the function opens a new popup window (using window.open()). Then, to check if the popup was blocked, it attempts (within the try…catch) to focus it. If the focus succeeds, which means the popup wasn’t blocked, the script prevents the link from navigating the user to the href (which is the default behavior, hence e.preventDefault()).
The second block defines a couple of variables we’ll need. First, it captures the current screen_width using either the window’s visualViewport (if available) or its innerWidth (which is more old school). Next it grabs the social links ($links) and counts them for looping purposes (count).
The final block is a conditional that checks to see if the screen_width is wider than 600px (an arbitrary width that just feels right… your mileage may vary). If the screen is wider than that threshold, it loops through the links,2 adds the click handler, and adds some text to the link label to let folks know it will open a popup.
\nAnd with that, the first layer of enhancement is complete: Users with JavaScript support who also happen to be using a wider browser window will get the popup share form if the popup is allowed. If the popup isn’t allowed, they’ll default to the baseline experience.
\nA few years back, browsers began participating in OS-level share activities. On one side, this allowed websites to share some data—URLs, text, files—to other apps on the device via navigator.share(). On the other side of the equation, Progressive Web Apps could advertise themselves—via the Manifest’s share_target member—as being able to receive content shared in this way.
Sharing a URL and text is really well supported. That said, it’s only been around a few years at this point and some browsers require an additional permission to use the API.3 For these reasons, it’s best to use the API as a progressive enhancement. Thankfully, it’s easy to test for support:
\nif (\"share\" in navigator) {\n // all good!\n}For my particular implementation, I’ve decided to swap out the individual links for a single button that, when clicked, will proffer the page’s details over to the OS’s share widget. Here’s the code I use to do that:
\nvar $links = document.querySelector(\".social-links--share\"),\n $parent = $links.parentNode,\n $button = document.createElement(\"button\"),\n title = document.querySelector(\"h1.p-name,title\").innerText,\n $description = document.querySelector(\n 'meta[name=\"og:description\"],meta[name=\"description\"]',\n ),\n text = $description ? $description.getAttribute(\"content\") : \"\",\n url = window.location.href;\n\n$button.innerHTML = \"Share <svg>…</svg>\";\n$button.addEventListener(\"click\", function (e) {\n navigator.share({ title, text, url });\n});\n\n$parent.insertBefore($button, $links);\n$links.remove();The first block sets up my variables:
\nul) of sharing links;h1 or title element);meta description element;The second block sets up the button by inserting the text “Share” and an SVG share icon and setting an event listener on it that will pass the collected info to navigator.share().
The third and final block swaps out the link list for the button.
\nThe final step to putting this all together involves setting up the conditional that determines which enhancement is offered. To keep everything a bit cleaner, I’m also moving each of the enhancements into its own function:
\n!(function (window, document, navigator) {\n function prepForPopup() {\n // popup code\n }\n function popup() {\n // popup event handler\n }\n function swapForShareAPI() {\n // share button code\n }\n\n if (\"share\" in navigator) {\n swapForShareAPI();\n } else {\n prepForPopup();\n }\n})(this, this.document, this.navigator);With this setup in place, I can provide the optimal experience in browsers that support the web share API and a pretty decent fallback experience to browsers that don’t. And if none of these enhancements can be applied, users can still share my content to the places I’ve identified… no cookies or third-party widgets required.
\nYou can see (and play with) an isolated demo of this interface over on Codepen.
\nInteresting side-note: If you own a form like this on your site, it makes a great share target. ↩︎
\nWhy a reverse while loop? Well, the order of execution doesn’t matter and decrementing while loops are faster in some instances. It’s a micro-optimization that boosts perf on older browsers and lower-end chipsets. ↩︎
Like many modern APIs, it also requires a secure connection (HTTPS). ↩︎
\nIt was a long time coming, but I finally had a chance to put the work I did on a widgets proposal for PWAs into practice on my own site. I’m pretty excited about it!
","summary":"It was a long time coming, but I finally had a chance to put the work I did on a widgets proposal for PWAs into practice on my own site. I’m pretty excited about it!
","content_html":"It was a long time coming, but I finally had a chance to put the work I did on a widgets proposal for PWAs into practice on my own site. I’m pretty excited about it!
\nI had the original idea for “projections” way back in 2019. Inspired by OS X’s Dashboard Widgets and Adobe AIR, I’d begun to wonder if it might be possible to project a component from a website into those kinds of surfaces. Rather than building a bespoke widget that connected to an API, I thought it made sense to leverage an installed PWA to manage those “projections.” I shared the idea at TPAC that year and got some interest from a broad range of folks, but didn’t have much time to work on the details until a few years later.
\nIn the intervening time, I kept working through the concept in my head. I mean in an ideal world, the widget would just be a responsive web page, right? But if that were the case, what happens when every widget loads the entirety of React to render their stock ticker? That seemed like a performance nightmare.
\nIn my gut, I felt like the right way to build things would be to have a standard library of widget templates and to enable devs to flow data into them via a Service Worker. Alex Russell suggested I model the APIs on how Notifications are handled (since they serve a similar function) and I was off to the races.
\nI drafted a substantial proposal for my vision of how PWA widgets should work. Key aspects included:
\niframe);After continuing to gently push on this idea with colleagues across Microsoft (and beyond), I discovered that the Windows 11 team was looking to open up the new Widget Dashboard to third-party applications. I saw this as an opportunity to turn my idea into a reality. After working my way into the conversation, I made a solid case for why PWAs needed to be a part of that story and… it worked! (It no doubt helped that companies including Meta, Twitter, and Hulu were all invested in PWA as a means of delivering apps for Windows.)
\nWhile the timeline for implementation didn’t allow us to tackle the entirety of my proposal, we did carve out the pieces that made for a compelling MVP. This allowed us to show what’s possible, see how folks use it, and plan for future investment in the space.
\nSadly, it meant tabling two features I really loved:
\nI’m sincerely hopeful these two features eventually make their way to us as I think they truly unlock the power of the widget platform. Perhaps, with enough uptake on the current implementation, we can revisit these in the not-too-distant future.
\nTo test things out, I decided to build two widgets for this site:
\nBoth are largely the same in terms of their setup: They display a list of linked titles from this site.
\nGiven that they were going to be largely identical, I made a single “feed” template for use in both widgets. The templating tech I used is called Adaptive Cards, which is what Windows 11 uses for rendering.
\nAdaptive Card templates are relatively straightforward JSON:
\n{\n \"type\": \"AdaptiveCard\",\n \"$schema\": \"http://adaptivecards.io/schemas/adaptive-card.json\",\n \"version\": \"1.6\",\n \"body\": [\n {\n \"$data\": \"${take(items,5)}\",\n \"type\": \"Container\",\n \"items\": [\n {\n \"type\": \"TextBlock\",\n \"text\": \"[${title}](${url})\",\n \"wrap\": true,\n \"weight\": \"Bolder\",\n \"spacing\": \"Padding\",\n \"height\": \"stretch\"\n }\n ],\n \"height\": \"stretch\"\n }\n ],\n \"backgroundImage\": {\n \"url\": \"https://www.aaron-gustafson.com/i/background-logo.png\",\n \"verticalAlignment\": \"Bottom\",\n \"horizontalAlignment\": \"Center\"\n }\n}What this structure does is:
\nitems from the data being fed into the template (more on that in a moment);item and\ntitle and url keys from the item object)The way Adaptive Cards work is that they flow JSON data into a template and render that. The variable names in the template map directly to the incoming data structure, so are totally up to you to define. As these particular widgets are feed-driven and this site already supports JSONFeed, I set up the widgets to flow the appropriate feed into each and used the keys that were already there. For reference, here’s a sample JSONFeed item:
{\n \"id\": \"…\",\n \"title\": \"…\",\n \"summary\": \"…\",\n \"content_html\": \"…\",\n \"url\": \"…\",\n \"tags\": [],\n \"date_published\": \"…\"\n}If you want to tinker with Adaptive Cards and make your own, you can do so with their Designer tool.
\nWith a basic template created, the next step was to set up the two widgets in my Manifest. As they both function largely the same, I’ll just focus on the definition for one of them.
\nFirst off, defining widgets in the Manifest is done via the widgets member, which is an array (much like icons and shortcuts). Each widget is represented as an object in that array. Here is the definition for the “latest posts” widget:
{\n \"name\": \"Latest Posts\",\n \"short_name\": \"Posts\",\n \"tag\": \"feed-posts\",\n \"description\": \"The latest posts from Aaron Gustafson’s blog\",\n \"template\": \"feed\",\n \"ms_ac_template\": \"/w/feed.ac.json\",\n \"data\": \"/feeds/latest-posts.json\",\n \"type\": \"application/json\",\n \"auth\": false,\n \"update\": 21600,\n \"icons\": [\n {\n \"src\": \"/i/icons/webicon-rss.png\",\n \"type\": \"image/png\",\n \"sizes\": \"120x120\"\n }\n ],\n \"screenshots\": [\n {\n \"src\": \"/i/screenshots/widget-posts.png\",\n \"sizes\": \"387x387\",\n \"label\": \"The latest posts widget\"\n }\n ]\n}Breaking this down:
\nname and short_name act much like these keys in the root of the Manifest as well as in shortcuts: The name value is used as the name for the widget unless there’s not enough room, in which case short_name is used.tag as analogous to class in HTML sense. It’s a way of labeling a widget so you can easily reference it later. Each widget instance will have a unique id created by the widget service, but that instance (or all instances, if the widget supports multiple instances) can be accessed via the tag. But more on that later.description key is used for marketing the widget within a host OS or digital storefront. It should accurately (and briefly) describe what the widget does.template key is not currently used in the Windows 11 implementation but refers to the expected standard library widget template provided by the system. As a template library is not currently available, the ms_ac_template value is used to provide a URL to get the custom Adaptive Card (hence “ac”) template. The “ms_” prefix is there because it’s expected that this would be a Microsoft-proprietary property. It follows the guidance for extending the Manifest.data and type keys define the path to the data that should be fed into the template for rendering by the widget host and the MIME of the data format it’s in. The Windows 11 implementation currently only accepts JSON data, but the design of widgets is set up to allow for this to eventually extend to other standardized formats like RSS, iCal, vCard, and such.update is an optional configuration member allowing you to set how often you’d like the widget to update, in seconds. Developers currently need to add the logic for implementing this into their Service Worker, but this setup allows the configuration to remain independent of the JavaScript code, making it easier to maintain.icons and screenshots allow us to define how the widget shows up in the widget host and how it is promoted for install.When someone installs my site as a PWA, the information about the available widgets gets ingested by the browser. The browser then determines, based on the provided values and its knowledge of the available widget service(s) on the device, which widgets should be offered. On Windows 11, this information is routed into the AppXManifest that governs how apps are represented in Windows. The Windows 11 widget service can then read in the details about the available widgets and offer them for users to install.
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2023-10-09/widgets-promotion.gif\")
As I mentioned earlier, all of the plumbing for widgets is done within a Service Worker and is modeled on the Notifications API. I’m not going to exhaustively detail how it all works, but I’ll give you enough detail to get you started.
\nFirst off, widgets are exposed via the self.widgets interface. Most importantly, this interface lets you access and update any instances of a widget connected to your PWA.
When a user chooses to install a widget, that emits a “widgetinstall” event in your Service Worker. You use that to kickoff the widget lifecycle by gathering the template and data needed to instantiate the widget:
\nself.addEventListener(\"widgetinstall\", (event) => {\n console.log(`Installing ${event.widget.tag}`);\n event.waitUntil(initializeWidget(event.widget));\n});The event argument comes in with details of the specific widget being instantiated (as event.widget). In the code above, you can see I’ve logged the widget’s tag value to the console. I pass the widget information over to my initializeWidget() function and it updates the widget with the latest data and, if necessary, sets up a Periodic Background Sync:
async function initializeWidget(widget) {\n await updateWidget(widget);\n await registerPeriodicSync(widget);\n return;\n}The code for my updateWidget() function is as follows:
async function updateWidget(widget) {\n const template = await (await fetch(widget.definition.msAcTemplate)).text();\n const data = await (await fetch(widget.definition.data)).text();\n\n try {\n await self.widgets.updateByTag(widget.definition.tag, { template, data });\n } catch (e) {\n console.log(`Couldn’t update the widget ${tag}`, e);\n }\n return;\n}This function does the following:
\nself.widgets.updateByTag() method to push the template and data to the widget service to update any widget instances connected to the widget’s tag.As I mentioned, I also have code in place to take advantage of Periodic Background Sync if/when it’s available and the browser allows my site to do it:
\nasync function registerPeriodicSync(widget) {\n let tag = widget.definition.tag;\n if (\"update\" in widget.definition) {\n registration.periodicSync.getTags().then((tags) => {\n // only one registration per tag\n if (!tags.includes(tag)) {\n periodicSync.register(tag, {\n minInterval: widget.definition.update,\n });\n }\n });\n }\n return;\n}This function also receives the widget details and:
\ndefinition (from the Manifest) includes an update member. If it has one, it…tag value and a minimum interval equal to the update requested.The update member, as you may recall, is the frequency (in seconds) you’d ideally like the widget to be updated. In reality, you’re at the mercy of the browser as to when (or even if) your sync will run, but that’s totally cool as there are other ways to update widgets as well.1
When a user uninstalls a widget, your Service Worker will receive a “widgetuninstall” event. Much like the “widgetinstall” event, the argument contains details about that widget which you can use to clean up after yourself:
\nself.addEventListener(\"widgetuninstall\", (event) => {\n console.log(`Uninstalling ${event.widget.tag}`);\n event.waitUntil(uninstallWidget(event.widget));\n});Your application may have different cleanup needs, but this is a great time to clean up any unneeded Periodic Sync registrations. Just be sure to check the length of the widget’s instances array (widget.instances) to make sure you’re dealing with the last instance of a given widget before you unregister the sync:
async function uninstallWidget(widget) {\n if (widget.instances.length === 1 && \"update\" in widget.definition) {\n await self.registration.periodicSync.unregister(widget.definition.tag);\n }\n return;\n}Widget platforms may periodically freeze your widget(s) to save resources. For example, they may do this when widgets are not visible. To keep your widgets up to date, they will periodically issue a “widgetresume” event. If you’ve modeled your approach on the one I’ve outlined above, you can route this event right through to your updateWidget() function:
self.addEventListener(\"widgetresume\", (event) => {\n console.log(`Resuming ${event.widget.tag}`);\n event.waitUntil(updateWidget(event.widget));\n});While I don’t want to get too into the weeds here, I do want to mention that widgets can have predefined user actions as well. These actions result in “widget click” events being sent back to the Service Worker so you can respond to them:
\nself.addEventListener(\"widgetclick\", (event) => {\n const widget = event.widget;\n const action = event.action;\n switch (action) {\n // Custom Actions\n case \"refresh\":\n event.waitUntil(updateWidget(widget));\n break;\n }\n});For a great example of how a widget can integrate actions, you should check out the demo PWAmp project. Their Service Worker widget code is worth a read.
\nWith all of these pieces in place, I was excited to see my site showing up in the Widget Dashboard in Windows 11.
\n![\"\"](\"https://www.aaron-gustafson.com/i/posts/2023-10-09/widgets-in-windows.jpg\")
You can view the full source code on GitHub:
\nI’m quite hopeful this will be the first of many places PWA-driven widgets will appear. If you’s like to see them supported elsewhere, be sure to tell your browser and OS vendor(s) of choice. The more they hear from their user base that this feature is needed, the more likely we are to see it get implemented in more places.
\nIn wiring this all up, I ran into a few current bugs I wanted to flag so you can avoid them:
\nicons member won’t accept SVG images. This should eventually be fixed, but it was keeping my widgets from appearing as installable.screenshots members can’t be incredibly large. I’m told you should provide square screenshots no larger than 500px ×500px.Have you checked out Server Events? ↩︎
\nInteresting examination of label positioning relative to checkboxes and radio controls in forms. While ostensibly web-focused, it applies equally to any GUI.
\n","social_text":"Interesting examination of label positioning relative to checkboxes and radio controls in forms. While ostensibly web-focused, it applies equally to any GUI.","url":"https://www.aaron-gustafson.com/notebook/links/assume-the-position-a-labelling-story/","external_url":"https://www.tpgi.com/assume-the-position-a-labelling-story/","tags":["accessibility","forms","design","user experience"],"image":"https://www.tpgi.com/wp-content/uploads/labelling-should-be.png","date_published":"2023-06-07T20:40:33Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/checkout-usability-autodetect-city-and-state-inputs-based-on-the-user-s-postal-code-28-of-mobile-sites-don-t-/","title":"🔗 Checkout Usability: Autodetect “City” and “State” Inputs Based on the User’s Postal Code (28% of Mobile Sites Don’t)","content_html":"Excellent overview of how to progressively enhance address entry forms using postal codes. It’s both a time saver and a data quality guard. Great stuff!
\n","social_text":"Excellent overview of how to progressively enhance address entry forms using postal codes. It’s both a time saver and a data quality guard. Great stuff!","url":"https://www.aaron-gustafson.com/notebook/links/checkout-usability-autodetect-city-and-state-inputs-based-on-the-user-s-postal-code-28-of-mobile-sites-don-t-/","external_url":"https://baymard.com/blog/zip-code-auto-detection?utm_medium=email&utm_campaign=Article%20Checkout%20Usability%20Autodetect%20City%20and%20State%20Inputs%20Based%20on%20the%20Users%20Postal%20Code%2028%20of%20Mobile%20Sites%20Dont&utm_content=Article%20Checkout%20Usability%20Autodetect%20City%20and%20State%20Inputs%20Based%20on%20the%20Users%20Postal%20Code%2028%20of%20Mobile%20Sites%20Dont+CID_06e39fd9939f69a009f7b4d63d1e0da8&utm_source=CampaignMonitor&utm_term=read%20the%20article","tags":["progressive enhancement","forms","user experience"],"image":"https://cdn.baymard.com/research/media_files/attachments/83684/original/research-media-file-37a02b5a04643939d772c093c9aeb1eb.jpg","date_published":"2023-04-12T23:01:09Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/how-ux-designers-can-engage-their-imagination/","title":"🔗 How UX designers can engage their imagination","content_html":"So much worthy of reflecting on on this piece!
\n\n\nI do not believe you can codesign your way to justice.
\nCertain institutions and design ideas are fundamentally oppressive, and the only way to achieve radical transformation at scale is with collective action and policy change.
\n
Imagination is key, but imagination in the right way:
\n\n\nImagination is not a splashy poster of a sci-fi movie but a daily act of resistance we must engage in despite how tired we might be.
\n
Following this framing, author Alba Villamil walls through a ton of actionable above and examples of how to bring imagination to hear on our UX work. Well worth your time!
\n","social_text":"Drop much goodness in this piece! “Imagination is not a splashy poster of a sci-fi movie but a daily act of resistance we must engage in despite how tired we might be.”","url":"https://www.aaron-gustafson.com/notebook/links/how-ux-designers-can-engage-their-imagination/","external_url":"https://www.fastcompany.com/90846822/ux-designers-suffering-from-failure-of-imagination","tags":["user experience","inclusive design"],"image":"https://images.fastcompany.net/image/upload/w_1280,f_auto,q_auto,fl_lossy/wp-cms/uploads/2023/02/p-1-90846822-ux-ethics.jpg","date_published":"2023-02-18T20:11:12Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/digital-exclusion-in-healthcare-how-to-change-it/","title":"🔗 Digital Exclusion in Healthcare & How to Change It","summary":"Fantastic talk from Sareh on assumptions we make about our users and how those assumptions exclude people who have different lived experiences than we do.
","content_html":"Fantastic talk from Sareh on assumptions we make about our users and how those assumptions exclude people who have different lived experiences than we do. Her focus is on digital healthcare, but is applicable to everything.
\nhttps://www.youtube.com/watch?v=Zi1NXGgsM3s
\nI love her calls to action as well!
\nRelated talk: Delivering Critical Information & Services
\n","social_text":"Amazing talk from @Sareh88 on assumptions we make about our users and how those assumptions exclude people who have different lived experiences than we do 🥰","url":"https://www.aaron-gustafson.com/notebook/links/digital-exclusion-in-healthcare-how-to-change-it/","external_url":"https://www.youtube.com/watch?v=Zi1NXGgsM3s","tags":["accessibility","empathy","inclusive design","industry","user experience"],"date_published":"2023-01-27T17:17:39Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/disruptive-design-patterns-an-uncharted-territory/","title":"🔗 Disruptive design patterns — an uncharted territory","content_html":"Excellent advice here:
\n\n\n","social_text":"Good examination of “disruptive” design patterns and how to consider the impact prior to taking them live.","url":"https://www.aaron-gustafson.com/notebook/links/disruptive-design-patterns-an-uncharted-territory/","external_url":"https://uxdesign.cc/disruptive-design-patterns-an-uncharted-territory-c1a857f2ff93","tags":["user experience"],"image":"https://miro.medium.com/max/1200/0*DqZGJjkCmJ9H9c8M","date_published":"2022-11-02T22:53:21Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/designing-better-error-messages-ux/","title":"🔗 Designing Better Error Messages UX","content_html":"[N]ext time you’re designing a new interface paradigm or chatting with an engineer, ask yourself about the risks involved in the known versus the unknown with the following questions.
\n\n
\n- Does the new design use intuitive patterns that prioritize consistency?
\n- Are you in any way disregarding accessibility practices in favor of a feature or a visual direction?
\n- How tech-savvy are your users and can the newly-introduced experience be easily adopted by current and future, more-diverse audiences?
\n- Can and will your design decisions be validated through properly conducted user research and user testing?
\nBeing mindful of these practices will help you guide decisions and ensure you don’t change things just because you can.
\n
As you’d expect, Vitaly’s deep dive into error message UX is a treasure trove of excellent, practical advice to make data entry better for your customers.
\n","social_text":"Tons of great info in this @smashingmag piece on the UX of error messages.","url":"https://www.aaron-gustafson.com/notebook/links/designing-better-error-messages-ux/","external_url":"https://www.smashingmagazine.com/2022/08/error-messages-ux-design/","tags":["forms","user experience","accessibility"],"image":"https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/93af7c7e-6484-4f47-9e79-fcf6aa24b3ce/better-error-messages-ux.jpg","date_published":"2022-08-30T16:56:41Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/why-everyone-is-watching-tv-with-closed-captioning-on-these-days/","title":"🔗 Why Everyone Is Watching TV with Closed Captioning On These Days","content_html":"Subtitles are yet another example of an accessibility feature that improves the experience of a much broader audience.
\nPersonally, I started using closed captions when we came home with Oscar. It also me to watch movie & shows while he slept in my arms. Interestingly, I’ve always tuned in dialogue subtitles in video games.
\n","social_text":"Subtitles are yet another example of an accessibility feature that improves the experience of a much broader audience.","url":"https://www.aaron-gustafson.com/notebook/links/why-everyone-is-watching-tv-with-closed-captioning-on-these-days/","external_url":"https://kottke.org/19/04/why-everyone-is-watching-tv-with-closed-captioning-on-these-days","tags":["accessibility","user experience"],"image":"https://kottke.org/plus/misc/images/ice-law-order.jpg","date_published":"2019-04-27T14:43:51Z"},{"id":"https://www.aaron-gustafson.com/notebook/links/policymakers-sound-alarm-on-dark-patterns-deceptive-web-design-tricks/","title":"🔗 Policymakers Sound Alarm On “Dark Patterns,” Deceptive Web Design Tricks","content_html":"The DETOUR Act, introduced by Sens. Mark Warner and Deb Fischer, targets bad actors on the web. I need to read through it fully to get a sense of what covered and/or missing, but that this is happening is, I think, a good thing.
\n","url":"https://www.aaron-gustafson.com/notebook/links/policymakers-sound-alarm-on-dark-patterns-deceptive-web-design-tricks/","external_url":"https://www.ndtv.com/world-news/policymakers-sound-alarm-on-dark-patterns-deceptive-web-design-trick-2020659","tags":["privacy","user experience"],"image":"https://c.ndtvimg.com/2019-04/4idbju0o_patterns650_625x300_10_April_19.jpg","date_published":"2019-04-10T15:18:25Z"}]}