Most accessibility fixes are mechanical, not a design debate, and an agent that already reads and rewrites code well can work through a large share of them in an afternoon.
Accessibility work has a reputation, in most teams I have been part of, as the thing that sits at the bottom of the backlog: important in principle, perpetually outranked by whatever feature is closer to shipping, and treated as expensive because fixing it properly is imagined to require a specialist and a redesign. Running it through a coding agent changed my view of the cost, not the importance, since the importance was never in question. What changed is realising how much of the actual work is mechanical rather than a matter of judgement, and mechanical work is exactly the kind an agent handles well. I had absorbed that reputation for years without ever actually pricing the work myself.
Take the most common offenders in an ordinary web codebase: an image with no description of what it shows, a button that is a clickable div with no keyboard handler, a form field with no label attached to it, a focus order that jumps somewhere nonsensical after a modal closes. None of these require a design meeting. Each one has a mechanically correct fix that follows directly from reading the surrounding markup, what the image is next to, what the button does when clicked, which label belongs with which field, and an agent can read a whole codebase’s worth of these in the time it would take a person to review one file, because the pattern matching involved is exactly the kind of task these tools are good at.
What makes it the cheapest win rather than just a cheap one is that the fixes rarely touch anything contentious. Nobody on a team argues about whether an image needs a description of what it shows, the way they might argue about a colour or a layout choice. There is very little to debate on whether an input has a label, which means an agent can propose the fix, a reviewer can approve it in seconds because there is nothing to argue over, and the change ships without the usual friction that slows down anything touching the interface. Low-controversy work is underrated as a category, and this is some of the lowest-controversy work available in a typical codebase. None of it requires taste, which is exactly why it moves quickly once someone actually starts.
The part I had to actually do myself, rather than delegate, was verifying the fixes were real rather than cosmetic. Reading the diff and confirming a label attribute got added is not the same as confirming the page is actually usable with a keyboard alone or with a screen reader turned on, and I do not trust a fix in this category until I have tried it that way myself. An agent can get the markup mechanically correct and still leave the actual experience broken if the surrounding interaction does not behave the way the markup now claims it does, so the check has to be using the thing the way someone who needs it would, not reading the code and assuming the intent matches the result.
What I have ended up doing is running an accessibility pass across a codebase the same way I would run a linter, routinely, mechanically, on things that are objectively broken regardless of taste, and treating it as a background task an agent chips away at continuously rather than a project someone has to schedule. The backlog item that used to sit at the bottom because it felt expensive turns out to be one of the cheaper things on the list, once the mechanical part is handed to something that is good at mechanical, and the only part that still needs a person is trying the result the way someone who actually relies on it would. The backlog did not get shorter because the standard changed. It got shorter because the actual cost of clearing it turned out to be far lower than the reputation the work had been carrying around for years.