# A more accessible web might be the Agentic Web's most overlooked gain

> Accessibility helps people use the web directly and gives browser agents a better foundation for assisting them - without taking control away.

*Published 2026-08-20 · 5 min read*

---

Over the past year, I’ve been in a lot of conversations about the Agentic Web - mostly about how agents can make us faster and more efficient, or how they can handle everyday chores for us.

However! Today I want to share what, for some, might be one big hot take 🌶️😁:

> A more accessible web might be the most important - and the most under-recognized - gain from agentic interactions on the web.

## Accessibility is about people

This is very important to me: **Accessibility is for humans**.

Semantic HTML, labels, headings, clearly labelled page sections, keyboard support and properly implemented ARIA give **assistive technologies** useful information about an interface.

This is not "agent infrastructure" - it is the foundation of human access to the web. **Agents simply happen to benefit from it too.** Browser agents can "understand" pages through a combination of screenshots, the DOM and accessibility tree snapshots, so a page that exposes clear roles, names and states gives both screen readers and some agents a much better map of what is happening.

## Compliance is not the same as a good experience

The numbers are not great... The [2026 WebAIM Million report](https://webaim.org/projects/million/) found detectable WCAG failures on **95.9% of one million popular home pages**. Automated tests only catch some accessibility problems, so this is not a complete accessibility audit of every site - but it shows how common basic barriers still are.

And even a website that meets accessibility requirements can still be very hard to use.

This is not only my take 😁 - it is the feedback I gathered from people who actually use screen readers every day. W3C's [guidance on WCAG conformance](https://www.w3.org/WAI/WCAG22/Understanding/conformance.html) says the same thing: content can satisfy all success criteria and still not be usable by people with a wide variety of disabilities.

Why does that gap exist?

Interfaces are designed visually first. A sighted user can look at a page, notice grouping, ignore a promotional carousel and jump straight to the thing they need. A screen reader presents the page piece by piece, so the user relies on headings, links, form controls and clearly labelled sections to understand its structure and move around efficiently.

That does not mean screen reader browsing is simply one long linear read. Experienced users move quickly through headings, controls and regions. But that speed depends on the page exposing a useful structure in the first place.

## An agent can become a new interface to the same website

Imagine an online shop with hundreds of products, filters, popups and comparison tables.

A user could explore all of it through their screen reader. Or they could ask a **co-browsing** agent:

> Find waterproof jackets in my size, explain the differences, and show me the three best matches. Do not add anything to the cart yet.

The agent can do the repetitive navigation, bring back a smaller set, and leave the final choice to the user.

To me it starts to look like **assistive technology** - or, to be more precise, an **assistive layer**. Browser agents are not established assistive technologies (yet? 😀), and they should **complement, not replace**, the tools and workflows people already trust.

## Structured tools can make it even easier

An agent can try to operate any website by interpreting screenshots, inspecting the DOM, reading the accessibility tree and simulating clicks.

But **developers cannot assume that a clever model will figure out a broken interface**.

If a button has no name, a custom widget hides its state, or the focus order makes no sense, the agent is working with the same bad clues we already gave to assistive technologies. Vision models and reasoning can sometimes work around the damage. But *sometimes* is not a strategy 🙂.

This is where `WebMCP` adds another piece. A website can expose a structured tool such as `search_products` or `add_to_cart`. The tool has a description, an input schema and a defined action.

That makes interaction faster and more reliable, because the agent can call the website's own functionality instead of putting together those page signals itself.

There is a trap here though 🙃.

Once a website can expose `search_products`, it gets tempting to treat that as the accessibility work. Ship the tools, let the agent take care of the rest, move on.

**A structured tool is not a replacement for an accessible interface**. It helps with delegated actions, and only for the people who want to delegate.

So in my opinion the direction is right 👍, as long as we keep both: accessible interface for direct use, structured tools for delegated actions, and a human who can move between them.

## When help starts making choices for you

Here is where my "hot take" needs a reality check 😀

Assistive technology should give a person more control, not less. But an agent does not only read and click - it can interpret, rank, summarize and potentially "decide" what to bring back to the user.

That creates a risk:

> The easier the agent makes the web, the easier it becomes for the agent to quietly decide which parts of the web the user gets to experience.

If I ask for three jackets, why did it pick those three? Did it hide a cheaper option? Did it mistake an advertisement for a recommendation? Did the website expose a tool that steered it towards products with a better margin?

Users still need independent exploration, access to the original structure, a way to ask *"what did you skip?"*, and the ability to take control back from the agent at any point. Recommendations should be explainable. Filters should be visible. Actions should be reversible where possible - if an action cannot be reversed, the agent should always check with the user first.

## How does the user verify what happened?

**Co-browsing** has a simple safety story for sighted users: watch the screen. But what happens when visual inspection is the exact thing the agent is helping with? 🤔

The agent says it selected the correct date, applied the discount and added the blue jacket in size XL. How does a blind or low-vision user verify that before paying?

For browser agents, I think that means an accessible action history, clear before-and-after states, read-back of critical fields, receipts, undo and confirmation before sensitive actions.

> The user should be able to inspect the result through their **preferred assistive technology** instead of relying on the same agent to confirm its own work.

## Make the website work for everyone

In this article, I focused mostly on how agents might support blind and low-vision users. But modern agents can support many other ways of interacting too!

I believe we should build websites that are accessible to everyone.

There is also a very practical business case: when someone cannot browse your products, complete your form or check out, they cannot become your customer. **By investing in accessibility, you are welcoming users who otherwise would not be able to interact with your business**.

**Build the accessible website first.**

Do that, and one investment covers two interaction models: people using the interface directly, and people working with an **assistive layer** beside them.

The Agentic Web might save everyone a few clicks. For some people, it might open a door that is currently closed 💡.

That feels like the gain worth paying attention to!

More soon. ✨