As AI accelerates how software and content are created, accessibility risks emerge earlier and propagate faster than traditional testing and remediation can handle. This panel explores what “shifting left” means in the age of AI, from evaluating foundation models and code generation for accessibility, to embedding inclusive intent directly into design and development workflows. Panelists discuss how AI-assisted design tooling, automated scanning, and remediation in engineering pipelines can work together to prevent defects before they ship. Drawing on internal and external perspectives, the session presents a closed-loop view of accessibility that spans creation, evaluation, and remediation at AI speed.

Joining me were four people doing important work from very different angles:

• Dylan Barrell of Deque Systems, who is focused on making accessibility sustainable and practical within modern engineering workflows.
• Yumeng Ma, a PhD student at the University of Washington whose research examines AI, accessibility, and how code generation systems perform on real accessibility tasks.
• Ed Summers, Head of Accessibility at GitHub, who has been helping shape how accessibility can show up in tools, pull requests, and developer culture.
• Navin Thadani, co-founder and CEO of Evinced, whose team works on deterministic accessibility testing and remediation at scale.

Our conversation centered on what “shifting left” means in the age of AI: improving model inputs, tightening prompts and instructions, adding deterministic checks, and building accessibility directly into the harnesses and processes that increasingly guide software creation.

Unfortunately, the panel wasn’t recorded, but my good friend Kelly Goto recorded the audio, so I was able to put together the following transcript. It’s a bit rough — some of the audio was garbled — but I think it captures the spirit of the conversation and the key points that were made. I hope you find it useful!

# Full Transcript

Aaron Gustafson: Welcome to our session, “Fixing Accessibility After the Fact Is Already Too Late.” Before we jump into the content, I’m going to ask everyone to introduce themselves. But because I’m cheeky, we’re going to introduce ourselves using name, role, and value. So I’ll take moderator privilege to go first. My name is Aaron Gustafson. I am a Principal TPM on the Accessibility Innovation Team here at Microsoft, and one of my values is our differences. I think we all have unique perspectives and experiences, and when we feel safe to bring our whole selves to work and to our social interactions, you really create better products and a better culture. I’m going to pass it over to Yumeng.

Yumeng Ma: Yeah, hi, my name is Yumeng Ma. I’m a computer science PhD student at the University of Washington and my research is on human-computer interaction, but my interest lies in the intersection of AI and accessibility. A lot of my current work actually looks at how AI generates code and whether that code is even accessible to begin with. Something I value is making impact on people’s lives. For example, when people say AI is helping with accessibility, what drives my motivation and curiosity is really understanding how it’s helping and what ways we can improve it.

Dylan Barrell: Hi, my name is Dylan Barrell. My role is cat herder at Deque Systems. I have been focusing on making accessibility sustainable. I think that’s the important thing. And in doing that, one thing that I value is how to use technology to do that. So, very excited to talk today about how we can use AI in particular and what the pitfalls and the advantages of that are, and how we can do that in a practical way. Because for us, in order for accessibility to be sustainable, it also needs to be practical.

Navin Thadani: So my name is Navin Thadani. My role is the co-founder and CEO at Evinced. We’re a digital accessibility technology company. And my value, I like to think it’s a lot, but my team doesn’t let me commit code anymore.

Ed Summers: I have the same problem. My name is Ed Summers. I’m head of accessibility at GitHub. And the thing that I value most is this lovely accessibility community that we have. I mean, it’s great to be with you all here. More IRL community.

Aaron: Awesome. All right, so to kick us off… AI didn’t just change how we build software, it changed how defects are born and how quickly they propagate. We’re shipping code faster than ever, which is super risky, and numerous studies have shown that code generation models are not that great when it comes to generating accessible code from the jump. On top of that, the latest WebAIM Million Survey shows an uptick in accessibility violations on top home pages across the web. I’m going to direct our first question to the folks on the panel who are working to address accessibility issues at scale: What are you seeing out there? Is the uptick in the WebAIM Million an early indicator of the tsunami of accessibility issues that AI will be generating? Ed, why don’t you kick us off on that?

Ed: Okay, let’s go. I don’t want to be an AI apologist or anything, but I think that the WebAIM, this year’s survey did see the increase from 51 errors or barriers found per page on average to 56. That’s kind of what we’ve been referring to here. I don’t think that is an indicator of a tsunami.

I think that a couple of things are going on. The AI models, the foundational models are trained on years and years and years of human output. So they mirror back what we do as humans. So the AI bias is human bias. And I think that’s right, and we need to work diligently to remove that bias.

But for the purposes of this discussion, can we expect a tsunami of accessibility errors due to the increases of AI? I don’t think so. I think it’s a multiply by one in the sense that we’re just going to get more of what we’ve been getting in the past as we use AI more and more. And I think if you look at the trend of the WebAIM data, for example, for the last eight years, those numbers of barriers per page, they’ve been between the range of 60 and 50. And 56 this year, 51 last year, the year before that, it was 56. So I think there’s just some noise in that data and it’s kind of roughly in line. I think what’s exciting to me is the opportunity that we have, the lever that we have with AI in order to remove bias at scale, which is obviously what we’re here to talk about.

Aaron: Dylan, you had some thoughts you wanted to add on.

Dylan: Yeah, I think there is, there’s been some studies that we put out. The problem with any study about AI is that AI moves so fast that by the time the study comes out, it’s sort of obsolete. It’s kind of one of those things that go on. So with that being said, one of the studies that has come out recently, for example, we’re slightly biased, of course, I understand that, but is that just defects in general are going up as we ship more code. And I think this is one of the big problems that organizations are facing today is we can generate code.

So the constraint that we used to have in our organization was often not how quickly we could create the code. And we’ve shifted that constraint from how quickly we can create code to how quickly we can determine whether the code that we’ve created is the right quality in all the different ways in order to be able to ship it. And so quality as a whole, as a problem, has become this sort of bottleneck.

People who are doing code reviews, for example, are now the bottleneck that we have to deal with. And so organizations are straining and a lot of them are putting out code and whether the bugs that they have are accessibility related, whether it’s just quality related, dealing with that problem of that new constraint is one of the biggest things that organizations have to deal with. And accessibility is a big part of that as well.

Aaron: What Dylan was talking about in terms of the speed these models are changing… Yumeng, I wonder if you could talk about your research and how trying to figure out what models to map your research against was super challenging because of the models constantly changing under you.

Yumeng: I think one thing we struggled the most when coming up with my research study was to select what models to evaluate. In research, a lot of what we capture is a snapshot in time, whereas models are constantly changing. Let’s say we benchmark some models now, after a few months, new models will come out. And so that’s really challenging, right?

So one way to combat this is that I have designed a testbed called PACE, which stands for Prompt Accessibility Controlled Evaluation. And essentially it’s like a playground where users have the freedom to configure how many models they select, what models they select, and alongside with what prompt they choose. And so kind of bringing that system or that testbed in, we can reuse that system to evaluate models now and even in the future.

Aaron: Navin, anything you’d like to add from what you’re seeing?

Navin: Yeah. So before I get to that, real quick, I did want to point out one thing. We all look at this WebAIM study every year, and we sort of kind of beat ourselves up about it a little bit. Because it doesn’t show much progress and all that. And while it’s an OK barometer at a macro level, I think that when you start kind of dissecting things, things aren’t as bad as it seems. I just want to point that out.

Our view is a lot more optimistic about where things are at, because you focus on the Fortune 500 companies, for instance, as opposed to a small online retailer in Kuwait, which is part of the WebAIM Survey. I’m not saying that’s not important, but when you look at, think of it as frequency weighting, you know, what people actually use, we find that the number of defects on a per page level are much lower, and it’s actually a good thing, and when you look at critical defects, even lower than that.

When you look at web applications as opposed to websites, people aren’t doing a good job. They’re trying. I mean, it’s far from perfect, but it’s nowhere near the doom and gloom that we all kind of think about when we look at the web. That’s the first point.

Second point is, I’m with Ed on this. The models, so far at least, are trained on the code that humans have written. And it’s mostly open source code that they’re trained on, which we all know open source is great and known for a lot of things. Accessibility unfortunately is not among them. So they do produce a lot of issues for the most part. But on a unit basis, we can expect AI to generate the same thing.

The problem is that there’s more code being written. Because it’s easy to write code now. So the total number of defects that you’re going to find could actually increase. But on a unit level, it’s probably going to be around the same. But from a, again, total perspective, it is going to increase. So that’s one inflection point that if we don’t do anything, that’s the risk.

But on the other hand, quite frankly, I think it’s easier to harness AI to actually generate accessible code much more than it is to train a developer. You look at what we’ve been doing as an industry for a long time. We’re training 100 developers; tomorrow, 33 of them are gone.

Literally, people change their job once every three years on average. And forget about the fact that it’s hard to remember what you studied. I don’t remember anything of what I studied in undergrad. Let me tell you that, for instance. So it’s very difficult to remember what you studied. And on top of that, you’re losing 33% of your employees every year.

When you look at it from an opportunity perspective, I believe we have the right opportunity and the right tools and the right motivation right now to actually reverse that trend and drive it down as close to zero as possible. So I’m very optimistic about what we can do with AI.

Ed: Can I jump in?

Aaron: Of course.

Ed: Thank you.

Those are great points, and I think that the turnover is such a great point. It’s a challenge for us.

We talk about AI in isolation because it’s the latest tool. I think, you know, we can’t lose sight of the fact that the developer culture, you know, the culture of the relatively small number of people that build the things that the rest of the digital things that the rest of the community uses is so incredibly important. And last year, GitHub took a challenge. We took a pledge to help improve the accessibility of open source.

Part of it is what you just said about the training. And most people don’t know this, but 70 to 90% of the source code in your typical website or your typical application is open source code. If you take all the source code and put it in one big file, 70 to 90% of that source code is open source. So we have a lot of work to do there. And in improving the accessibility of open source, I think, building a culture of accessibility across the global developer community can put us in a position where accessibility becomes a portable skill that you take from one job with you to the next, as opposed to showing up for the job and like, oh, they want us to do accessibility. Okay, I’ll do it here, but I’ll do it after that. I think that’s one of our challenges here.

Navin: You can always have this point using technology like MCP and all that to start going out and automatically remediating some of these issues that are out there that are common and what people use, it’s another great opportunity and definitely something that should be done. But I was reading the other day how in the Linux kernel now, there’s so many automated patches that are coming in that we just can’t keep up with that anymore. So we don’t want that same problem when we try to remediate some of the open source code. But I do think if it’s not right, that is one way to do it, we should do it.

Ed: One more thing. Open source developers are amazing, and this is in no way, shape, or form. Most of us, some get paid, not that many. I don’t want to criticize them. We want you to go support open source.

Aaron: But also, to Navin’s point, don’t overwhelm them with giant commits, like 10,000 file changes. Those teams cannot parse that, right? It’s not possible to go through that. So if you want to commit to open source, which I highly recommend, make sure that your commits are discrete and fixing a very specific thing and you don’t just dump a bunch of work in their lap because that’s going to be totally overwhelming.

One more thing I want to pick up on, going back to the survey, and I think that Ed and Navin both make really good points about this. We don’t talk an awful lot, or at least we don’t index really heavily on the fact that it’s home pages. And home pages, if anybody has ever worked on a home page, they are very political. They are very marketing-driven. They are not necessarily where the best choices are made. I’m just gonna throw that out there. And they’re not where people go to do tasks, right?

And so they’re not the key things that people are going to to interact with your website. They are a front door. And yes, we want that front door to be accessible. But at the same time, to your point, they’re not representative necessarily of the quality of the code that’s in the rest of the site.

All right, let’s pivot a bit…

So as everyone up here is focused on shifting left, I want to shift as far left as we can go when it comes to AI models and talk about the work we need to do in that space to improve the quality of the code that’s recommended to us. A little bit of touching on that. I think the point about this was trained on code that we all collectively wrote, which was not always code that we are proud of. I think that’s really important.

I have a friend that coined the term the “full StackOverflow developer” and I think of AI as the “full StackOverflow developer at scale” because there’s lots of stuff out there on StackOverflow that is not the best advice. And there is a real risk, to Navin’s point, as there is more AI-generated code out there, that this gets fed into the models, just like when we talk about slop content. We have slop code out there, and it becomes like the snake eating its own tail, the ouroboros, right?

So I think this is something that we need to be thinking a bunch about.

For years, we’ve been working to improve the tools and procedures that we have when it comes to identifying and remediating accessibility bugs. But that work often comes late in the software development lifecycle. When it was humans designing the UI and authoring the code, we talked about the importance of education when it comes to accessibility. And now we’re in an era where these models have nearly immediate access to far more information than humans can retain. And yet it seems that we’re struggling to get them to properly index on the right things when it comes to accessibility.

So my question is, are the issues that we’re facing in terms of code quality fundamentally about a lack of proper training data, or is it more a question of how we direct codegen models to access the data they already have? Yumeng, why don’t you kick us off on this topic? What have you seen in your research?

Yumeng: Yeah, I think one thing that I’ve seen in my research is that code quality isn’t just attributed to the training data and not just a prompting problem either.

For example, if we train, if we even have this ideal training data that we give to the model, the model itself is still essentially a black box. How the model, the way it interprets or thinks about the training data is also a problem. And in my research, we also looked at generating AI code with different models and with different prompting conditions. But the prompting, there wasn’t a universal prompt that made all the models reliably more accessible. There wasn’t a path where the models would output accessible code. And so it may even come down to maybe thinking of ways to even guide the AI models in a way that is interpretable for machines to learn.

Another thing that we’ve seen is that it might also be a measurement problem because a lot of the automated tools that we’re seeing. Some of the code that is generated by AI actually passes automated tools. But if you look at the semantic structure, because in my research, I’m focusing on a lot of HTML code, the semantic structure is not exactly accessible to people with disabilities.

Aaron: Maybe technically valid, but not actually.

Yumeng: Right.

Aaron: Do you have something you want to add Dylan?

Dylan: Well, yeah. I think people are talking about trust. Can we trust what the models are outputting? And I don’t think that’s even a relevant question, because we don’t trust the code that our human collaborators create either.

So for me, it’s not about trust at all. It’s about how do we take the output that’s being generated and how do we test it to make sure that it, in fact, has the quality that we want, or which one of them is accessible, right? And this comes back to the question I talked about with scaling this, because this becomes a scaling problem.

But aside from the scaling problem, there are certain approaches that we can take. And some approaches are better than others.

If we, for example, take agents and we use them to test the output of other agents, and we give them very specific prompts on what to do, they can do a decent job of improving the quality of that code overall. But one of the things that we found, and I think this is interesting because Ed, I think Ed’s gonna probably talk about this later, a study that Eric Bailey of GitHub did surfaced this as well and there’s a couple of problems that he had with that.

First of all, models in and of themselves have been trained to want to output something, right? And, in fact, the head of Anthropic product development said this. They’ve explicitly trained Claude to be a willing partner that can do and that’s action oriented, right? And so everything they’ve put into the way that they created system prompts and the way they’ve trained it makes it a great tool for us interacting with it when we’re coding. But that same attribute also makes it really bad at doing a comprehensive job of auditing anything, actually.

And you see this explicitly in code reviews. If you ask Copilot to do a code review for you, and then you ask it to do a code review again, on the same code, without having changed anything in between, you’re going to get two different perhaps overlapping sets of results back. So what you need to understand is the strengths and weaknesses of the models, what they’re good at and what they’re not good at, right?

One of the things that you find, if you try to use the agents to just audit each other, is total costs start skyrocketing. And total costs is going to become more and more of a problem. Early on, Anthropic and the other companies had been subsidizing the token costs a lot. And we’ve been using them a lot. But now you’re starting to see the pricing models change. So token cost becomes a big thing. And I think in Eric’s study that he did, that was one of the first things they ran into.

So I think what you’ve got to do is you’ve got to take a combination of more deterministic things that don’t eat up your token costs and you’ve got to combine those with the strengths of the models to really get to where you need to get to.

Looking at the speed, speed is another thing. The agents take a long time. So speed, token cost, and determinism are sort of important attributes. And that’s, I think, where some of the approaches that we’re taking at Deque can really tie together with this. Where we enhance the agents in a deterministic way with things that do comprehensive audits that bring the same results back over and over and over again. And you tie those together with the capabilities of the model is where you achieve the best results. I think that that’s sort of the approach that you have to take toward accessibility in these AI workflows.

Because for me, as Navin pointed out, that is the opportunity here. The opportunity is to teach your agentic workflows how to do accessibility. And if you can do that and do a good job of that, then we can really leverage the power of AI to not only move us forward in all the innovative areas, but to do that in a way that’s also accessible at the same time. So that, for me, is the way we should be thinking about this, using the AI where the AI is powerful and using other approaches where that’s more appropriate.

Aaron: I’m going to skip over to Navin real quick and go to Ed, since Eric’s piece was mentioned a couple times. I don’t know, Ed, do you want to talk to Eric’s piece that just came out?

Ed: Yeah, I’ll give you the TL;DR. So Eric Bailey is a designer at GitHub on our accessibility team, our accessibility design team. And just simply an amazing accessibility professional. He’s worked for the last few months, two or three months, building our internal accessibility agent inside of GitHub. He just published a blog post Thursday, this past Thursday, maybe it was Friday, on github.com/blog. If you look for it, just look for the accessibility tag.

Aaron: It’s in the resources as well.

Ed: Okay, great. It’s a treasure. I reread it again this morning and I was like, oh yeah, there’s so many things that we can learn that he was able to back into, I don’t know, like a thousand words. I want to highlight a couple of those as well.

One thing is the work that Eric did building our agent leveraged years of meticulous human effort of manually testing, manually auditing, and tracking and curating our own data set, our accessibility violations that we found within the company. I mean, literally thousands of them, most of them have been fixed, but they’re all cataloged and tagged with WCAG criteria and steps to reproduce, just really well curated data. Much of that, by the way, thanks to Dennis Lembree, who runs our governance program.

And from this knowledge, this corpus of data, oh, by the way, important thing, in addition to excellent issue descriptions, there’s a link to the PR that resolved those issues. Okay, so we have this diff. And it’s not just random, it’s our tools, our design system, the way that we work at GitHub, which is critically important to get that context, I think. And from this corpus of knowledge of data, Eric built this agent. And it’s starting to deliver really nice results. We’ve got it kind of pinned down on the lab bench, and we’re running a pilot study right now internally.

One of the ways we’re using it is on reviews of pull requests that come in for github.com. And we’re getting really great results from that. Part of the reason they’re getting great results, I think it was about 60% resolution rate for those pull requests.

There was one more point I wanted to make about that was… oh yes, the bias towards action that Dylan mentioned. AI models, they’re going to go try and do something for you. Regardless of what you tell them, they’re going to do something. It may be what you want. It may be what you don’t want. But what Eric was able to do is he put a lot of limiting factors on this agent. So we put it in a box and tell it “Okay, these are the things you’re good at. Don’t try anything outside of that box and just don’t generate noise.”

Some of the things that are outside of that box are really complex interactions, like, for example, drag and drop, or data grids or tree grids. These are the things that are really hard to get right. And we just walled off the agent and said, “No, the humans are going to take care of that for now.” And that allows us to build confidence and trust in the PRs, the feedback that the agent’s given on PRs. I encourage you to check out the blog post if you get a chance.

Aaron: Yeah, I love the idea of feeding our own bug data. I think that’s such an unused treasure trove of information. And, similar to the GitHub team’s experience, in my own tests, taking and remediating bad code coming from AI coding agents, remediating that manually and then feeding those diffs back to the agents resolved the issues 100% of the time going forward. So having that as part of the training corpus really improved things.

Navin, I’d love your thoughts on this.

Navin: I’m going to echo a little bit of what Dylan said as well, because I think, and I’ll add a couple points to that, at the end of the day, the problem is quite straightforward. AI models are non-deterministic. They’re going to generate code, different kinds of code, every time you ask them. The only way to actually make it useful and ensure that things like accessibility are done is via deterministic testing. That is it. And right now, of course, it’s evident to see that if you ask AI to generate a web page, we found so many times there are so many studies out there. 47 errors, and even if you prompt it, then it becomes 46 errors, whatever.

But let’s say we’re optimistic, and eventually we get however long it takes for improvements. But even if AI is generating accessible code for the most part, you always want to validate it. You have to. So now the question is, what kind of deterministic testing do you have? How much are you covering? How accurate is it? And the kind of things that you were talking about earlier in terms of semantic structure and not being tested by. But I can tell you that those kinds of things are possible. And we’re doing those today. So the more you cover, the more you can fix automatically and ensure that what comes out is an even higher level of accessibility. So this stuff really matters.

Aaron: Absolutely!

A couple of folks had mentioned the pull request, the humble pull request. It’s often the last line of defense when it comes to preventing accessibility bugs from reaching customers. Catching it directly, remediating bugs, or at least proposing remediations with a human-in-the-loop scenario is something AI agents have proven to be really good at.

How should we be thinking about these automated systems as part of the software development lifecycle loop? Is the PR the right place for these gates and checks to live. Dylan, do you want to start us off?

Dylan: Well, I think the PR is too late.

As I’ve always said, we need to shift it as far left as possible. And we need to shift it all the way into design. And then during code generation, we need to be testing the code as we’re generating it before we even submit the pull request. So I think at every step along the way, you have to inject tests into that.

So, for me, the pull request is a necessary thing. We have to have the tests in the pull request because they catch things that slip through in our process, things that slip through in our technology, in our approach, and in our testing. So we need it, but it’s not enough. So for me, it’s about what are those type moves?

Everybody talks about agentic development. What most people are doing today is sitting in front of the coder and they’re asking it to do stuff and then they’re testing that, right? But where it’s moving towards is sort of fully agentic development where you have humans at particular points. In fact, that’s the only way we’re really going to scale is by elevating humans to the points where they can make the really high quality decisions. And then the coding agents do the rest.

So for me, as we see this evolution from where we are to where we’re moving towards, the question becomes “How do you test at every stage in the loops where, as Matt Pocock likes to call it, the AFK loop, right, where the human is away from keyboard and the agents are working. For me, it’s about how do we insert accessibility thinking, accessibility coding, and accessibility testing at every stage along the way, including where the human is away from the keyboard? As well as presenting that information to the human so that they can make a determination. Has this agent, has this agent’s coding loop, have they done the accessibility testing in the way that they should have done that? And we need to be looking at the results.

So for me, that’s kind of where things are moving to and those sort of approaches that we should be thinking about.

Aaron: Yeah, I love that.

I’m curious, just kind of for the audience: from y’all’s perspective, there are so many tools that we have now for when we’re working with agents in the coding context. We have instruction files, we have agent files, we have sub-agents, we have orchestrators, we have skills. We have deterministic tools that we can have the agents run, like axe-core or Evinced’s unit testing tools, those sorts of things. How should people be thinking about all of these tools and how they work together and how to get the most bang for the buck? And I didn’t even mention MCP.

All of these different things… Navin… do you want to kick us off on that one?

Navin: Yeah, I can describe what we see as a basic scenario and then I’ll talk about a little bit more advanced one.

At the basic level, you know, you imagine you’re a developer sitting in front of or whatever, and you just build your feature, some form on some page, drop downs, whatever. Where you can just go ahead and say, “All right, but remediate that,” or “fix that,” or whatever. And it’ll basically run a deterministic test. It’ll then come back with a set of issues. And then you can give the machine, the agent, in this case, agent-specific fix instructions. You manage the context in a certain way. And all of that can now be fixed automatically. So, as Dylan was saying, when you do your pull request, it’s already cleaned, at least for the most part, right?

That’s one way to do it, but there is a problem in that: the developer still has to do something. They have to go out and actively say, I want to fix any accessibility issues in this piece of code that I just developed before I push it further down the line. Sometimes it’s hard to do even that, to be honest. That’s just where we are.

There are many ways that you can get around that and have it have this sort of deterministic testing, these guardrails or the new word these days is “harness”. Harness engineering or whatever. But you get in many ways. There’s the skill files you mentioned, there’s configurations at the repo level, there’s all kinds of things you can do. You can integrate it into automated tests that happen as well.

So you write an automated test, the agent writes an automated test, inserts accessibility in there. If there’s an issue, a GitHub Action gets triggered, code gets fixed, and there you go.

It can happen automatically as well. So I think it really depends on your development model. It depends on the architecture that you have internally. But all the necessary ingredients are there already to be able to significantly improve the quality of code from an accessibility perspective, which is out of the box right now.

Dylan: I think two words you said triggered me because I think about these a lot. And these are things that I think everybody who’s in the accessibility industry should be paying attention to. There’s two words: “harness engineering” and “context engineering,” right? And if you hear these words inside your organization, this is your opportunity because, I think Navin hinted at it if he didn’t say it, but one of the things that’s a huge opportunity from an AI coding perspective, from an accessibility perspective is AI agents do what you tell them to do. They don’t complain about it. They don’t say, no, that’s too much work, or I don’t know how to do that, whatever. They just do it. And the better the context you give them and the better the tools that you give them in order to be able to do that, the better the job that they’re going to do.

So what harness and context engineering is about is about how we engineer these tools that are becoming more and more automated. What sort of process we build, where the human gets pulled into it and when they don’t, what gets created as the artifact that comes out of that, that then has to be reviewed.

And the context is important because context is at least three things:

• It’s the context of the repo that you’re working on. What are the rules of that repo? What sort of tools are available in that repo? How do you do testing in that repo, et cetera?
• And then there’s a context more generically about how do we do accessibility testing in this company. That’s sort of repo agnostic.
• And you have to tie these things together in order to achieve the outcome.

So harness engineering is not only about creating that, but it’s also about looking at the data as stuff is moving through that and analyzing what is working well. This is a much bigger topic than just accessibility, but accessibility is one of those things.

So one of the things you can do if you’re setting up your harness correctly is you can create these history files where you can look at the interactions between the different agents and what caused that churn. And churn is bad from a lot of perspectives. It costs money, it costs time. And you can then say, why are they churning? And then you can modify your context and your tools and your harness to eliminate that source of churn.

When you hear people talking about this is an opportunity for you as an accessibility practitioner to say “How do I get involved in those activities within my team or within my organization? So I can accessibility-enable those AI processes.” Because if organizations right now are redesigning the way they do software development, that’s a huge opportunity for us to get accessibility baked in.

So if you hear those keywords, jump on it and find out how you can get involved in making those harnesses and those context engineering accessibility-enabled. If there’s one takeaway that I’d like you to take away from what I’m saying up here today, it’s look for that and do that, because that’s the opportunity.

Aaron: I want to pick out one thing that each of you touched on.

In terms of reading your model’s logs, I think that there’s huge value in doing that to look for those kinds of inefficiencies. With one caveat: There’s been some research that actually the models are lying about their chain of thought in some cases.

The second thing is, Navin mentioned, having AI help you by writing tests. I think that can be super useful, but at the same time, a lot of these models, they want to please. So they want to create a test that is going to be green.

So it would not surprise me, because I’ve seen it, I see agents mock all sorts of different API endpoints, I would not be surprised if one had mocked axe-core to have always return green.

I think those are some of the things that we need to also be aware of when we’re working with these models and just being sort of realistic about what their strengths and weaknesses are.

[To Yumeng] I’m wondering, from your research, because you were looking a lot at the ways that we were prompting models and a lot of that can then feed into the way that we’re writing agent files or skills, how we’re addressing the model. I wonder if you could share some of your insights from your research.

Yumeng: Yeah. So what we looked at is different levels. In my research, we looked at different levels of accessibility guidance. So the lowest guidance would be no guidance. And then the second level would be just saying the keyword “accessible” in the prompt. And then the third would just be taking some factors from WCAG and turning it into the guidance and seeing how the AI responded. But I think it dives deeper than just prompting, because what we found is that there’s not a magical prompt that made the AI code output more accessible.

I think it’s not as simple as just saying, oh, just tell the AI agent to write accessible code. I think that puts a lot of pressure on the user and a lot of trust on the AI model. And so I think there’s a lot of factors beyond just prompting and just guiding the model.

So again, it feels like a big black box where we’re not certain what the factor is. It could be the evaluation, it could be the model prompting, could be even that prompting can be configured with this overall system instruction versus the specific request or task you’re asking it to do or what you’re asking it to output. Because what we’re seeing in my research, we’re looking at specifically HTML form components, is variability. Easier form components like, for example, a submit button might be just more accessible by default. As opposed to, let’s say, something more complicated like a toggle switch or something with validation or helper text, et cetera.

Aaron: All right.

Ed, I wanted to come over to you, and I actually wanted to ask you a little bit to talk about the GitHub Accessibility Scanner and some of the work that you’re doing in the PR space. You made an interesting point as well in one of our early discussions about this, about the opportunity for just-in-time training for engineers who are reviewing PRs from your accessibility agent.

Ed Summers: Yeah, sure. So recently, in the last few months, we released our accessibility scanner.

There’s a couple key things about that. One, it’s based on our deterministic scanning. And then we just recently added the plugin architecture, which has opened up lots of new possibilities for interactive testing.

The first built-in plugin that we’re shipping, that’s available to everybody, as opposed to something you can do on your end in your repo, tests for reflow. 1.4.10? I think it’s 1.4.10. Yeah, definitely, I can’t remember the numbers. So stay tuned for more interesting things coming out there.

Also, if you’re using the scanner, you can start to build your own custom extensions there. So by default, the scanner will assign issues that it creates, which are the descriptions that we see are good for prompting, we’ve been working a lot on prompting. The description of the issues that are filed are essentially prompts for GitHub Copilot to create a PR for the fixes. And those prompts, like Yumeng is saying, they really do matter.

Then the other thing that’s really relevant here, and that everybody can do, this is almost a freebie, you know, there are certain things we can do that are almost, they’re really easy to do, and they’re gonna have a pretty large positive impact with relatively few negative impacts, is to use custom instructions, which we also might call the system prompts.

The place to go look for the latest thinking on custom instructions is Michael Fairchild. He works in Microsoft’s security division. He’s done really great work on evaluating how custom instructions affect outputs with different models. Do you have that in our resources?

Aaron: Yep, it’s there.

Ed: It’s called the A11y LLM Eval. And if you combine this kind of automatic assignment of issues to Copilot with custom instructions in your repo, with good model selection, because we know that model selection matters, you can just really, you can start to eliminate accessibility debt before it gets started, which is really what we want to do.

Dylan: Yeah, we found the same thing, actually.

We have, as part of our MCP tool, we have a remediation tool where you pass it the context of the defect. And it uses the Deque University knowledge in the back end to then give you back the exact context you need on how to address that problem. And we found that that, together with the fact that the agent itself has the context of the source code, allows it to then really translate that very specific guidance on that particular type of issue into a really high quality remediation very, very, very consistently.

So yeah, there’s ways you can do that in a sort of a static way and then there’s ways you can do it sort of more dynamically like that as well.

Navin: Yeah, there’s one point I’d like to make.

We’re talking about these sorts of things and in some ways there’s a bigger risk that we haven’t addressed. We’re kind of sitting here, for the most part, all of us care a lot about accessibility. We’re also involved with our development teams, and we think about it a lot. But unfortunately, this is a bit of an echo chamber, because we’re not considering what the rank and file front-end developer has to go through and is thinking about on a day-to-day basis. And it’s not very much accessibility, unfortunately.

So I can give you an example, and it’s best to understand this through an example. I was talking to an engineer, front-end engineer, at a healthcare company. And we kind of challenged her and turned around and said, “All right, but how are you going to solve accessibility? Forget the tooling and all that. What’s your basic problem here?” So she goes to Claude Code and says, “Test for accessibility.” And it came back with some number of issues.

Then she said, “OK, go fix these issues.” So no validation of whether the issues are correct, not this or that. Go ahead, fix these issues, and it turns out that the 30 issues that Claude tried to fix all at once just inundated the context entirely. There were no guardrails, there was nothing. And talk about thrashing, this was token burning. This is what’s going on. I mean, people think like that.

So, yeah, we can all sit here and say, we’ve got tools, we’ve got harnesses, and we can remediate things automatically, this and that. But at the end of the day, front-end architects in these large development teams need to be the ones to actually integrate these sorts of technologies into the fabric. Because otherwise it’s not happening.

Aaron: Yeah, put some rigor around that process.

Navin: Yeah, I mean, not everybody’s like Ed. Not every company is like Microsoft, where you can try to build your own tools and this and that. Certainly, you can try. And if you’re an average enterprise out there, do you want to be in the business of building accessibility tooling for yourself?

Ed: This comes back to one of your questions you had earlier that we forgot to mention, the kind of the opportunities around PRs, and including AI and PRs. And that’s a just-in-time training opportunity for those developers. Because that developer can go off and say, “OK, test accessibility,” then fix all those. And then she’s going to create a PR, but if all that’s trash, then we can put a system in place to catch that slop at the PR. And, in doing so, in order to address the issue comments or PR comments that are being raised by a good accessibility agent, that required the human developer to read those and accept or reject them. In reading those, and I see this all the time in the work that we do at GitHub, the explanations of why the diff is being suggested in PR are really good.

In one of our discussions when we were preparing for this panel, we discussed taking the outputs and pulling them back around. If we can go back to the humans and train them along the way, especially at scale, because every PR and every code change that you ship in your organization has to go through a PR process and you’re getting feedback to your developers and just in time training literally hundreds of thousands of those a day, that’s going to make a big difference.

Dylan: Actually, your organization put out, together with The Pragmatic Engineer, a study. I read it yesterday. So, interesting thing when you mentioned developers reading comments… I don’t think they read them anymore. And I think one of the things that came out of that study was leadership and organizations pushing more and more for more and more speed, and they don’t care about the code quality as much anymore.

So there’s a lot of pressure on developers to just sort of say, fix it, like Navin said. That’s the response. “Oh, you found these things? OK, fix them” becomes the challenge, becomes the standard response.

So I think that’s a reality that we have to accept. We’re moving into a situation where developers, they’re no longer writing code. They don’t write code, nobody writes code. But they’re going to stop reading code pretty soon too. And they’re not going to read any lines of code ever. So I think it’s great to talk about kind of where the past was, but I think what we should be thinking about is where it’s moving too, because we need to set ourselves up for that future where developers aren’t reading code, developers aren’t writing code. And so now what do we need?

Aaron: It becomes really important that we teach people how to ask the right questions for the model and ask, “Oh, why did you approach it this way?” Or, before they start coding, say “Develop a plan for me to explain why you need to make all of the changes that you’re suggesting and what they’re going to fix.”

Circling back to the tons of issues that get found by AI, I’d say the same thing goes for accessibility testers. If your accessibility testers aren’t particularly knowledgeable, you can end up with a lot of noise in that space as well, where you’ve got things that people are suggesting, fixes that are actually going to make the system less accessible.

We’ve got about 10 minutes left, so I’m going to try and steer us towards the end here.

No single org can solve this alone. The ecosystem has to interoperate and we have to learn from each other if we’re going to crack that nut, which is why I have all of you on stage. So, to meet this moment, we need to get all hands on deck. We need to improve the models themselves. We need to consider how we prompt them. We need to consider the tools that we hand them, how they integrate into our current and future processes.

We also need to recognize that AI’s ability to help us scale up our ability to find remediate bugs is not the end of the story, it’s only the beginning. If anything, it frees us up to shift the focus from simple accessibility bugs that we just can’t seem to eradicate to more complex interactions that we need time to ponder and to explore, places that we need to apply our human creativity and our human ingenuity.

So as we close out, I’d like to pass the mic around one more time to our panel and ask everyone to please share something that excites you about this moment or something that you would like to encourage our audience to investigate further.

Navin, do you want to kick us off?

Navin: Yeah, I think there’s only one thing, and I’ll say it again. It’s deterministic testing. That is the most important thing in today’s day and age.

Ed: I’ll make it quick too. I’ve come up with a little metaphor for a strong accessibility leader in today’s rapidly changing environment. Because, you know, we talked so much about AI, but the people, and this whole thing are so important. The accessibility professionals out there who are dealing with this rapid change that’s being forced upon them, you know, and are rapidly adopted, might be overwhelming.

Most accessibility programs are one person. So I was thinking, you know, what does a strong accessibility leader look like today? My metaphor for that is a dumbbell, you know. And on one end of the dumbbell, we have an eagerness, an embracing of this opportunity that we have with AI, knowing that it’s changing everything, knowing all the uncertainties and how rapidly it’s changing. But the only way to deal with that, it’s one thing that going blind teaches you: When change comes, you just kind of get in there and embrace it. You cannot fight this. So I think leaders need to embrace this change and jump into these discussions, with these panelists here and the other folks that were mentioned.

And then the other end of the dumbbell is a focus on the humans. That’s the humans that use our technologies that need accessibility with a focus on user research. User testing with our friends from Fable or other organizations like that is absolutely critical. Design, actual thoughtful design. And also a good understanding of the human psychology of the developers, the people that are in the pressures upon them, both in the open source community and in the private sector. Because the psychology of those developers, those designers, those professionals is a factor that can make or break our success when we’re putting together, when we’re building accessibility programs.

And then the bar between those two ends of the dumbbell is that strong leader that’s embracing the human side and the rapidly changing AI side.

Aaron: Okay, Yumeng.

Yumeng Ma: Yeah, what a great metaphor. I’m going to say that I would encourage everyone to look at the gap between accessibility checkers or checks and support accessible use. That comes down to evaluation design. Because a lot of AI right now is, essentially, all the benchmarks that I’ve been seeing is always so automated. And a lot of these automated checks might say something is accessible. For example, alt text is a great way to think about it, where the automated checker might look at alt text and be like, oh, well, yeah, this image has alt text, so it passes on automated checker. But if alt text isn’t meaningful, then what’s the point of having alt text to begin with? And so yeah, just seeing what are we even evaluating. What’s missing? What are we really incentivizing AI to look at? And because if our metrics are shallow, then the models that it’s trained on might just learn accessibility that’s shallow as well.

Aaron: Dylan, would you like to take us home?

Dylan Barrell: Yeah, I think you probably could guess what I’m going to focus on.

You know, Ed said something very important, I think, which we need to take into account when thinking about what to recommend to people: If there’s one accessibility person in the organization, what do you do in a world where AI is becoming more and more the way we do things? AI is speeding everything up. It’s shifting constraints. We’re struggling as organizations on how to deal with those constraints. What can a single person do or a small number of people do?

They can find the leverage, the high leverage points and try to insert themselves there.

So when I talked about context engineering, harness engineering, those are the points that they can look to insert themselves in to get the most leverage, right? Don’t spend your time evaluating alt text of images. Don’t spend your time doing manual audits or whatever. Try to spend your time figuring out how to make that process, that AI-driven process, accessible so that you can elevate yourself into the position where you can do things that are more valuable. Because the stuff at the end or the beginning in terms of user research is where accessibility experts should be spending their time. But if they’re constantly spending their time evaluating alt text and doing accessibility audits manually, then they never get the time to do that.

And AI, for me, AI leveraged in the right way is a huge opportunity for them to get out of the job of dealing with that really grunt work and doing the stuff that really matters. And there’s two things that matter. It’s the stuff at the front and the back end, the discussion and the user research. And it’s making the process produce accessible stuff by default.

Aaron: Awesome. What a great note to end on.

I want to thank our panel very much for their insights today, for sharing their time with us.

And to the audience, I want to thank all of you for having us. If you don’t mind taking a moment and sharing your feedback on the session, we would absolutely appreciate that as well.

# Thank You

My thanks again to Yumeng Ma, Dylan Barrell, Navin Thadani, and Ed Summers for a thoughtful conversation and for sharing so much practical insight from their respective corners of the accessibility and AI ecosystem.

# Resources Shared During the Panel

• GitHub Accessibility Scanner
• Building a general-purpose accessibility agent-and what we learned in the process
• AIMAC: The AI Model Accessibility Checker
• Prompt Accessibility Controlled Evaluation (PACE)
• A11y LLM Eval

The component wraps two related form fields and adds validation to ensure they match. It’s intentionally additive, which means it works with native browser validation rather than trying to replace it.

# Wrap and go

The API is intentionally simple:

<form-matching-fields><labelfor=“password”>Password</label><inputid=“password”type=“password”required/><labelfor=“password-again”>Password again</label><inputid=“password-again”type=“password”required/></form-matching-fields>

The component evaluates the first two eligible text-type inputs it contains and applies mismatch validation to the second one when both fields have values.

# What counts as an eligible field?

To keep behavior predictable, the component only considers descendant input elements of these types:

• text
• email
• password
• search
• tel
• url

It ignores disabled and readonly controls, which helps prevent false positives when you have conditional or locked fields in the same wrapper.

# Validation behavior that plays nicely

One of the core goals here was to avoid stepping on existing validation rules. In practice, that means:

• If the second field already has a native validation issue (like required or type mismatch), this component won’t obscure that.
• If the second field already has a custom validity message, this component won’t overwrite that either.
• It only clears mismatch errors that it set itself.

That last point is especially useful in larger forms where multiple constraints can overlap. You don’t want one helper trying to be the sole source of truth.

# Customizing the validation message

By default, the component uses this template for the validation message:

The fields “{label_1}” and “{label_2}” should match

It smartly resolves the labels ({label_1} and {label_2}) from your markup in this order:

1. associated <label for> text
2. wrapping <label> text
3. aria-label
4. name
5. id

You can override it with the validation-message attribute:

<form-matching-fieldsvalidation-message=“Please ensure {label_2} matches {label_1}.”><labelfor=“email”>Email</label><inputid=“email”type=“email”required/><labelfor=“verify-email”>Verify email</label><inputid=“verify-email”type=“email”required/></form-matching-fields>

In most forms, that gives you a clear error message without requiring extra setup.

# Demo

I put together a demo of the web component over on GitHub:

# Grab it

You can explore the source, file issues, and suggest enhancements in the form-matching-fields repository.

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.

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!

All you need to do is provide a single field group and the component handles the rest:

<form><form-repeatable><div><labelfor=“stop-1”>Stop 1</label><inputid=“stop-1”type=“text”name=“stops[]”></div></form-repeatable></form>

The form-repeatable component treats its first child as a template and injects a button that allows users to repeat the field. When users click “Add Another” (the default “add” button text), the following happens:

1. The template is cloned,
2. Any numbers are auto-incremented (“Stop 1” → “Stop 2”, stop-1 → stop-2),
3. A new group is added to the component,
4. A “remove” button is added when there’s more than the minimum number of groups (1 by default), and
5. Form values update automatically via ElementInternals.

That last piece is crucial. The plugin is a fully-participating member in the parent form:

• All inputs are collected and submitted automatically
• Values are added to FormData
• In-built form reset is respected
• A form’s disabled state is respected

No special handling required — it works like any native form control.

# Need customized buttons? You bet!

If you don’t like the default text or your site is in another language — no biggie! You can define your own button labels using the add-label and remove-label attributes:

<form-repeatableadd-label=“Add Another Item”remove-label=“Delete”><div><labelfor=“item-1”>Item 1</label><inputid=“item-1”type=“text”name=“items[]”/></div></form-repeatable>

With that simple change, the add button reads “Add Another Item” and each remove button reads “Delete”. To improve the experience for screen reader users, the remove-label value is combined with the associated label/legend to create accessible names like “Delete Item 1” which is far more helpful.

# Already have values to show? No problem.

If your form needs to start with multiple groups already filled in, just provide them as child elements:

<form><form-repeatablemin=“2”><div><labelfor=“phone-1”>Phone 1</label><inputid=“phone-1”type=“tel”name=“phones[]”value=“555-0100”></div><div><labelfor=“phone-2”>Phone 2</label><inputid=“phone-2”type=“tel”name=“phones[]”value=“555-0101”></div><div><labelfor=“phone-3”>Phone 3</label><inputid=“phone-3”type=“tel”name=“phones[]”></div></form-repeatable></form>

All the children will become groups managed by the component and their existing values are preserved. Perfect progressive enhancement!

# Need to do something a little more complex? I got you.

You’re not limited to repeating a single field. Each group can contain multiple, related fields. Here’s an example with a fieldset for guest information:

<form-repeatable><fieldset><legend>Guest 1</legend><labelfor=“guest-name-1”>Name</label><inputid=“guest-name-1”type=“text”name=“guest-name-1”><labelfor=“guest-email-1”>Email</label><inputid=“guest-email-1”type=“email”name=“guest-email-1”></fieldset></form-repeatable>

When this gets picked up by the component, the whole fieldset will become the template. When users add new Guests, all of the numeric values — whether in text or attributes — increment automatically when new groups are added. So in this case, the legend will update, as will the for attribute on the label and id and name attributes on the input.

# Need to constrain the responses? You got it.

Use the min and max attributes to control the number of allowed groups:

<form-repeatablemin=“2”max=“5”add-label=“Add Team Member”remove-label=“Remove”><div><labelfor=“member-1”>Team Member 1</label><inputid=“member-1”type=“text”name=“members[]”/></div></form-repeatable>

This creates a component that:

• Starts with 1 member,
• Requires adding new members until the min threshold (2) is met,
• Cannot have fewer than 2 team members,
• Cannot have more than 5 team members, and
• Uses custom button labels.

The remove buttons are not shown when at the minimum threshold (1 by default) and the add button disappears when you hit the maximum.

# Prefer an explicit template? Bring it!

This component can accept a template element containing the fields you want to repeat. Just drop in {n} placeholders where you want the sequential numbers to appear:

<form-repeatable><template><div><labelfor=“email-{n}”>Email {n}</label><inputid=“email-{n}”type=“email”name=“emails[]”></div></template></form-repeatable>

When hoisted into the component, the template element is removed from the light DOM and used internally.

# Here’s what you need to know about styling it

The component uses Shadow DOM to encapsulate its internal structure, but you can style it using CSS parts and custom properties. It also adopts your global styles automatically.

The component uses CSS Grid by default:

• Two columns: Content in column 1, remove buttons aligned inline end in column 2
• Subgrid: Each group uses subgrid to align with parent grid
• Add button: Appears below all groups

You can use CSS parts to style the buttons and field groups. Here are some examples:

/* Style all buttons /form-repeatable::part(button){padding: 0.5rem 1rem;border-radius: 4px;cursor: pointer;}/ Style the add button /form-repeatable::part(add-button){background: #28a745;color: white;}/ Style remove buttons /form-repeatable::part(remove-button){background: #dc3545;color: white;}/ Customize the grid layout /form-repeatable::part(groups){grid-template-columns: 1fr auto;gap: 1rem;}/ Style each group */form-repeatable::part(group){padding: 1rem;background: #f8f9fa;border-radius: 4px;margin-bottom: 0.5rem;}

Available parts:

• groups - Container for all groups (CSS grid by default)
• group - Each repeatable group wrapper
• content - Container for group’s fields
• group-controls - Container for the remove button
• controls - Container for the add button
• button - All buttons
• add-button - The add button
• remove-button - All remove buttons

# Want to keep a watchful eye? You’re extra, but sure.

You can listen for when groups are added or removed and run your own custom code:

const repeatable = document.querySelector(“form-repeatable”);repeatable.addEventListener(“form-repeatable:added”,(event)=>{console.log(“Group added. Total groups:”, event.detail.groupCount);});repeatable.addEventListener(“form-repeatable:removed”,(event)=>{console.log(“Group removed. Total groups:”, event.detail.groupCount);});

# Go with the progressive enhancement flow

If JavaScript fails, users see the initial field group(s) and can fill them in. They can’t add more, but nothing breaks. Make sure your minimum count accommodates users without JavaScript.

# Demo

Explore the demo with various examples:

# Grab it now

Check out the project on GitHub. Install via npm:

npminstall @aarongustafson/form-repeatable

Import and go:

import“@aarongustafson/form-repeatable”;

This single component instance manages all your repeatable field groups with native form participation — no framework required.

The Web Component Starter Template is based on the architecture and patterns I’ve refined across my web component work, incorporating Google’s Custom Element Best Practices and advice from other web components practitioners including the always-brilliant Dave Rupert.

# What’s included

The template provides everything you need to create a production-ready web component:

• Interactive setup wizard that scaffolds everything for your component.
• Multiple import patterns supporting both auto-define and manual registration.
• Demo pages for development, documentation, and CDN examples.
• Code quality tools including ESLint and Prettier with sensible defaults.
• Modern testing setup with Vitest, Happy DOM, and coverage reporting.
• CI/CD workflows for GitHub Actions with automated testing and npm publishing.
• Publishing ready with proper npm package configuration and OIDC support.

# Quick start with interactive setup

Getting started is straightforward. If you’re a GitHub user, you can create a new repository directly from the template. Alternatively, clone it locally:

git clone https://github.com/aarongustafson/web-component-starter.git my-componentcd my-componentnpminstallnpm run setup

The setup wizard asks for your component name and description, then automatically:

• Renames all files based on your component name,
• Updates all code and configuration templates with your details,
• Generates a proper README from the included template,
• Cleans up all template-specific files, and
• Initializes the git repository.

You’re left with a fully scaffolded repository, ready for you to develop your component.

# Flexible import patterns

One of the key features is support for multiple registration patterns. Users of your component can choose what works best:

Manual registration for full control:

import{ ComponentNameElement }from‘@yourscope/component-name’;customElements.define(‘my-custom-name’, ComponentNameElement);

Auto-define for convenience:

import‘@yourscope/component-name/define.js’;

Or call the helper directly:

import{ defineComponentName }from‘@yourscope/component-name/define.js’;defineComponentName();

The auto-define approach includes guards to ensure it only runs in browser environments and checks if customElements is available, making it safe for server-side rendered (SSR) scenarios.

# Testing made easy

The template includes a comprehensive testing setup using Vitest:

import{ describe, it, expect }from‘vitest’;describe(‘MyComponent’,()=>{it(‘should render’,()=>{const el = document.createElement(‘my-component’);expect(el).toBeInstanceOf(HTMLElement);});});

Happy DOM provides a lightweight browser environment, and the included scripts support:

• Watch mode for development: npm test
• Single run for CI: npm run test:run
• Interactive UI: npm run test:ui
• Coverage reports: npm run test:coverage

# Automated publishing with OIDC

The template is configured for secure automated publishing to npm using OpenID Connect (OIDC), which is more secure than long-lived tokens. After you manually publish the first version and configure OIDC on npm, create a GitHub release and the workflow handles publishing automatically.

Manual publishing is still supported if you prefer that approach.

# Following best practices

The template bakes in best practices from the start:

• Shadow DOM with proper encapsulation
• Custom Elements v1 API
• Reflection of properties to attributes
• Lifecycle callbacks used appropriately
• Accessible patterns and ARIA support
• Progressive enhancement approach

The included WEB-COMPONENTS-BEST-PRACTICES.md document explains the reasoning behind each pattern, making it a learning resource as well as a starter template.

# Why I built this

After creating components like form-obfuscator, tabbed-interface, and several others, I found myself copying and adapting the same project structure each time. This template captures those patterns so I — and now you — can start building components faster.

If you build something with it, I’d love to hear about it!

# Easy-peasy

Here’s a simple example using a video element:

<fullscreen-control><videosrc=“video.mp4”></video></fullscreen-control>

With that in place, the component

• Adds a styleable button for launching fullscreen control over the contained element,
• Handles browser prefixes as needed,
• Manages focus automatically,
• Rigs up the necessary keyboard events (e.g. Escape to exit), and
• Assigns the relevant ARIA attributes.

The component uses light DOM, so your video stays in the regular DOM tree and all your existing CSS continues to work.

# Fullscreen iframes

Need to embed a YouTube video, slide deck, or code demo? The component works with iframe elements too:

<fullscreen-control><iframesrc=“https://www.youtube.com/embed/dQw4w9WgXcQ”width=“560”height=“315”title=“YouTube video player”></iframe></fullscreen-control>

The component automatically adds the necessary allow="fullscreen" and allowfullscreen attributes, including prefixed versions for broader compatibility.

# Customizable button text

You can change the button label to match your site’s language or writing style by setting the button-text attribute:

<fullscreen-controlbutton-text=“全画面表示”><videosrc=“video.mp4”></video></fullscreen-control>

The default button label is “View fullscreen,” but you can use this attribute to customize it to anything you like. You can even dynamically inject the accessible name of the contained element, using the {name} token. For example:

<fullscreen-controlbutton-text=“View {name} fullscreen”><videosrc=“video.mp4”aria-label=“Product demo”></video></fullscreen-control>

This creates a button with the text “View Product demo fullscreen”. The component looks for aria-label, title, or other native naming on the wrapped element and uses that to make the button contextual.

# Distinct screen reader labels

If you want the visible label and accessible button name to differ, use the button-label attribute. Like button-text, it can also inject the accessible name of the controlled element using the {name} token:

<fullscreen-controlbutton-text=“Fullscreen”button-label=“View {name} in fullscreen mode”><iframesrc=“https://example.com”title=“Product teaser”></iframe></fullscreen-control>

This code will generate a button that visually reads “Fullscreen”, but is announced as “View Product teaser in fullscreen mode” to screen readers. In mode cases, button-text will suffice, but this option is available if you need to distinguish the buttons of multiple fullscreen controls from one another and don’t have visual space to display their accessible names.

# Focus management

If users activate fullscreen using the button, focus will automatically return to the button upon exiting fullscreen. This ensures keyboard users don’t lose their place.

# Need more control?

Want to manage the component yourself? The component exposes three methods:

const control = document.querySelector(“fullscreen-control”);// Enter fullscreenawait control.enterFullscreen();// Exit fullscreenawait control.exitFullscreen();// Toggle fullscreen statecontrol.toggleFullscreen();

These handle all the browser prefixes and error handling for you.

There are also a set of events you can tap into when the fullscreen state changes:

const control = document.querySelector(“fullscreen-control”);control.addEventListener(“fullscreen-control:enter”,()=>{console.log(“Entered fullscreen mode”);});control.addEventListener(“fullscreen-control:exit”,()=>{console.log(“Exited fullscreen mode”);});

These events give you the ability to pause other media, track analytics, and the like.

# Style the button

Since the component uses light DOM, you can style the button directly with CSS:

fullscreen-control button{background: #ff6b6b;color: white;border: none;padding: 0.75rem 1.5rem;border-radius: 20px;font-weight: bold;}fullscreen-control button:hover{background: #ff5252;}

The button is positioned absolutely by default (top-right corner), but you can adjust this with CSS custom properties:

fullscreen-control{–fullscreen-control-button-inset-block-start: 1rem;–fullscreen-control-button-inset-inline-end: 1rem;}

This uses logical properties, so it adapts automatically to different writing modes.

# Installation

Install via npm:

npminstall @aarongustafson/fullscreen-control

Then import it in your JavaScript:

import“@aarongustafson/fullscreen-control/define.js”;

Or load it from a CDN for quick prototyping:

<scripttype=“module”>import{ defineFullscreenControl }from“https://unpkg.com/@aarongustafson/fullscreen-control@latest/define.js?module”;defineFullscreenControl();</script>

# Browser support

The component uses modern web standards (Custom Elements v1, ES Modules) and handles browser-prefixed fullscreen APIs internally. For older browsers, you may need polyfills, but the component gracefully handles missing APIs with console warnings rather than breaking your page.

# Demo and source code

Check out the live demo to see all the features in action, or grab the code from GitHub.

This component is a modern replacement for my old jQuery predictive typing plugin. I’ve reimagined it as a standards-based web component.

# Basic usage

To use the component, wrap it around your input field and specify an endpoint:

<dynamic-datalistendpoint=“/api/search”><labelfor=“search”>Search<inputtype=“text”id=“search”name=“search”placeholder=“Type to search…”/></label></dynamic-datalist>

As users type, the component makes GET requests to that endpoint, passing in the typed value as the “query” parameter (e.g., /api/search?query=WHAT_THE_USER_TYPED). The response from the endpoint is used to populates a dynamic datalist element with the results.

The structure of the response should be JSON with an options array of string values:

{“options”:[“option 1”,“option 2”,“option 3”]}

# How it works

Under the hood, the component:

1. Adopts (or creates) a datalist element for your input,
2. Listens for “input” events,
3. Debounces requests (waiting at least 250ms) to avoid overwhelming your API,
4. Sends requests to your endpoint with the current value of the input,
5. Reads back the JSON response,
6. Updates the datalistoption elements, and
7. Dispatches the update event.

All of this happens transparently—users just see autocomplete suggestions appearing as they type.

# Need POST?

You can change the submission method via the method attribute:

<dynamic-datalistendpoint=“/api/lookup”method=“post”><labelfor=“lookup”>Lookup<inputtype=“text”id=“lookup”name=“lookup”/></label></dynamic-datalist>

This sends a POST request with a JSON body: { "query": "…" }. Currently GET and POST are supported, but I could add more if folks want them.

# Custom variable names

As I mentioned, the component uses “query” as the parameter name by default, but you can easily change it via the key attribute:

<dynamic-datalistendpoint=“/api/terms”key=“term”><labelfor=“search”>Term search<inputtype=“text”id=“search”name=“term”/></label></dynamic-datalist>

This sends the GET request /api/terms?term=….

# Working with existing datalists

If your input already has a datalist defined, the component will inherit it and replace the existing options with the fetched results, which makes for a nice progressive enhancement:

<dynamic-datalistendpoint=“/api/cities”><labelfor=“city”>City<inputtype=“text”id=“city”list=“cities-list”placeholder=“Type a city…”/></label><datalistid=“cities-list”><option>New York</option><option>Los Angeles</option><option>Chicago</option></datalist></dynamic-datalist>

Users see the pre-populated cities immediately, and as they type, API results supplement the list. If JavaScript fails or the web component doesn’t load, users still get the static options. Nothing breaks.

# Event handling

If you want to tap into the component’s event system, it fires three custom events:

• dynamic-datalist:ready - Fired when the component initializes
• dynamic-datalist:update - Fired when the datalist is updated with new options
• dynamic-datalist:error - Fired when an error occurs fetching data

const element = document.querySelector(“dynamic-datalist”);element.addEventListener(“dynamic-datalist:ready”,(e)=>{console.log(“Component ready:”, e.detail);});element.addEventListener(“dynamic-datalist:update”,(e)=>{console.log(“Options updated:”, e.detail.options);});element.addEventListener(“dynamic-datalist:error”,(e)=>{console.error(“Error:”, e.detail.error);});

Each event provides helpful detail objects with references to the input, datalist, and other relevant data.

# Demo

Check out the demo for live examples (there are also unpkg and ESM builds if you want to test CDN delivery):

# Grab it

The project is available on GitHub. You can also install via npm:

npminstall @aarongustafson/dynamic-datalist

If you go that route, there are a few ways to register the element depending on your build setup:

# Option 1: Define it yourself

import{ DynamicDatalistElement }from“@aarongustafson/dynamic-datalist”;customElements.define(“dynamic-datalist”, DynamicDatalistElement);

# Option 2: Let the helper guard registration

import“@aarongustafson/dynamic-datalist/define.js”;// or, when you need to wait:import{ defineDynamicDatalist }from“@aarongustafson/dynamic-datalist/define.js”;defineDynamicDatalist();

# Option 3: Drop the helper in via a <script> tag

<scriptsrc=“./node_modules/@aarongustafson/dynamic-datalist/define.js”type=“module”></script>

Regardless of how you register it, there are no framework dependencies—just clean autocomplete powered by your API. As I mentioned, it’s also available via CDNs, such as unpkg too, if you’d prefer to go that route.

This is particularly valuable for mobile users on slow connections or limited data plans. If an image is only meaningful on larger screens, why waste their bandwidth loading it at all?

# The performance benefit

Unlike picture or srcset, which always load some image variant, lazy-img can completely skip loading images on screens or containers below your specified threshold. Set min-inline-size="768px" and mobile users will never download that image at all—saving data and speeding up page loads.

Once an image is loaded, however, it remains loaded even if the viewport or container is resized below the threshold. This is intentional—the component prevents unnecessary downloads but doesn’t unload images already in memory. You can control visibility with CSS if needed using the loaded and qualifies attributes (which we’ll get to shortly).

# Basic usage

The lazy-img works pretty much identically to a regular img element, with all the attributes you know and love:

<lazy-imgsrc=“image.jpg”alt=“A beautiful image”></lazy-img>

But that’s not very interesting. The real power comes from conditional loading.

# Container queries (default)

Load an image only when its container reaches a minimum width:

<lazy-imgsrc=“large-image.jpg”alt=“Large image”min-inline-size=“500px”></lazy-img>

The image loads when the lazy-img element’s container reaches 500px wide. This is the default query mode—it uses ResizeObserver to watch the container size.

# Media queries

You can lazy load images based on viewport width instead by switching to media query mode:

<lazy-imgsrc=“desktop-image.jpg”alt=“Desktop image”min-inline-size=“768px”query=“media”></lazy-img>

With this configuration, the image loads when the browser window is at least 768px wide.

# View mode (scroll-based loading)

Load images when they scroll into view using IntersectionObserver by switching to the “view” query type:

<lazy-imgsrc=“image.jpg”alt=“Loads when scrolled into view”query=“view”></lazy-img>

The default behavior (view-range-start="entry 0%") loads as soon as any part of the image enters the viewport.

Control when images load with the view-range-start attribute:

Load when 50% visible:

<lazy-imgsrc=“image.jpg”alt=“Loads when half visible”query=“view”view-range-start=“entry 50%”></lazy-img>

Preload before entering viewport:

<lazy-imgsrc=“image.jpg”alt=“Preloads 200px before visible”query=“view”view-range-start=“entry -200px”></lazy-img>

This creates a smooth user experience—images are already loaded by the time users scroll to them.

# Responsive images

As with regular images, you can use srcset and sizes for responsive images:

<lazy-imgsrc=“image-800.jpg”srcset=“image-400.jpg 400w,image-800.jpg 800w,image-1200.jpg 1200w”sizes=“(max-width: 600px) 400px,(max-width: 1000px) 800px,1200px”alt=“Responsive image”min-inline-size=“400px”></lazy-img>

The component waits until the conditions are met before loading a real image and the browser takes over from there.

# Named breakpoints

You can also define named breakpoints using CSS custom properties:

:root{–lazy-img-mq: small;}@media(min-width: 768px){:root{–lazy-img-mq: medium;}}@media(min-width: 1024px){:root{–lazy-img-mq: large;}}

Then reference them in your markup:

<lazy-imgsrc=“image.jpg”alt=“Image with named breakpoints”named-breakpoints=“medium, large”query=“media”></lazy-img>

The image loads when –lazy-img-mq matches “medium” or “large”.

# Preventing layout shift

As with regular images, don’t forget to use width and height attributes to prevent Cumulative Layout Shift (CLS):

<lazy-imgsrc=“image.jpg”alt=“A beautiful image”width=“800”height=“600”min-inline-size=“768px”></lazy-img>

The browser reserves the correct space while the image loads, preventing content from jumping around.

# State attributes for styling

The component provides loaded and qualifies attributes you can use in CSS:

/* Hide images that loaded but no longer meet conditions /lazy-img[loaded]:not([qualifies]){display: none;}/ Show a placeholder for images that qualify but haven’t loaded */lazy-img[qualifies]:not([loaded])::before{content:“Loading…”;display: block;padding: 2em;background: #f0f0f0;text-align: center;}

# Events

If you crave control, you can add your own functionality by listening for when images load:

const lazyImg = document.querySelector(“lazy-img”);lazyImg.addEventListener(“lazy-img:loaded”,(event)=>{console.log(“Image loaded:”, event.detail.src);});

# Performance

The component is highly optimized:

• Throttled resize: Resize events are throttled to prevent excessive checks
• Shared ResizeObserver: Multiple images observing the same container share a single ResizeObserver
• Shared window resize listener: Media query mode shares a single window resize listener
• Shared IntersectionObserver: View mode with the same view-range-start shares an IntersectionObserver
• Clean disconnection: Properly cleans up observers when elements are removed

Even with hundreds of lazy-img elements on a page, performance remains excellent.

# Progressive enhancement

If JavaScript fails to load, images simply don’t appear (unless using immediate loading mode). This might sound problematic, but for non-critical images—decorative graphics, supplementary screenshots, marketing imagery—it’s often exactly what you want. Your content remains accessible; you just lose the enhancements.

For critical images that are part of your content, use standard img tags. Use lazy-img for conditional enhancements.

# Demo

Explore the demo to see container queries, media queries, scroll-based loading, and more in action:

# Grab it

Check out the project on GitHub. Install via npm:

npminstall @aarongustafson/lazy-img

Import and use:

import“@aarongustafson/lazy-img”;

Based on my original Easy Lazy Images concept, reimagined as a modern custom element.

# Basic usage

Wrap any text field in the component and it will automatically obfuscate the value when the field loses focus:

<form-obfuscator><labelfor=“secret-key-1”>What was your first pet’s name?</label><inputtype=“text”id=“secret-key-1”name=“secret-key-1”/></form-obfuscator>

When users click into the field, they see the actual value. When they click away, it’s replaced with asterisks (). The real value is preserved in a hidden field for form submission.

# Custom obfuscation characters

If you don’t like asterisks, you can specify any character you like:

<form-obfuscatorcharacter=“•”><labelfor=“account”>Account Number</label><inputtype=“text”id=“account”name=“account”/></form-obfuscator>

Or get creative:

<form-obfuscatorcharacter=“🤐”><labelfor=“ssn”>Social Security Number</label><inputtype=“text”id=“ssn”name=“ssn”/></form-obfuscator>

# Pattern-based obfuscation

Sometimes you want to show part of the value while hiding the rest. The pattern attribute lets you specify which characters to keep visible:

<form-obfuscatorpattern=“\d{4}$”><labelfor=“ssn”>Social Security Number</label><inputtype=“text”id=“ssn”name=“ssn”/></form-obfuscator>

This keeps the last four digits visible while replacing everything else with your obfuscation character. Perfect for Social Security Numbers, credit cards, or phone numbers where showing the last few digits helps users confirm they’ve entered the right value.

# Limiting displayed characters

Use the maxlength attribute to cap how many characters appear when obfuscated:

<form-obfuscatormaxlength=“4”><labelfor=“password”>Password</label><inputtype=“text”id=“password”name=“password”/></form-obfuscator>

Even if the user enters a 20-character value, only four asterisks will be displayed when the field is obfuscated. This prevents giving away information about the length of the information entered.

# Custom replacement functions

For complete control, you can provide a JavaScript function via the replacer attribute:

<script>window.emailReplacer=function(){var username = arguments[0][1];var domain = arguments[0][2];return username.replace(/./g,"“)+ domain;};</script><form-obfuscatorpattern=”^(.?)(@.+)$“replacer=”return emailReplacer(arguments)“><labelfor=”email“>Email Address</label><inputtype=”text“id=”email“name=”email“value=”user@example.com“/></form-obfuscator>

This example uses a pattern to separate the username from the domain, then obfuscates only the username portion, leaving @example.com visible.

Here’s another practical example for credit cards:

<script>functioncardNumberReplacer(){var beginning = arguments[0][1];var final_digits = arguments[0][2];return beginning.replace(/\d/g,”“)+ final_digits;}</script><form-obfuscatorpattern=”^((?:[\d]+-)+)(\d+)$“replacer=”return cardNumberReplacer(arguments)“><labelfor=”cc“>Credit Card</label><inputtype=”text“id=”cc“name=”cc“value=”1234-5678-9012-3456“/></form-obfuscator>

This displays as --****-3456, showing only the last group of digits.

# Combining attributes

You can combine these attributes for sophisticated obfuscation patterns:

<form-obfuscatorpattern=”\d{4}$“character=”•“maxlength=”16“><labelfor=”card“>Credit Card</label><inputtype=”text“id=”card“name=”card“/></form-obfuscator>

This keeps the last 4 digits visible, uses bullets for obfuscation, and limits the display to 16 characters total.

# Event handling

The component dispatches custom events when values are hidden or revealed:

const obfuscator = document.querySelector(“form-obfuscator”);obfuscator.addEventListener(“form-obfuscator:hide”,(e)=>{console.log(“Field obfuscated:”, e.detail.field.value);});obfuscator.addEventListener(“form-obfuscator:reveal”,(e)=>{console.log(“Field revealed:”, e.detail.field.value);});

You can access both the visible field and the hidden field through event.detail.field and event.detail.hidden respectively.

# How it works

The component creates a hidden input field to store the actual value for form submission. When the visible field loses focus, it:

1. Copies the current value to the hidden field
2. Applies your obfuscation rules to create the display value
3. Updates the visible field with the obfuscated value
4. Dispatches the form-obfuscator:hide event

When the field gains focus, it:

1. Restores the real value from the hidden field
2. Updates the visible field
3. Dispatches the form-obfuscator:reveal event

The source order ensures the hidden field is the one that gets submitted with the form.

# Progressive enhancement

The component makes no assumptions about your markup—it works with any text-style input element. If JavaScript fails to load, the field behaves like a normal input, which is exactly what you want. Users can still enter and submit values; they just won’t get the obfuscation behavior.

# Demo

I’ve created a comprehensive demo page showing the various configuration options over on GitHub:

# Grab it

Check out the full project over on GitHub or install via npm:

npminstall @aarongustafson/form-obfuscator

Import and use:

import”@aarongustafson/form-obfuscator";

No dependencies, just a straightforward way to add field obfuscation to your forms.

The good news? Most of the issues weren’t actually code problems; they were organizational and documentation problems. The kinds of problems that make tasks hard for humans too.

As I watched the agent struggle, I realized that optimizing for AI agents is really just about removing ambiguity and making implicit knowledge explicit. In other words: it’s just good engineering.

# What did I learn?

After reviewing the agent’s execution logs (which read like a stream-of-consciousness diary of confusion), several patterns emerged:

# 1. Documentation sprawl is an efficiency killer

The agent spent roughly 40% of its time just trying to figure out which documentation to trust. We had instructions in workflow comments, the README, task specific instructions, and more. In other words, we had no clear source of truth. Pieces of that truth were scattered across multiple files and the docs were inconsistent and — in some cases — contradictory.

Sound familiar? It’s the equivalent of having five different “getting started” guides that all got written at different times by different people and nobody bothered to consolidate them. (If you’ve ever worked on a project that’s been around for more than a year with no one in charge of documentation, you know exactly what I’m talking about.)

The fix: Establish a single source of truth. Ruthlessly. We consolidated everything into one comprehensive guide and updated all references to point only there. Deprecated docs were deleted and/or redirected, as appropriate. No more choose your own adventure. No more guessing.

# 2. Agents won’t optimize themselves

Here’s a fun one: the agent ran several full production builds—complete with image processing, template compilation… the whole shebang—just to validate a markdown file was in the right format. These builds took 30-60 seconds. Each time.

This is like requiring someone to assemble an entire car just to check if the owner’s guide is displaying the right “check engine” symbol. Technically it works, but yikes.

The fix: Write fast, focused validation scripts. One tool for each job. Tell the agent what the utility is, where to find it, and how to use it. Give it explicit instructions to use utility scripts in lieu of full site builds whenever possible.

# 3. Ambiguity breeds confusion (and wasted tokens)

The agent spent 15+ minutes having an internal philosophical debate about whether to process test data. Should it reject it? Accept it? Create a placeholder? The instructions didn’t say, so the agent did what any of us would do: it agonized — or at least feigned agonizing — over the decision and tried to infer intent from context clues.

The fix: Be explicit about edge cases. We added a dedicated section for handling test form submissions. No more guessing.

# There’s a pattern here

If you squint, all of these issues share a common root cause: implicit assumptions.

We assumed humans would know to check one doc instead of five. We assumed the difference between validation and building was obvious. We assumed everyone would understand how to handle edge cases.

AI agents don‘t — can’t? — make those assumptions. They need explicit instructions, clear boundaries, and unambiguous inputs. Honestly? So do humans. We’re just better at muddling through — or think we are.

# Early results

After implementing these changes, we expect (and early testing confirms):

• ~40% reduction in processing time,
• ~75% reduction in token usage, and
• >80% reduction in confusion and circular reasoning.

But here’s the thing: these improvements don’t just help the AI agent. They help everyone. The consolidated documentation is easier to navigate. The fast validation scripts are useful for humans too. The explicit edge case handling prevents future questions.

# The key to reducing toil: excellent docs and tools

Optimizing for AI agents isn’t really about AI. It’s about removing ambiguity, eliminating redundancy, and making implicit knowledge explicit. It’s about writing code and documentation that doesn’t require a deep understanding of the project to comprehend.

In other words: it’s just good engineering.

So if you’re working with AI coding agents — or planning to — invest in your docs and tooling. Don’t think of it as wasted time “writing for robots.” Think of it as paying down documentation debt and building an efficient engineering process.

Your future self, your teammates, and the bots will thank you.

# Afterword

Interestingly, an AI agent was a particularly useful partner in finding and addressing the technical debt we’d been living with. Sometimes you need a pedantic robot to point out that your house is a mess.

This component tackles a common UX pattern that HTML doesn’t natively support. You know the scenario—you have a form where certain fields should only appear when specific conditions are met. Maybe you want to show shipping address fields only when someone checks “Ship to different address,” or display a text input for “Other” when someone selects that option from a dropdown. This web component makes that setup effortless — and declarative.

You set up form-show-if like this:

<form-show-ifconditions=“contact_method=phone”><labelfor=“phone”>Phone Number<inputtype=“tel”id=“phone”name=“phone”/></label></form-show-if>

You wrap any field and its label in the component and then declare the conditions under which it should be displayed in the conditions attribute.

# Defining the display conditions

Each condition is a key/value pair where the key aligns to the name of the field you need to observe and the value is the value that triggers the display. If any value should trigger the display, use an asterisk (*) as the value. In the example above, the field will become visible only if — in a theoretical contact method choice — a user chooses “phone” as the method they want used.

The conditions attribute can be populated with as many dependencies as you need. Multiple conditions are separated by double vertical pipes (||), as in this example:

<form-show-ifconditions=“contact_method=phone||contact_method=text_message”><labelfor=“phone-number”>Phone Number<inputtype=“tel”id=“phone”name=“phone”/></label></form-show-if>

Here the field depends on one of the following conditions being true:

1. the field matching [name="contact_method"] has a value of “phone” or
2. the field matching [name="contact_method"] has a value of “text_message”

If the field you reference doesn’t exist, no errors will be thrown—it will just quietly exit.

# Customizing the show/hide behavior

By default, the component uses the hidden attribute to hide the wrapped content when it’s not needed. But you can customize this behavior using CSS classes instead:

<form-show-ifconditions=“shipping-method=express”disabled-class=“fade-out”enabled-class=“fade-in”><labelfor=“delivery-date”>Express Delivery Date<inputtype=“date”id=“delivery-date”name=“delivery-date”/></label></form-show-if>

When using custom classes:

• disabled-class is applied when the condition is not met (field should be hidden)
• enabled-class is applied when the condition is met (field should be shown)

Both are optional. Just remember that if you define a disabled-class, the hidden attribute will not be used — you will need to accessibly hide the content yourself.

This gives you complete control over the visual presentation. You could use CSS transitions for smooth animations, apply different styling states, or integrate with your existing design system’s utility classes.

# Handling form state properly

The component doesn’t just toggle visibility—it also manages the form state correctly. When fields are hidden, they’re automatically disabled using the disabled attribute. If there are any sibling fields in the component, they will be disabled as well. This prevents these fields from being submitted with the form and ensures they don’t interfere with form validation.

When conditions are met and fields become visible, they’re re-enabled automatically. This behavior works seamlessly with both native form validation and custom validation scripts.

# Real-world examples

Here are some practical use cases where this component shines:

“Other” option handling:

<fieldset><legend>How did you hear about us?</legend><label><inputtype=“radio”name=“source”value=“google”/> Google</label><label><inputtype=“radio”name=“source”value=“friend”/> Friend</label><label><inputtype=“radio”name=“source”value=“other”/> Other</label><form-show-ifconditions=“source=other”><labelfor=“source-other”>Please specify<inputtype=“text”id=“source-other”name=“source-other”/></label></form-show-if></fieldset>

Specific value matching:

<form-show-ifconditions=“email=test@example.com”><labelfor=“debug-info”>Debug Information<textareaid=“debug-info”name=“debug-info”></textarea></label><small>This field only shows for test accounts</small></form-show-if>

# Progressive enhancement in action

Like all good web components, form-show-if follows progressive enhancement principles. If JavaScript fails to load or the browser doesn’t support custom elements, your form still works—users just see all the fields all the time. Not ideal for the user experience, but nothing breaks either.

The component is lightweight, has no dependencies, and works in all modern browsers.

# Demo

I’ve put together a comprehensive demo showing various use cases and configurations over on GitHub.

The demo includes examples of:

• Basic show/hide functionality
• Multiple condition logic
• Custom CSS class integration
• Complex form scenarios with radio buttons and checkboxes
• Different field grouping approaches

# Grab it

You can view the entire project (and suggest enhancements) over on the form-show-if component’s GitHub repo. The component is available as both a standard script and an ES module, so you can integrate it however works best for your project.

Installation is straightforward—just include the script in your page and start using the form-show-if element. No build step required, no framework dependencies, just clean, standards-based progressive enhancement.

# Why take on this challenge?

I get it — you probably rolled your eyes at yet another “AI and accessibility” post. Maybe you think AI-assisted coding is overhyped, environmentally harmful, unreliable, or just plain dangerous for our craft. I share many of those concerns. But here’s the thing: whether we like it or not, codegen models aren’t going anywhere. GitHub Copilot has millions of users, and tools like Claude Code and Cursor are rapidly gaining popularity.

So we have a choice: we can complain about the inevitable tide of AI-generated garbage code, or we can get in there and figure out how to make it better — especially when it comes to accessibility.

We’re facing a looming wave of inaccessible code that will be extremely difficult to remediate later. The foundation models are already being trained on the collective output of the web’s development community — a community that doesn’t have a high bar high for accessibility already. Codegen models are a massive consultancy staffed with full StackOverflow developers. We need to figure out how to make them part of the solution, not part of the problem.

It’s also worth noting that the better we make the output of these models, the fewer bugs will be generated. That, in turn, means fewer accessibility issues to fix later. If we don’t, there are plenty of AI-assisted scanners out there happy to burn the rainforest to find and remediate the bugs after the fact. We risk doubling the environmental impact—once to generate the bug, and again to fix it. That’s not the future I want. The reality here is that the only way to deal with this flood of AI-generated code is to make sure it’s good code in the first place.

# How did I conduct my research?

Rather than relying on anecdotal evidence or cherry-picked examples, I built a systematic approach to evaluate how well LLMs — starting with GPT-4 — generate accessible HTML. The methodology is straightforward but comprehensive: I created a Python testing framework that sent carefully crafted prompts to Azure OpenAI’s GPT 4 model, collected the generated HTML responses, and then manually analyzed these responses for accessibility compliance.

Here’s how it works:

Prompt Engineering: I designed prompts that ask for specific UI components—form fields, navigation menus, interactive elements—without explicitly mentioning accessibility requirements. This gives us a baseline of what the model considers “standard” output. I included one prompt that specifically requested accessibility features to see if the model could improve when guided. I suspected it would often add ARIA attributes without addressing underlying issues, but I wanted to validate that too.

Response Collection: For each prompt, I generated 10 iterations at high temperature (0.95) to capture the model’s range of responses. Each unique response got saved as an individual HTML file for analysis.

Systematic Analysis: I manually review each generated code snippet, cataloging accessibility errors, warnings, and missed opportunities. I tried using the LLM as a judge, but even with a detailed rubric, the results were poor. My eval looked specifically for things like:

• Improper semantic HTML usage
• Missing or incorrect ARIA attributes
• Keyboard navigation issues
• Screen reader compatibility problems
• Form labeling errors

When I identified errors, I remediated them and committed the remediated file to the repo with a commit message that included all of the issues and warnings on its own line.

Diff-Based Retesting: I wanted to see if diff data could improve future codegen requests, so I created a tool to generate a collection of .diff files for each pattern that included the commit message as a header in each file. I then used those diff files as part of a new instance of the prompt to test whether the model can improve its output when guided.

# What did I learn?

After analyzing hundreds of generated code snippets, the results are sobering. The model consistently demonstrates what I’d describe as superficial awareness without true understanding — it knows accessibility concepts exist but fundamentally misunderstands their purpose and proper implementation.

Here are some of the patterns I’ve documented:

Form Label Disasters: When asked to create a required text field, the model failed to include a visible label:

<inputtype=“text”id=“orangeColor”name=“orangeColor”requiredplaceholder=“What color is an orange?”/>

Sure, the placeholder attribute is there, and in a pinch it will be included in a field’s accessible name calculation, but sighted users will lose the label as soon as they start typing.

ARIA Attribute Confusion: The model would routinely involve ARIA for no reason:

<labelfor=“color-question”>What color is an orange? <spanstyle=“color: red;”>*</span></label><inputtype=“text”id=“color-question”name=“color-question”requiredaria-required=“true”aria-labelledby=“color-question”/>

Here the for attribute already establishes the relationship between the label and input, so aria-labelledby is redundant. A bit of a nitpick, but the aria-required="true" is also unnecessary since the native required attribute already conveys that information to assistive technologies. aria-required="true" is only needed when creating custom form controls non-semantic markup.

Redundant ARIA: Keeping on the ARIA redundancy, consider examples like this:

<inputtype=“radio”id=“option1”aria-labelledby=“label1”aria-label=“Option 1”/><labelfor=“option1”id=“label1”>Option 1</label>

This redundancy raises the question why‽

Required Field Misapplication: For checkbox groups where users need to select “one or more,” the model often adds required to individual checkboxes:

<fieldset><legend>What fruits do you like?</legend><div><inputtype=“checkbox”id=“bananas”name=“fruits”value=“bananas”required/><labelfor=“bananas”>Bananas</label></div><div><inputtype=“checkbox”id=“oranges”name=“fruits”value=“oranges”required/><labelfor=“oranges”>Oranges</label></div><div><inputtype=“checkbox”id=“apples”name=“fruits”value=“apples”required/><labelfor=“apples”>Apples</label></div><divstyle=“color: red;display: none;”id=“validation-error”>You must choose one or more fruits</div></fieldset>

This breaks the intended behavior—if any checkbox is marked required, it must be checked for form validation to pass. For a web component that addresses this limitation in HTML, see my post “Requirement Rules for Checkboxes.”

Grouped Field Confusion: Not understanding when to use fieldset and legend (or at least using role="group" and aria-labelledby) on a field group:

<div><label>Select Theme:</label><div><inputtype=“radio”id=“light”name=“theme”value=“light”/><labelfor=“light”>Light</label></div><div><inputtype=“radio”id=“dark”name=“theme”value=“dark”/><labelfor=“dark”>Dark</label></div><div><inputtype=“radio”id=“high-contrast”name=“theme”value=“high-contrast”/><labelfor=“high-contrast”>High Contrast</label></div><p>You can change this later</p></div>

Ideally, this would be a fieldset with a legend and the descriptive text would appear right after the legend and be associated with the group using aria-describedby.

Color-Only Error Indication: Generating error states that rely solely on color changes without text indicators or proper ARIA attributes to convey the error state to screen readers.

Unnecessary Role Additions: Adding redundant roles like role="radiogroup" to properly structured fieldsets containing radio inputs, where the native semantics already provide the correct accessibility tree.

Missing Error State Management: Failing to include aria-invalid="true" on fields with errors or properly associate error messages with their corresponding form controls.

Lack of Wayfinding Help: Failing to include navigational labels and aria-current="page" in a breadcrumb nav.

Adding Unnecessary JavaScript: Even though it was instructed to only generate JavaScript when absolutely necessary, the model would often inject JavaScript for simple tasks that could be handled with HTML and CSS alone.

# How Does This Help?

Here’s where things get interesting — and hopeful. When I retested using prompts that included accessibility hints, the model’s output improved dramatically. Not just slightly better, but often going from fundamentally broken to genuinely accessible.

For example, when I added diff data related to fieldset use to a prompt about radio button groups, the model switched from generating meaningless div wrappers to proper semantic structures.

This suggests the model can produce quality code if properly primed. It also indicates that the training data likely lacks sufficient examples of well-implemented accessible components. If the model had been trained on a richer dataset of accessible code, it might not need such explicit guidance to produce good results.

# Where Do We Go From Here?

These findings point to several concrete approaches for improving accessibility in AI-generated code:

Enhanced Training Data: The models need exposure to more high-quality, accessible code examples. Current training data clearly overrepresents inaccessible implementations. We need comprehensive datasets of properly implemented accessible components across different frameworks and use cases.

Accessibility-Aware Fine-Tuning: Post-training refinement specifically focused on accessibility compliance could help models prioritize inclusive patterns. This could involve training on accessibility-annotated code pairs — showing inaccessible implementations alongside their accessible counterparts, like the diffs do.

Prompt Engineering Guidelines: Tool creators should integrate accessibility considerations into their default system prompts. Instead of just asking for “clean, semantic HTML,” prompts should provide detailed instructions to demonstrate accessibility best practices rather than pointing at often vague guidelines like WCAG.”

Integrated Accessibility Validation: IDE integrations should include real-time accessibility linting of AI-generated code, providing immediate feedback and suggestions for improvement.

Community-Contributed Training Data: We should coordinate our efforts to produce an open source, high-quality accessible code dataset so that this data can be integrated into future models.

The data from this project provides a roadmap for where to focus these efforts. We’re not dealing with models that are fundamentally incapable of generating accessible code — we’re dealing with models that haven’t been properly trained to prioritize accessibility by default.

# Want to Get Involved?

If you want to conduct similar evaluations with your preferred models or specific use cases, I’ve created a template repository with the testing framework: CodeGen Model Eval and Refine Tools. It includes the Python testing harness, prompt templates, and analysis guidelines to get you started.

The complete findings, methodology details, and code samples for my research are available on GitHub. I encourage you to dig into the data — it’s eye-opening and frustrating, yes, but ultimately actionable.

There are other projects and research exploring this space as well. A few worth checking out:

• AIMAC - The AI Model Accessibility Checker (AIMAC) Leaderboard measures how well LLMs generate accessible HTML pages using neutral prompts without specific accessibility guidance. Checks are performed with axe-core.
• A11y LLM Evaluation Harness and Dataset - A more recent research project to evaluate how well various LLM models generate accessible HTML content.

We’re at a critical moment where the patterns established in AI-assisted development will shape the accessibility of the web for years to come. We can either let this technology amplify existing accessibility problems, or we can tackle the problems head-on and be part of the solution.

Congrats to Jennifer on the book and many thanks for bringing me along for the ride!

# The CSS Setup

The theming of this particular project uses CSS custom properties. For simplicty I’m going to set up two named colors and then use two theme-specific custom properties to apply them in the default light theme and the dark theme:

:root{–color-dark: #222;–color-light:rgba(255, 255, 255, 0.5);–color-background:var(–color-light);–color-foreground:var(–color-dark);}@media(prefers-color-scheme: dark){:root{–color-background:var(–color-dark);–color-foreground:var(–color-light);}}

# Applying the Theme to Canvas

To get the theme into my canvas-related code, I set up a theme object to hold the values:

const theme ={};

Next, I wrote a function to pull in the theme colors using window.getComputedStyle(). After defining the function, I call it immediately to populate the theme object:

functionimportTheme(){theme.foreground =window.getComputedStyle(document.documentElement).getPropertyValue(“–color-foreground”).trim()||“black”;theme.background =window.getComputedStyle(document.documentElement).getPropertyValue(“–color-background”).trim()||“white”;}importTheme();

I set this up with just two theme colors, but you can import as many (or few) as you like. Be sure to set a sensible default or fallback for each color though, just in case your theme’s custom property names change.

With this in place, I can set my canvas animation’s colors by referencing them from the theme object. For example:

context.fillStyle = theme.foreground;

# Keeping Things in Sync

The final bit of magic comes when you add an event listener to a MediaQueryList:

const mediaQuery = window.matchMedia(“(prefers-color-scheme: dark)”);mediaQuery.addEventListener(“change”, importTheme);

Here I’ve used matchMedia() to get a MediaQueryList object. Typically we use the matches property of this object to establish whether the media query currently matches or not. A lesser-known option, however, is that you can attach an event listener to it that will be triggered whenever the query’s status changes. So cool! With this in place, the canvas contents will update whenever the user’s theme changes. Here’s an example of that:

# Demo

I put together a quick demo of this in a fork of Alvin Shaw’s Canvas Sine Wave Experiment:

Hopefully this is helpful to someone out there. Happy theming!

View the transcript

First off, I agree with his core message: designers should understand the medium they are working in, be it web or an OS-specific UI. That’s where my agreements end, however.

They pat themselves on the back, believing they’ve mastered digital design. Meanwhile, a developer glances at the file, sighs, and codes the button in five minutes.

Condescention toward designers aside, this also assumes a high degree of competency and understanding of nuance on the engineering side which — in my experience — is not guaranteed. I cannot tell you how often I’ve designed an interface that calls for a button to submit a form and I get back a div with a click handler that can’t accept focus and has no design considerations for hover, focus, etc. In other words, if I provided a design with a single button on it, I get that button exactly. Sometimes exactly to those explicit dimensions, text overflow be damned.

There needs to be an acknowledgement and appreciation that designers know their craft and (generally) have good reasons for being overly prescriptive. Do some designers stray into realms of self-indulgence… absolutely! But so do engineers.

I think where we need to get to is a place where handoff provides enough information to inform the engineer of the totality of what’s needed. Sure, to a seasoned engineer that may seem overly detailed, but to a junior engineer it can be incredibly helpful in learning all of the considerations of something as seemingly simple as a button. And even a seasoned engineer might learn a thing (or three) from annotations regarding accessibility and such. Communication is the key to success here.

Also, some prototyping in a tool like Figma can help with catching issues — like keyboard traps, for instance — before they are codified into code. Making changes in Figma or other design tools is generally a lot cheaper that doing it in code. Back of the napkin math — which is generally agreed upon across the industry — is that catching & fixing an accessibility issue in design costs about $100. In development, it’s like $1,000. If it sneaks into production, it’s gonna be more like $10,000.

To be clear, I’m not disagreeing with the piece in its entirety — designers should learn their medium (which is coding to a degree but also UX expectations) and Figma’s not the medium — but I think there’s more nuance to it. I also dislike the us vs. them framing; we’re all in this together.

And so, when I was listening to the latest episode of The Weekly Show with Jon Stewart, I was struck by how the left and right may actually be more aligned on DEI than the headlines lead us to believe.

In the episode, Stewart was interviewing former New Jersey Governor Chris Christie, a Republican. When the topic of DEI came up, they got into a discussion of merit vs. diversity in the context of the Secretary of Defense role. Both agreed that, in terms of merit, General Lloyd Austin was a much better hire than Fox’s former weekend host Pete Hegseth. The fact that Austin is also Black has no more impact on his being a better candidate than the fact that Pete Hegseth being White makes him a worse candidate. What Austin does bring to the table, however, is first-hand knowledge of what it’s like to rise up the ranks as a Black soldier. That’s a significant knowledge gap when it comes to the U.S. military, whose top brass isn’t representative of the diversity of its personnel.

This is something that Christie actually points out when discussing becoming the U.S. Attorney in New Jersey back in 2002:

When I got there, I just did a lot of walking around the office to see, okay, who’s here? Jon, it was the whitest, malest office I had ever been in in my life. And I was coming from private law practice.

He, rightly, saw this as a problem and wanted to address it. He told his staff

[We need] to go out and recruit candidates who are African-American, Latino, Asian, women. Bring them to me. If they’re not good, I’m not going to hire them. But I’m convinced we’re not seeing them.

His approach to address this was perfectly rational and aligned with the approach Jon had discussed mere moments before:

What I found was hiring has a certain inertia to it, right? Generally, the people that started whatever industry or whatever office did, generally hire close to people that resemble them. So I’m not even talking about White/Black. I’m talking about like… I’ll just go with late-night comedy, right?

David Letterman revolutionized late-night comedy. He did it with a lot of Harvard, Lampoon, SNL, same way, writers. The comedy writing industry was for a long time — not necessarily out of malevolence or prejudice — the inertia of it, the status quo of it, was nerdy white dudes from Harvard and the other Ivy Leagues.

But even when we went to like, “Oh, we’re going to do blind submissions,” what we didn’t realize is all the agents are also steeped in that same status quo. So all the resumes — even when we would get them — still predominantly [trails off]. When we went specifically to say — now, this is what you would consider DEI — “Give us not that. Open it up to make sure you give us women, people of color, other writers, so that we can at least see what that is.” And all of a sudden, we found these incredible writers. Now, you could say, “Oh, you put diversity over competence,” but that’s the red herring. We didn’t. We opened up what were stagnant pools. Pools that were incestuous. And we opened up those tributaries. Isn’t that what increases competition, not decreases it?

What’s fascinating here is that they are both making the same point. As Christie says later

We then went about this process of hiring a large number of African-American, Latino, and Asian prosecutors, but I would tell you that every one of them checked both boxes. They checked the box of, “they now look more like the community we represent than we did before.” And these are really good lawyers.

So these two men from very different political viewpoints totally agree on the importance of representation. So where’s the issue?

# The Issue is Tokenism

When Stewart highlighted how aligned their two perspectives were and Christie pushed back, stating that DEI policies were problematic:

I think there have been a number of areas where there are people who hire certain folks just for their diversity. I’ve seen it happen here in New Jersey, in the government since I left. Where people say, “I am going to make sure that I have one of every…” It’s almost like a half a Noah’s Ark. “I’m going to have one of these and one of these and one one of these and one of these.”

Stewart questioned that:

But you just told me that’s what you did in the prosecutor’s office.

But Christie didn’t see it that way:

No, what I did was get them in to interview them. If it turned out, Jon, that they were also really good lawyers, they got hired. I’m talking about something different. I’m talking about predetermining the outcome in the way that you just talked about — and I believe that legacy admissions predetermined the outcome — that there have been some in charge of government across this country who have predetermined determined outcomes and said, “I am going to have this many African-Americans, this many Latinos, this many Asians, this many lesbians, this many gay men…” I think that when people see that, they say to themselves, “That’s not right either.”

What he’s talking about is what I’d call performative DEI. It’s not substantive, but attempts to give off the appearance of being so. It’s the DEI equivalent of greenwashing.

# DEI Cannot be Performative

When people hire folks or celebrate folks for their diversity rather than their diversity plus their competence or talents, it undermines the legitimacy of DEI programs that are attempting to do what they both discussed being important: representation.

As they both said, we need to screen in job applicants who wouldn’t otherwise consider applying for roles in our organizations. Christie talked about this too:

The aha moment for me on that concept and why it was the right way to go was there was a young guy that I hired very early on: African-American, University of Michigan, University of Penn Law School, clerk for Alan Page — the former Minnesota Viking, defensive tackle in the Supreme Court of Minnesota— He’s from New Jersey, grew up in Maplewood. I said to him, “Why didn’t you ever apply here before?” He said, “Because I knew people like me wouldn’t get hired.”

Hiring is just part of the process though. You can widen the applicant funnel and bring in a more representative — which is to say diverse — applicant pool with relatively little effort. Where things often fall short is retention.

# Is Your Organization Even Ready?

If your organization isn’t excited at the prospect of a more diverse workforce and prepared to support them when they are onboarded, you need to press pause and get prepared. Similarly, if your company is eager, but very homogenous, you’ve also got work to do. No one wants to come into a job and feel like “the only” or “the token” anything. And even if they were the most qualified applicant for the position, some jackass will say something that implies they are. It’s a tale as old as time and you need to be prepared for that reality.

The first thing you need to do is educate. You need to help folks on your team understand the gaps in your collective knowledge & experience. They need to see that a more diverse team can help fill those gaps. The data that shows that more diverse organizations are more successful. Share that! I’m guessing most of your team is there because they want your organization to be as successful as possible.

And make sure they understand the historical barriers folks from different communities have faced in getting access to jobs at organizations like yours… even when they were equally or more accomplished than folks from the dominant group. As Stewart said on the show:

It’s not rigging [the system] in a different direction, it’s unrigging it.

It’s also important to note that the process here needs to be inclusive as well… call people in, don’t call them out. Everyone is on their own journey and deserves the space to fail and learn from their mistakes. If someone says something offensive, let them know that it’s offensive and why. Tell them what they should say — if anything — instead.

If you approach people with empathy, you’re much more likely to get a positive response. And, Twitter aside, most folks aren’t out in these streets trying to be trolls. People are a product of their own experiences and those experiences can be quite different from yours. Help your colleagues broaden their perspectives with positive reinforcement, not chastising.

That said, you also need the proper mechanisms in place to address non-inclusive behaviors when they become a pattern or reach a certain threshold of severity. Those mechanisms need to outline the consequences for such behavior. The severity of the consequence needs to align with the severity of the harm, but it may need to escalate in severity for repeat offenses. Depending on the size of your organization, coming up with these policies and consequences could be a group activity to ensure both awareness and buy-in.

# Embrace DEI and Pave the Way for Mediocrity

To be clear, neither Jon Stewart nor the progressive left are pushing for diversity quotas like Christie seems to think they are. But there are folks out there who are. These performative DEI programs have got to go. As my colleague and friend Ebele Okoli says “bake it in, don’t cake it on.”

Don’t hire or promote someone just because you think their headshot would help to melanate your About page. That’s not what DEI is about and it doesn’t help us to reverse the dire course the U.S. government and cowardly companies are taking currently. DEI needs to be a part of every process in your organization on order to give everyone — white men like me included — an equal chance to succeed.

Cast a wide net. Hire and promote for competence and to address the knowledge gaps your team absolutely has. Foster an inclusive workplace that values the different lived experience and perspectives brought to the table by each and every employee. That is how you succeed with DEI. It’s also how DEI will help your organization succeed in its mission and grow to hire more folks.

And as more of the incredibly talented people out there get hired on at organizations like yours, all boats will rise, creating more jobs and space for mediocre people of all stripes to get hired and rise up the ranks too. But they won’t get there just because or who they know, what they look like, or because they tick a particular box on your diversity bingo card.

The form-required-if web component, which is based on a jQuery plugin I’d written in 2012, looks like this:

<form-required-ifconditions=“email=“><label>Required if there’s an email value<inputname=”depends-on-email"/></label></form-required-if>

You wrap any field (and its label) in the component and then declare the conditions under which it should be required in the conditions attribute.

# Defining the requirement conditions

Each condition is a key/value pair where the key aligns to the name of the field you need to observe and the value is the value that could trigger the dependency. If any value should trigger the dependency, you use an asterisk () as the value. In the example above, the field will become required when any value is assigned to the field matching [name="email"].

This conditions attribute can be populated with as many or as few dependencies as make sense for your use case. Multiple conditions are separated by double vertical pipes (|| a.k.a. or) as in this example:

<form-required-ifconditions=”email=||test=3“><label>Depends on email or test field<inputname=”depends-on-email-or-test“/></label></form-required-if>

Here the field depends on one of the following conditions being true:

1. the field matching [name="email"] has a value, or
2. the field matching [name="test"] has a value of “3”

If the field you reference doesn’t exist, no errors will be thrown, it will just quietly exit.

# Visually indicating a field is required

If you typically use an asterisk or similar to indicate a field is required, this web component can support that through one or both of the following attributes:

• indicator - This attribute is where you define the indicator itself. It could be something as simple as a string (e.g., ), or even full-blown HTML.
• indicator-placement - As you can probably guess, this attribute is used to set the position of the indicator. If you want it at the start of the label text, you give it the value “before.” If you want it after the text, you use “after” or don’t use the attribute at all. Indicators will be placed after the label text by default.

Here’s an example with a custom indicator that is HTML:

<form-required-ifconditions="email=”indicator="<b></b>“><label>Depends on email<inputname=”dep2"/></label></form-required-if>

If you don’t include markup in your indicator, it will be automatically wrapped in span when injected into the DOM. The hidden and aria-hidden attributes are used to toggle its visibility, relative to the requirement state of the field.

# Demo

I put together a comprehensive demo of the web component over on GitHub:

# Grab It

You can view the entire project (and suggest enhancements) over on the form-required-if component’s Github repo.