OpenAI Says Add ARIA for ChatGPT Atlas. Adrian Roselli Says Don't. The Two-Minute Check Between Them.

A visitor that clicks

You have spent some time getting robots.txt right, and maybe you pasted in a block of schema. Both of those are about AI reading your site. There is a newer kind of visitor that does something different: it clicks. An AI browser can open your homepage, hunt for the "Book now" button, and try to press it for somebody.

OpenAI's ChatGPT Atlas is one of those browsers. It is built on Chromium, and it launched in October 2025. OpenAI's Publishers and Developers FAQ says "ChatGPT Atlas uses ARIA tags," which it describes as the same labels and roles that support screen readers, to interpret page structure and interactive elements.

If you have never heard of ARIA, it is a set of extra attributes that web developers add to HTML so that screen readers can tell what a thing on the page is. A button, a menu, the main content area. The same information, it turns out, is useful to software that has to figure out where to click.

So far, so cool. Then the accessibility community read that sentence and had a very different reaction.

What OpenAI said, and what it didn't

The same FAQ page goes on to advise publishers to follow the standard ARIA best practices, adding descriptive roles, labels, and states to interactive elements like buttons, menus, and forms. That part I am paraphrasing, because I could not load the page directly when I researched this. That wording matches what a second site, Kickpoint, quotes independently, so I trust it. I would not hang much weight on my summary of the rest.

What the page does not say matters just as much. It makes no claim about ranking. It makes no claim about being cited in ChatGPT answers. It is about an agent understanding a page well enough to use it, which is a different problem from being quoted.

The pushback

Adrian Roselli, a well-known accessibility consultant, wrote a post called "OpenAI, ARIA, and SEO: Making the Web Worse" the day after Atlas launched. He has updated it since. His position is that ARIA should only be a fallback. He points out that sites using ARIA tend to be less accessible than sites that don't, a pattern the annual WebAIM Million reports have found. He also warns that asking sites to add ARIA for a machine invites keyword stuffing, and says he has already seen it in aria-label attributes.

The W3C, which writes the standards, agrees with him. Its ARIA Authoring Practices guide has a heading that reads "No ARIA is better than Bad ARIA." And the first rule in its "Using ARIA" document says that if a native HTML element already has the meaning and behavior you need, use that instead of taking some other element and adding a role to it.

Here is the part worth noticing. Roselli and OpenAI are not as far apart on the practical question as the headlines suggest. A real <button> is already a button to a screen reader, and presumably to an agent that reads the same information. A real <main> is already the main landmark. A real <nav> is already navigation. You do not add ARIA to those. You just use them.

What nobody has shown

There is no study showing that adding ARIA to your site makes an AI agent more likely to complete a booking. I looked. There is also no evidence that landmarks or ARIA make you more likely to be cited. Google's own AI features documentation says no special optimization is needed for AI Overviews or AI Mode beyond ordinary Search fundamentals, so landmarks are not a documented Google requirement either.

Agents also do not all read pages the same way. A Search Engine Journal piece from April 2026 sorts them by method: ChatGPT Atlas and Microsoft's Playwright MCP read the accessibility tree, Anthropic's Computer Use API works from screenshots, Google's Project Mariner combines vision with code structure, and OpenAI's CUA and Perplexity's Comet mix approaches. That is one trade-press author's classification, not vendor documentation, and it covers specific products rather than every agent a company ships. But it makes the point. ARIA is not a universal signal. One agent reading it does not mean all of them do.

A recent academic study (A11y-CUA, CHI 2026) did find that a computer-use agent completed 78.3% of 60 tasks by default, and far fewer when forced to work keyboard-only or through a magnifier. That tells you agents are weaker away from the mouse. It does not test whether changing your site helps, so I would not use it as a reason to touch anything.

The two-minute check

None of that uncertainty makes this check expensive, and a clean page is good for human visitors using assistive tools anyway.

First, open your homepage, right-click, and choose View Source. This is the raw HTML your server sends, which is what our audit and most crawlers see. Search the page for <main and <nav. You want to find both.

If you find them in DevTools' Elements panel but not in View Source, JavaScript is adding them after the page loads. That is the same gap I wrote about in Your Site Looks Fine to You. Most AI Crawlers Get the View-Source Version.. Page builders do this more than you would think.

Second, open Chrome DevTools. For each of your "Book now," "Call," and "Contact" controls, select its element in the Elements panel (or right-click the control and choose Inspect), then read its Role and Name in the Accessibility pane. Each one should show up as a button or a link with a name. If it shows up as a generic container with no name, somebody built your booking button out of a styled box. Owners on WordPress themes, Wix, and Squarespace run into this more than anybody expects, and it looks identical on screen.

Third, press Tab repeatedly from the top of the page. You should be able to reach those same controls with the keyboard. A control you cannot reach that way is probably not a real button.

Many page-builder themes already emit <main>, <nav>, and proper buttons. Check before you add anything. If something is missing, the fix is to use the native element, not to paste ARIA attributes from an SEO guide.

What our audit does with this

The Technical Health module is 12 points of the 100-point score. The landmark check is one point inside it, so one point out of 100 overall. It passes only if both <main> and <nav> appear in the raw HTML of your homepage. Only one present is a warning, neither is a fail, and a warning or a fail earns zero.

It looks for the literal elements. A <div role="main"> does not count, even though a browser treats it as the same landmark. It does not check button labels, link names, form labels, or any ARIA attribute. So it does not measure how ready you are for AI agents, and a pass means you have two native elements on one page. That is a small signal.

I would rather you spend the two minutes than chase the point.

The takeaway

Use the native elements. Skip bad or bolted-on ARIA, which Roselli argues makes things worse. Make sure the controls a customer, or a customer's assistant, would press are real buttons with real names.

That is a cheap fix with an honest, modest payoff, and nobody has shown it moves your citations or your bookings.

If you want a number for your homepage, the free Grade Check scores it on the same engine as the paid report, takes about a minute, and costs nothing. It shows a score and a letter grade, not the individual checks, so the view-source search above is how you see the landmark check itself.