OpenAI, ARIA and SEO: How Atlas Advice Could Make the Web Worse

When OpenAI launched ChatGPT Atlas, its browser with ChatGPT built in, the announcement included a line aimed at website owners: they can add ARIA tags to improve how the ChatGPT agent works on their sites. The developer FAQ expands on it. Atlas, it says, relies on the same labels and roles that support screen readers to interpret page structure and interactive elements, so following WAI-ARIA best practices, with descriptive roles, labels and states on buttons, menus and forms, helps the agent recognize what each element does.

On the surface that sounds like good news for accessibility. Experienced practitioners, including the well-known accessibility consultant Adrian Roselli, read it very differently. Their concerns fall into two groups: what the advice reveals about how OpenAI sees ARIA, and what it is likely to trigger in the SEO world.

What the Advice Actually Signals

Read with an accessibility background, the guidance says several things at once:

• Unstructured sites are hard to scrape. Pages built from generic div elements, a common outcome of component-heavy frameworks used without care for semantics, are difficult for an automated agent to interpret.
• ARIA is being treated as bot metadata. The advice frames ARIA as a layer for steering an AI agent, not as a way to communicate with people using assistive technology.
• The goal is easier extraction. Better-labeled pages make it simpler for the agent to classify and structure content it collects from sites.
• The concept of ARIA is misunderstood. This is the point that needs the most context.

ARIA is meant to fill gaps, not to be the first tool you reach for. Long-standing accessibility guidance makes these points:

• Native HTML comes first. A real button, nav or label already exposes the right semantics. ARIA is the fallback when no suitable element exists.
• More ARIA often means less accessibility. Large-scale audits of the web regularly find that pages using ARIA have more detectable accessibility errors, not fewer, because roles and properties are easy to apply incorrectly.
• The APG is not a best-practices manual. The ARIA Authoring Practices Guide demonstrates patterns for building custom widgets; calling it "WAI-ARIA best practices" misrepresents its purpose.
• Forcing APG patterns onto ordinary content backfires. Authors who retrofit complex widget roles onto simple pages tend to make them harder, not easier, to use.

There is also a credibility problem. Accessibility specialists have repeatedly documented basic HTML and accessibility failures in ChatGPT's own interfaces over the past several years. A company with that track record now asking the rest of the web to add ARIA, chiefly so its agent can read pages more easily, understandably draws skepticism.

The Likely Fallout for SEO and Accessibility

The web is already filling up with machine-generated text. As human-written content gets crowded out, site owners look for any edge that might get them noticed, and a large industry exists to sell such edges.

The HTML

Element: Accessible Dynamic Results Without ARIA Hacks

The dynamic-result announcements we usually patch together with a div and ARIA are already built into HTML through the

element.

Angular v22: Stable Signal Forms, Async Reactivity and AI Agent Support

Angular v22 makes Signal Forms, Angular Aria and the resource APIs stable, adds @Service and injectAsync, and introduces MCP and WebMCP tooling for AI agents.

That industry has a long record of abusing whatever metadata search engines look at. Image alt text has been stuffed with keywords for decades. Once an AI vendor says its agent reads ARIA, ARIA becomes the next target. Expect to see:

• Redundant roles everywhere. Buttons, links and plain containers decorated with roles they either already have or should not have at all.
• Wrong roles applied for effect. Elements marked up as something they are not, simply to look more important to an agent.
• Keyword-stuffed labels. Any ARIA attribute that accepts free text is at risk. Keyword-laden aria-label values already exist in the wild, and an aria-roledescription packed with sales terms is easy to imagine.

The people hurt by this are not bots. Screen reader users hear every one of those labels and roles. When aria-label overrides visible text with a string of keywords, the page becomes noisy, confusing or unusable for them. SEO tricks have already done real damage to the web, LLMs have amplified that damage, and this advice gives the same playbook a fresh surface to exploit.

What Developers and Site Owners Can Do

A sensible response does not require rejecting accessibility work; it requires doing it for the right reasons:

• Use semantic HTML first. Proper headings, landmarks, form labels and native controls help assistive technology and, as a side effect, any automated reader.
• Add ARIA only to fix a real gap. Do not add it because an AI vendor said its agent likes it. Unnecessary ARIA is a net negative for users.
• Test with actual assistive technology. Screen reader testing, not agent behavior, should decide whether markup is correct.
• Push back on keyword stuffing in reviews. Treat SEO-motivated text in aria-label or aria-roledescription as a bug.
• Make deliberate choices about AI agents. Teams and individuals can decide whether they want an agentic browser reading and acting on their content, and can weigh the privacy and content-use implications when choosing tools.

The core message from accessibility practitioners is simple: ARIA exists for people. Repurposing it as a ranking signal for AI agents risks making the web worse for exactly the users it was designed to serve.