I’ve stopped trying to appeal to your empathy.
For the better part of a decade, I’ve been the person in the pull request comments begging you to stop using clickable <div>s. I’ve written the documentation. I’ve linked the WCAG guidelines. I’ve explained, until I was blue in the face, that screen readers rely on semantic HTML to navigate a page.
And mostly? You ignored me.
Not you specifically, maybe. But the industry. We built Single Page Applications that are essentially piles of generic containers held together by JavaScript and hope. We treated accessibility (a11y) like a nice-to-have, something to sprinkle on top right before launch if there was budget left. There never was.
But here we are at the end of 2025, and suddenly, the tone has shifted. Not because everyone grew a conscience overnight. No, it’s because your messy DOM is breaking the AI agents.
The Accessibility Tree isn’t just for screen readers anymore
Here’s the thing about those autonomous agents we’re all integrating into our workflows now. When an AI tries to “read” a webpage to perform a task—booking a flight, scraping data, or navigating a dashboard—it doesn’t look at the pixels like a human does. It doesn’t “see” that your blue rectangle looks like a button.
It reads the code. Specifically, it often relies on a simplified representation of the DOM, very similar to the Accessibility Tree that screen readers use.
If your button is coded like this:
<div class="btn-primary" onclick="submitForm()">
<span>Go</span>
</div>
A sophisticated vision-enabled model might figure it out. Eventually. After burning a bunch of inference tokens trying to guess if “Go” is a label, a verb, or a button. But if you’re building for speed and accuracy, relying on visual inference is sloppy engineering.
However, if you write this:
<button aria-label="Submit User Profile">
Go
</button>
The agent knows exactly what that element is (role="button") and exactly what it does (“Submit User Profile”). No guessing. No hallucinating that the button navigates to a “Go” programming language tutorial.
Ambiguity is the enemy of automation
I was debugging a scraping agent last week that kept failing on a client’s e-commerce site. It was supposed to add a specific item to the cart. It kept crashing or adding the wrong item.
I looked at the markup. It was a disaster.
Every product card had a button labeled “Add”. Just “Add”. Visually, it was obvious which button belonged to which product because they were next to each other. But in the DOM? It was just a list of identical nodes.
The agent had no context. It was effectively blind.
We added aria-label="Add [Product Name] to Cart" to the buttons. That’s it. One attribute. The success rate of the agent went from 40% to 100% instantly.
The irony is palpable. We couldn’t get the budget to fix this for blind users for three years. But the minute it hindered the “AI transformation strategy,” it was fixed in a sprint.
ARIA Labels: The API for your UI
Think of ARIA (Accessible Rich Internet Applications) attributes as metadata for your interface. You provide APIs for your backend data, right? You wouldn’t just dump a raw database row into a JSON response without keys.
So why do you dump raw UI elements without labels?
When you use aria-label, aria-description, or explicit roles, you are defining the contract of your UI. You are telling any programmatic consumer—be it a screen reader used by a human or a headless browser driven by an LLM—what the intent of that element is.
The “Table Stakes” argument didn’t work
We used to say accessibility was table stakes. It wasn’t. If it were, 90% of the web wouldn’t fail basic compliance checks.
But now, semantic clarity is table stakes for the agent economy. If your competitor’s site is easily navigable by a personal shopping bot and yours is a cryptic puzzle of nested <div>s, guess where the automated orders are going to go?
The bot doesn’t have patience. It won’t struggle through your bad UX. It will just fail and move on.
How to fix it (without rewriting everything)
You don’t need to burn your codebase down. You just need to be explicit.
1. Label your icons.
If you have a button that is just a magnifying glass icon, a screen reader sees nothing. An AI sees an SVG path. Neither is helpful.
Bad:
<button><svg ... /></button>Good:
<button aria-label="Search catalog"><svg ... /></button>2. Describe state changes.
When a user clicks a dropdown, does the DOM reflect that it’s open?
Use aria-expanded="true". Agents need to know the current state of the UI to decide their next action. If the agent clicks “Menu” and the DOM doesn’t explicitly say “the menu is now open,” the agent might click it again, closing it. I’ve seen this loop happen. It’s hilarious to watch, but terrible for business.
3. Link inputs to labels.
Please, for the love of clean code, use the for attribute on your labels or aria-labelledby.
<!-- The agent knows this input is for the email address specifically -->
<label for="email">Email</label>
<input id="email" type="email" autocomplete="email" />
Without this association, the agent has to infer relationships based on proximity, which is fragile.
A cynical win is still a win
Look, I’ll be honest. It bothers me a little that we’re finally cleaning up our HTML to make life easier for software rather than people. It feels backwards. We should have cared about the human experience first.
But I’m a pragmatist.
If the motivation you need to finally add aria-label to your navigation buttons is “to optimize for agentic workflows,” I will take it. I don’t care why you fix the accessibility tree, as long as you fix it.
Because the result is the same: a web that is more semantic, more structured, and easier to navigate. The blind user using a screen reader benefits just as much as the ChatGPT instance trying to order pizza.
So go ahead. Tell your boss you’re “optimizing the DOM for high-fidelity AI agent interaction.” Put it on your quarterly goals. Use the buzzwords.
Just put the damn labels on the buttons.
