---
title: "Accessible web for humans and agents"
description: "We've made a better web for humans. The same primitives — semantic HTML, alt text, captions — now help agents read and act. Treat agents as a new kind of user."
author: "olaf"
author_name: "Olaf Sulich"
tags: ["agents","accessibility","web"]
published_at: "2026-08-20T16:10:42.479Z"
canonical: "https://mega.dev/accessible-web"
---
For years we tried to build a web that everyone could use. Thanks to standards and the growth of web technology, the digital world is a far better place than it was a decade ago.
Then AI changed everything. We have new problems now, and no good answers yet.
How do the solutions we already built help us adapt the web for agents? How do today's agentic standards shape the next ones?
We've made a better web for humans. It's time to do the same for agents.
## What we did for humans
We've come a long way toward a better, more inclusive web.
HTML5 changed the web for good. It introduced semantic elements that let developers describe the content on their pages more precisely, which made those pages usable for people on screen readers.
Alongside semantic tags, WCAG grew into a huge body of standards for building accessible digital products. It reached well beyond HTML and touched almost every part of browsing the web: guidelines for publishing media, color contrast, font sizes, alt text, labels, and proper focus handling for keyboard navigation.
Thanks to a lot of talented, hard-working people, accessible primitives started to appear. They answered a real gap in native HTML and the difficulty of building high-quality, spec-compliant UI components. That's how we got Radix UI, Headless UI, React Aria, Base UI, and similar libraries. Shadcn/ui was built on top of them, and today it's the default choice for building web apps. Build on it and you get both visual flexibility and a solid accessibility foundation.
## Different species, similar problems
None of what we built over the years went to waste.
Google [put it well](https://developer.chrome.com/docs/lighthouse/agentic-browsing/accessibility-for-agents):
While accessibility standards are written for humans, many of the design principles are also helpful for agents.
Is your HTML well structured, with a clean heading hierarchy? Then you can generate markdown from it and hand it to users through a copy-to-markdown button. A tiny change that saves a lot of time and energy.
Using semantic tags? During computer use, an agent walking your page knows it's clicking a real button instead of guessing which div is a fake one pretending to be clickable.
Do your images have alt text? An agent understands the image better and can decide whether it's worth downloading and processing for more detail, or whether the alt plus surrounding context is enough.
Video? Same thing. Ship captions up front and your users' agents won't have to transcribe anything themselves.
Recently Google started counting accessibility as one of the key factors in [Lighthouse's agentic browser scoring](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring). That shows how important supporting agents is, and how much of that support you already get from work you've done for people.
## Agents operate on your behalf
Reading page content is one thing, performing actions is a completely different story. I remember when one of the first big standards, the [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro), showed up, people lost their minds over it. MCP opened agents up to the outside world and gave us a lot of new power.
MCP isn't flawless. Enough rough edges showed up that most people doing local work with agents moved to CLI tools instead.
Adam writes in [I was wrong about MCP](https://x.com/_overment/status/2076440928726708612):
So the whole 'MCPs vs CLIs' debate doesn't really make sense, we're talking about different use cases. Shifting the perspective from a connector to a capability layer makes the concept of an MCP server far more flexible and, in many ways, truly AI-native.
MCP isn't the answer to every problem, but in plenty of places it works really well. The hype has clearly cooled, but the standard isn't going anywhere.
New standards are being built on top of it, like Google's [WebMCP](https://developer.chrome.com/docs/ai/webmcp). Where MCP works from the server side, WebMCP works from the client.
The core idea is to build tools out of the interactions on a page. That gives agents predefined actions to call, instead of scraping the page and guessing where to click. Today agents often work through a mix of screenshots, DOM elements, and the accessibility tree. WebMCP aims to be a simpler, more predictable alternative.
That opens the door to a new kind of human-browser-agent collaboration, where you don't just trigger actions like classic MCP, but share a visually rich interaction inside a shared context.
WebMCP isn't meant to replace classic MCP. It's an addition, and it only fits certain scenarios where human-in-the-loop and browser integration make sense. The standard is still in its infancy, and it's not clear whether it'll stick. Either way, it's good to see new ideas built on proven foundations.
## Distribution shift
A lot of sites now ship an agentic chat on their pages. Don't get me wrong, that's often a good move, but these days it's nowhere near enough. The quality varies. Some are genuinely good, others are painful to use. But quality isn't the real problem. The problem is how we pull information out of a source in the first place.
People have completely changed how they consume content. Some will just read your page. Others will paste the link into ChatGPT. Others reach for an agent like [Hermes](https://hermes-agent.nousresearch.com/), and some build their own custom setup, the way Kent C. Dodds built [Kody](https://github.com/kentcdodds/kody).
The takeaway? It's very hard to predict how the content you publish will be consumed. Instead of shrugging and thinking "it'll be fine, my user's agent will figure it out," we can flip it around and meet users halfway.
There's no single right answer. For less technical people, a built-in chat might be the friendliest option. For others, a copy-to-markdown button makes their life much easier. Some are only happy with an MCP or CLI their agent can use.
The inclusive mindset we once brought to building the web for people now shows up in how we give agents access to content. We have to start treating agents as a genuinely different kind of user, with new needs and problems we haven't solved yet.
## Careful with standards
I'm a little torn on standards in AI.
On one hand, there's a lot of chaos that could use some order. Every so often a new revolution shows up with a new approach or standard. Over the past few years we've actually adopted very few real standards for agents, and the loudest by far is the Model Context Protocol.
But other approaches emerged that never got wrapped in the "standard" label and yet stay stable and keep evolving across the ecosystem, like Context Engineering or the Ralph Loop.
Standardizing the underlying technology once drove incredible growth for the web. Then it fell behind, and in some areas we had to patch the gaps with outside tech. That's exactly what happened with accessible components. The standards didn't reach far enough, and custom libraries had to make up the difference. Those same libraries power Shadcn/ui today.
So I'm cautious about standards when I work with agents. Everything keeps changing, fast. Agent frameworks can't keep up, let alone standards. Initiatives show up, like [Agent2Agent (A2A)](https://a2a-protocol.org/latest/), but many die as quickly as they appear. Others have a moment, like [llms.txt](https://llmstxt.org/), then fade a little. What about the next proposals? Will WebMCP catch on, or get forgotten fast? We'll find out soon enough.
Standards or no standards, it's time to think about accessibility again. Differently than before, but just as seriously.