Agent Accessibility: A Copernican Shift from Human-Centric to Agent-Centric Software

Here’s a doozy of a Copernican Shift.

This is one of those moments where you have to take a conceptual leap. First, we learned that the Earth was not the center of the universe. Then we learned that the Sun wasn’t either. Now we understand that we are moving at an unfathomable speed through space, corkscrewing through the plasma wake of a fusion reactor. Multiple universes anyone? Quantum simulation?

Buckle up, because software is undergoing a shift of similar magnitude.

For the entire history of software, we have assumed that humans sit at the center of the system. Interfaces were designed to be seen, navigated, clicked, and understood by people. Accessibility, in that worldview, meant ensuring that more humans—across a wider range of abilities and contexts—could successfully interact with those interfaces.

That assumption is now quietly breaking.

We are entering a world in which humans increasingly do not operate software. They brief it. They express intent, define constraints, and evaluate outcomes. The actual execution—the navigation, sequencing, and coordination across systems—is delegated to agents.

When that happens, the center of gravity moves. And when the center moves, everything built around the old center begins to fail in ways that are subtle at first and structural over time.

This post is about that shift, and about why the modern web—particularly the Web 2.0, JavaScript-heavy, app-like web we have collectively optimized for—is deeply hostile to agents. Not accidentally. By design.

When the web was readable by default

The early web had an underrated virtue: it told the truth.

HTML described documents. A heading was a heading. A form was a form. A link was a link. The Document Object Model—the DOM—was not an implementation detail. It was the contract. Humans interpreted that structure visually through browsers, and machines interpreted it directly.

That shared contract is what made early accessibility possible. Screen readers worked because structure meant something. Automation worked because structure meant something. Search worked because structure meant something.

Accessibility, in that era, was not a checklist layered on top of design. It emerged naturally from the fact that meaning was encoded directly in the document itself.

Over time, we traded that property away.

What Web 2.0 actually changed

Modern front-end frameworks did more than improve interactivity. They changed what a web page is.

In a typical Single Page Application, the server no longer sends a meaningful document. It sends a shell. The DOM that arrives over the wire is skeletal—often little more than a root container and a set of script tags. The page’s meaning is not present at load time. It is constructed later, at runtime, after JavaScript executes, APIs respond, experiments resolve, and state converges.

From a human perspective, this mostly works. We are patient. We scroll. We click. We infer meaning from partial signals.

Agents do none of those things.

Agents parse.

And when they parse a modern site, what they encounter is not a document but a process.

The DOM is where agent accessibility actually lives

This is the part that most “AI-friendly UX” conversations miss.

Agents do not experience pixels. They do not see layouts or colors. They experience the DOM. The DOM is their source of truth.

On a large number of modern sites, that truth is incomplete at best and actively misleading at worst. The initial DOM often contains no meaningful content at all. Headings, calls to action, pricing tables, even navigation elements may not exist until client-side rendering completes.

From an agent’s point of view, the most important parts of the page are not hidden below the fold. They are absent.

This is not an edge case. It is the default architecture of the modern web.

It helps to make the divergence explicit.

The Same Page, Two Realities

This is not a tooling gap. It is a representational failure.

A concrete failure mode: the vanishing call to action

Consider a simple task: an agent is asked to evaluate a product page and determine how to get started.

A human lands on the page and immediately sees a prominent “Get Started” button—bright, centered, visually obvious.

An agent lands on the same page and inspects the DOM. What it finds is a root <div>, a JavaScript bundle, and perhaps a loading indicator. The button does not yet exist. It will only be created after JavaScript loads, feature flags resolve, personalization rules fire, and the correct component tree hydrates.

To the agent, there is no declared action to take.

This is not a tooling problem. It is a representation problem. The system has failed to declare its affordances in a way that can be reliably inspected.

Another failure mode: semantics replaced by aesthetics

Design systems and component libraries have normalized a quiet semantic regression.

Buttons become clickable <div> elements. Forms become bespoke abstractions. Lists become visual groupings rather than structural lists. Everything looks right, but nothing says what it is.

Humans infer intent from visual cues. Agents cannot. When the DOM does not distinguish between a primary action and a decorative container, the agent has no principled way to determine what matters.

Traditional accessibility once demanded semantic honesty because assistive technologies depended on it. We relaxed that discipline when humans were the only consumers we optimized for.

Agents bring that discipline back—with interest.

Information hidden behind choreography

The modern web is full of choreography. Content appears on hover. Details hide behind tabs. Pricing collapses into accordions. Critical constraints live inside modals.

To humans, this feels elegant and uncluttered. To agents, it is opaque.

Key information often exists only after a specific interaction sequence, and that sequence is encoded in JavaScript logic rather than declared in the DOM. The agent is forced to reverse-engineer not just content but behavior.

That is the opposite of accessibility. The system requires participation before it reveals meaning, and agents are not participants. They are interpreters.

We have already learned this lesson once

This pattern should feel familiar.

For years, teams insisted they were “building for humans, not bots.” Then search engines reshaped the web. Suddenly structure mattered again. Semantic markup mattered again. Content that could not be crawled effectively stopped existing.

That was indexing.

Agents are not indexing. They are executing.

If a system cannot be confidently interpreted, it cannot be acted upon. If it cannot be acted upon, it will be bypassed in favor of systems that can.

The false comfort of “humans in the loop”

At this point, many organizations reach for reassurance. Humans are still in the loop, they say. Humans are still involved.

This is comforting, but it misses the point.

Of course humans are in charge. They set goals, define intent, and judge outcomes. But they are no longer in charge of execution, and designing systems as though they are is a category mistake.

We do not design compilers around human-in-the-loop execution. We do not design databases assuming a person will supervise every query. We design them to execute correctly, predictably, and legibly for machines.

Agents deserve the same respect.

Optimizing for narrated interaction—showing humans what an agent is doing—does not solve the real problem. The real problem is making the system itself legible enough that the agent can operate without supervision.

The real Copernican Shift

Here is the shift hiding in plain sight.

We are moving from human-centric software to agent-centric systems.

Humans brief. Agents execute.

Accessibility, in this world, is no longer primarily about accommodating human perception. It is about enabling machine comprehension. That means treating the DOM not as a rendering artifact but as a contract. It means server-rendered truth instead of client-side illusion. It means explicit semantics, stable structure, and declared action models.

Ironically, the path forward looks a lot like the path we abandoned.

Where this series is headed

This is the first post in a series on Agent Accessibility. Future pieces will get much more concrete—patterns that work, architectures that fail, and practical ways to build sites that agents can actually understand and act upon.

For now, the point is simple.

The web we are building today is optimized for humans pretending to be machines—clicking, hovering, hunting for meaning.

Agents will not do that.

They will route around systems that cannot explain themselves clearly. They will prefer software that exposes intent, declares capability, and tells the truth in its structure.

That is the next frontier of accessibility. And that is the Copernican Shift most teams have not yet realized they are already standing inside.