How ChatGPT’s Atlas Browser Uses ARIA Tags to Navigate Websites

OpenAI launched their Atlas browser on October 21, 2025. This browser, built directly into ChatGPT, got marketing teams (including ours!) excited to experiment and test, and something interesting emerged. The AI Agents built into Atlas don’t navigate websites the way humans do, clicking through visual interfaces. Instead, it relies on ARIA (Accessible Rich Internet Applications) tags—the same semantic markup that screen readers use.

This changes the conversation around website accessibility. ARIA implementation is no longer just about compliance or serving users with disabilities (though those remain critical). AI tools now depend on the same semantic structure that assistive technologies require. When a website lacks proper ARIA implementation, AI browsers will struggle to navigate it the same way screen readers do.

This is also timely: the European Accessibility Act (EAA) requires WCAG 2.1 Level AA compliance by June 2025, just six months away at the time we’re publishing this. Over 4,000 digital accessibility lawsuits were filed in 2024, with 67% targeting companies under $25M revenue. And now Atlas demonstrates that proper ARIA implementation also positions websites for AI discoverability.

Let’s look at what this means for website optimization, why ARIA matters more than ever, and how to implement it properly.

Atlas’s Current State: Experimental and Evolving

Before diving into ARIA implementation, let’s be honest about where Atlas is right now.

Atlas’s agent mode is v1.0 technology which is usually slow and error-prone. Early testing reveals that simple tasks can take 10+ minutes, with frequent navigation failures even on well-structured sites. OpenAI explicitly labels the agent mode as “experimental,” and currently it’s available only on macOS (Windows and mobile versions are “coming soon”).

So why implement ARIA now if Atlas barely works? Because Atlas’s use of ARIA navigation, regardless of its current performance, will represent how AI tools will increasingly interact with websites. Website optimization isn’t about the Atlas that we’re using right now. Instead, it’s all about positioning for tomorrow’s AI landscape while also gaining immediate compliance and SEO benefits.

Think of it this way: Atlas is proof of concept. Whether this specific browser succeeds or fails, the idea that AI tools will use semantic markup to understand website structure will become increasingly common. The first AI browser to use ARIA navigation won’t be the last.

How Atlas Browser Navigates Websites Using ARIA Tags

Let’s walk through how Atlas actually moves around a website. Understanding this mechanism is critical for knowing what to implement.

OpenAI’s documentation explicitly states: “ChatGPT Atlas uses ARIA tags—the same labels and roles that support screen readers—to interpret page structure and interactive elements.” Unlike visual navigation where humans see buttons, menus, and forms, Atlas reads semantic structure through ARIA attributes.

What ARIA Actually Does

ARIA is a set of attributes that define ways to make web content more accessible. These attributes communicate three types of information:

• Roles: What an element is (role="button", role="navigation", role="dialog")
• States: Current condition (aria-expanded="true", aria-selected="false")
• Properties: Relationships and labels (aria-label="Submit form", aria-controls="menu-1")

Screen readers have used ARIA for years to help users with disabilities navigate complex web applications. Now AI browsers like Atlas use this same semantic information to understand page structure and interactive elements.

The difference between visual and semantic navigation

When sighted users encounter a dropdown menu, they see a button with a down arrow, click it, and a menu appears. That is visual navigation. But for Atlas and screen readers, the visual presentation means nothing. They need semantic navigation elements like:

• aria-haspopup="true" to know a dropdown exists
• aria-expanded="false" to understand current state
• aria-controls="menu-1" to link the button to its menu
• JavaScript to update aria-expanded to "true" when opened

This is where most implementations break. Developers add ARIA attributes to satisfy automated testing tools without implementing the state management that makes them actually work. The result are sites that look accessible but aren’t navigable by either screen readers or AI browsers.

ARIA Implementation Issues: Why 79% Get It Wrong

Before diving into implementation guidance, let’s acknowledge a sobering reality from WebAIM’s 2025 Million study: pages with ARIA have twice as many accessibility errors as pages without. 79% of websites misuse ARIA in ways that hurt rather than help screen reader users and by extension, AI navigation.

This isn’t a reason to avoid ARIA. It’s a reason to take implementation seriously.

Why ARIA is Perceived to be Difficult to Implement

ARIA implementation requires thinking differently about website structure. Most developers work visually in that they see what users see. But ARIA requires semantic thinking, which is understanding how assistive technologies and AI tools perceive structure.

Here’s what typically happens: teams add ARIA attributes because automated tools flag missing accessibility features. A dropdown gets aria-haspopup="true" and aria-expanded="false". But the JavaScript to update aria-expanded when the dropdown opens isn’t included. Visually it works perfectly. For Atlas and screen readers, the dropdown is permanently “collapsed” even when open. Thinking about what you see vs what is represented in the ARIA is where people sometimes struggle initially. But with patience and practice, thinking semantically can become second nature.

What Differentiates Proper ARIA Implementation From Misuse?

The sites that implement ARIA correctly share common practices:

• Comprehensive testing: Automated tools plus manual screen reader validation
• Proper governance: Clear documentation, responsibility assignment, maintenance schedules
• Understanding over attribute copying: Teams learn ARIA principles, not just attribute lists
• State management: JavaScript updates ARIA attributes dynamically as element states change
• Ongoing maintenance: Regular audits catch regressions as sites evolve

Following this framework helps sites fall in the 21% who get it right, not the 79% who don’t.

Interactive Elements That Need ARIA Tags for AI Navigation

Let’s break down the interactive elements that cause the most navigation issues when ARIA tags are missing or incorrect. These are the high-priority items to audit.

Dropdown Menus and Select Elements

Dropdowns are one of the most commonly misimplemented interactive elements. Not only do you need to add aria-haspopup="true" and aria-expanded="false" to the trigger button, but also the JavaScript to toggle aria-expanded to "true" when the dropdown opens. Otherwise, Atlas and screen readers will have no idea that the dropdown is open.

Example of Proper ARIA Implementation for Dropdown Menus and Select Elements

<!-- Before: Inaccessible dropdown -->
<button class="dropdown-trigger">
  Products
</button>
<div class="dropdown-menu">
  <!-- Menu items -->
</div>

<!-- After: Accessible dropdown -->
<button 
  class="dropdown-trigger"
  aria-haspopup="true"
  aria-expanded="false"
  aria-controls="products-menu"
  id="products-button">
  Products
</button>
<div 
  class="dropdown-menu"
  id="products-menu"
  aria-labelledby="products-button">
  <!-- Menu items -->
</div>

What this does:

• aria-haspopup="true" tells Atlas a dropdown exists
• aria-expanded="false" indicates current state
• JavaScript updates aria-expanded to "true" when opened
• aria-controls="products-menu" links trigger to dropdown content

Modal Dialogs and Overlays

Modal dialogs are where ARIA implementation complexity becomes clear. Visual implementation is straightforward: overlay appears, background dims. But Atlas and screen readers need role="dialog", aria-modal="true", and JavaScript focus management to navigate properly.

Example of Proper ARIA Implementation for Modal Dialogs and Overlays

<div 
  role="dialog"
  aria-modal="true"
  aria-labelledby="modal-title"
  aria-describedby="modal-description">
  <h2 id="modal-title">Confirm Action</h2>
  <p id="modal-description">Are you sure you want to proceed?</p>
  <button>Confirm</button>
  <button>Cancel</button>
</div>

Plus JavaScript for:

• Moving focus into modal when opened
• Trapping focus within modal (tab wraps inside)
• Returning focus to trigger element when closed
• Closing on Escape key press

This takes significant work because it requires both ARIA attributes AND complete JavaScript focus management. Visual CSS doesn’t communicate any of this to assistive technologies or AI browsers.

Form Elements and Input Fields

WebAIM’s 2025 study found that 34.2% of form inputs aren’t properly labeled. You wouldn’t see this without looking at the code, as forms look accessible visually with labels positioned above fields, but there is zero ARIA connection between label and input.

Example of Proper ARIA Implementation for Form Elements and Input Fields

<!-- Option 1: HTML label element (preferred when possible) -->
<label for="email-input">Email Address</label>
<input 
  type="email" 
  id="email-input"
  aria-required="true"
  aria-invalid="false">

<!-- Option 2: ARIA labeling (for custom implementations) -->
<span id="email-label">Email Address</span>
<input 
  type="email"
  aria-labelledby="email-label"
  aria-required="true"
  aria-describedby="email-error">
<span id="email-error" role="alert"></span>

Validation and error handling:

• aria-required="true" indicates required fields
• aria-invalid="false" changes to "true" on validation failure
• aria-describedby links to error messages
• Error messages in elements with role="alert" are announced immediately

Accordions and Expandable Content

Accordions appear straightforward but state management adds complexity. Visual implementation uses CSS for smooth expand/collapse transitions. But aria-expanded attributes must be updated dynamically with JavaScript, or Atlas and screen readers have no idea which sections are open.

Example of Proper ARIA Implementation for Accordions and Expandable Content

<button 
  aria-expanded="false"
  aria-controls="section-1"
  id="accordion-button-1">
  Section Title
</button>
<div 
  id="section-1"
  aria-labelledby="accordion-button-1"
  hidden>
  <!-- Content -->
</div>

JavaScript must:

• Toggle aria-expanded between "false" and "true" on click
• Show/hide content section
• Update hidden attribute on content div

This is one of those areas where visual implementation is straightforward but ARIA adds another layer of state management to maintain.

Accessibility Widgets Are Not a Solution

If there’s one thing to understand about accessibility implementation, it’s this: accessibility widgets (those floating toolbars claiming instant compliance) do not provide legal protection and may actually increase lawsuit risk.

Here’s the data:

• 1,023 companies with accessibility widgets were sued in 2024—that’s 25% of all digital accessibility lawsuits (source: UseableNet)
• 62% increase from 2022 in lawsuits targeting sites with these widgets (source: UseableNet)
• accessiBe (major widget provider) fined $1M by FTC in 2025 for false advertising about compliance (source: Federal Trade Commission)

Why Widgets Fail

Widgets mask underlying accessibility issues rather than fixing them. Atlas, just like screen readers, navigates the actual Document Object Model (DOM) of the page, not the widget’s overlay. Courts increasingly reject widget-only implementations as insufficient compliance.

A pattern emerges in accessibility audits: sites have widgets installed, owners believe they’re protected, but testing reveals the same navigation barriers widgets claim to fix. The widget creates a false sense of security while actual problems remain.

If you currently have a widget installed: Don’t remove it immediately (some users may rely on it), but prioritize implementing real fixes and plan transition away from widget dependency. Only proper ARIA implementation in underlying code provides accessibility.

How to Audit Your Website’s ARIA Accessibility Implementation

Let’s walk through how to audit current ARIA implementation. This assessment will help you prioritize where to focus effort first.

Understanding the Capabilities and Limitations of Accessibility Testing Tools

Here’s the critical reality about automated testing: tools detect only 20-40% of accessibility issues. Running Lighthouse and getting a perfect score doesn’t mean comprehensive accessibility—it means the baseline check passed.

An automated tool is an important part of evaluating accessibility, including ARIA elements, but they can miss out on important parts of a true accessibility audit.

What Automated Tools Miss:

• Semantic meaningfulness: Tools detect aria-label presence but can’t evaluate whether the label is helpful
• Dynamic behaviour: State changes triggered by user interaction often aren’t tested
• Context appropriateness: Tools flag technical violations but miss user experience issues
• Keyboard navigation flow: Logical tab order requires human evaluation

There are many automated tools on the market. Here are the pros and cons of some popular ones:

axe DevTools (Deque Systems)

• Capabilities: Uses a zero false positives approach, typically detects more than half of the issues
• Best for: Developers who need detailed, accurate reporting
• Limitations: Steeper learning curve; there will still be issues that require human judgment

WAVE (WebAIM)

• Capabilities: Visual overlay showing accessibility issues directly on page
• Best for: Beginners learning accessibility; educational purposes
• Limitations: Catches only basic issues; limited depth for complex implementations

Google Lighthouse

• Capabilities: Built into Chrome DevTools; quick accessibility overview
• Best for: Baseline audits and monitoring trends
• Limitations: Uses axe-core but limited subset; detects only 20-30% of issues

Pa11y

• Capabilities: Command-line tool for CI/CD integration; automated testing on every build
• Best for: Preventing regressions in development workflow
• Limitations: Setup complexity; same detection limitations as other automated tools

Manual Testing is Still Required

Manual screen reader testing is required, not optional. This is where the remaining 60-80% of accessibility issues are discovered.

Basic screen reader testing approach:

1. Windows: Download NVDA (free) or JAWS (paid)
2. macOS: VoiceOver (built-in, press Command+F5)
3. Test critical paths: Main navigation, primary forms, key conversion flows
4. Time investment: 2-4 hours per major user flow minimum

What to validate:

• Are interactive elements announced correctly?
• Do state changes (expanded/collapsed, selected/unselected) communicate?
• Can users complete tasks using only keyboard + screen reader?
• Are error messages clear and actionable?

This is genuinely challenging work that requires both technical skill and patience. Don’t feel like testing everything at once is necessary. Just start with the homepage and primary conversion path as those have the highest impact.

How to Prioritize Finding and Fixing Accessibility Issues

Our experience shows that focusing on business-critical elements first produces the most meaningful improvements:

Tier 1 – Critical (Do First):

• Main navigation structure
• Primary conversion forms (contact, purchase, signup)
• Critical interactive elements on high-traffic pages
• Resource needed: 20-40 hours for average site

Tier 2 – Important (Next 3-6 Months):

• Secondary navigation elements
• Content accordions and expandable sections
• Modal dialogs site-wide
• Resource needed: 40-80 hours

Tier 3 – Comprehensive (Ongoing):

• Full site audit and remediation
• Component library documentation
• Team training for content creators
• Automated testing in CI/CD pipeline
• Resource needed: Ongoing 10-20 hours/month

Think about the most critical user flows on the website. Prioritizing the checkout process, contact forms, and main navigation gives the biggest impact for users AND for Atlas.

Why ARIA Tags Matter for AI Browser Navigation Beyond Atlas

Atlas is the first high-profile example, but let’s look at where AI tool navigation is heading and why ARIA implementation matters for the broader landscape.

The AI Browser Category is Emerging

• Perplexity Comet launched before Atlas
• The Browser Company Dia (Arc browser evolution) is in development
• Google Gemini in Chrome represents defensive positioning from Google
• Microsoft Copilot in Edge shows similar strategic moves

Whether these specific browsers succeed isn’t the point. The pattern they represent, where AI tools that need to understand and interact with web content programmatically, will continue evolving. ARIA provides the semantic structure these tools need.

Beyond Browsers, Other AI Applications are Emerging

• Voice assistants navigating web content more sophisticatedly
• Automated form filling and task completion
• Content extraction and summarization tools
• AI shopping assistants that need to navigate e-commerce sites

Search Engine Evolution Matters as Well

Google’s algorithm increasingly favors semantic structure. While Google confirmed accessibility isn’t a direct ranking factor, the correlation exists: AccessibilityChecker and Semrush’s 2025 study of 10,000 websites found a 23% average organic traffic increase associated with improved accessibility scores.

Why? Better semantic markup improves:

• User engagement metrics (longer sessions, more site engagement)
• Mobile experience (mobile-first indexing benefits from accessible design)
• Core Web Vitals (performance metrics overlap with accessibility requirements)

However, Amazon has high rankings globally despite failing most accessibility checks. Other fundamental SEO tactics such as authority, links, and content quality matter more for ranking. Accessibility is just one component of website optimization.

Business Case: ARIA Compliance, SEO, and AI Discoverability

Let’s talk about why this work deserves budget and priority. The business case for ARIA implementation has strengthened with Atlas and similar AI tools, but it rests on three pillars.

1. Accessibility Compliance (Independent of Atlas)

• European Accessibility Act: Requires WCAG 2.1 Level AA compliance by June 2025 (six months away)
• 4,000+ lawsuits filed in 2024: Digital accessibility litigation remains high
• 67% target small businesses: Companies under $25M revenue face highest risk
• Penalties are substantial: Germany allows up to €500,000; Italy up to 5% of annual turnover

The EAA affects any company selling to EU customers. Other countries have similar rules. For example, US-only businesses face increasing lawsuit risk from ADA Title III claims.

2. SEO Correlation (Not Causation, But Meaningful)

Multiple studies show correlation between accessibility improvements and organic traffic increases, including the AccessibilityChecker/Semrush study that we mentioned earlier.

Of course, correlation doesn’t equal causation. Amazon’s excellent rankings despite poor accessibility proves other factors matter more. Think of accessibility as one piece of the SEO puzzle. It’s meaningful but doesn’t stand on its own.

3. AI Discoverability (Future-Proofing)

Atlas demonstrates that AI tools will increasingly rely on semantic markup. Whether this specific browser succeeds, the approach it represents where their AI Agents use ARIA for navigation will become more common.

Organizations implementing proper ARIA now gain:

• First-mover advantage before competitors adapt
• Positioning for whatever AI tools emerge next
• Protection against future algorithm updates favoring semantic structure

Implementation Requires Real Investment

The reality is that accessibility implementation is not cheap or fast:

• Tier 1 priorities: 20-40 hours (critical navigation, forms, high-traffic pages)
• Comprehensive coverage: 40-80 hours or more depending on site complexity
• Ongoing maintenance: 10-20 hours/month for monitoring and updates
• External support: $5,000-15,000 for professional audit and critical fixes

This is substantial work, not a weekend project. Organizations must weigh accessibility investment against other priorities. The triple benefit (compliance + SEO + AI) certainly strengthens the justification, but budget constraints are real, especially for small businesses.

ARIA Implementation Guide: Priorities and Getting Started

Let’s break down how to actually implement this.

Implementation Options Based on Resources

Option 1: Phased Priority Approach (Recommended for Most)

• Month 1: Audit to understand scope (20-40 hours)
• Months 2-3: Critical path fixes—main navigation, primary forms, high-traffic pages (20-40 hours)
• Months 4-6: Important elements—modals, accordions, secondary features (40-80 hours)
• Ongoing: Comprehensive coverage and maintenance

This option will get organizations to meaningful compliance before the June 2025 EAA deadline, with continued improvement after.

Option 2: Professional Acceleration (If Budget Allows)

• External accessibility firm can compress timeline significantly
• Investment: $15,000-50,000 depending on site complexity
• Faster but requires budget many small businesses don’t have
• Consider hybrid: external audit plus internal implementation with consultant training

Option 3: Minimum Viable Compliance (If Deadline Absolute)

• Focus exclusively on WCAG 2.1 Level AA requirements for EAA
• Defer nice-to-have implementations
• Plan for continued improvement after deadline
• Riskier but achievable with focused effort

Skills and Resources Required

Technical Capabilities Needed for Accessibility Reviews

• HTML/CSS semantic markup understanding (intermediate level)
• JavaScript state management (intermediate-advanced level)
• ARIA specification knowledge (requires focused study, not just documentation skimming)
• Screen reader operation (NVDA, JAWS, VoiceOver)
• Testing methodology and QA process design

For Teams Without ARIA Expertise

We recommend structured learning. Try implementing one element type fully (e.g., forms), validate with screen reader testing, document learnings, then move to the next element type. This builds expertise as you go rather than waiting to learn everything, then trying it out.

Or you can bring in specialist support. There are many consultants or contractors with ARIA expertise, or try a hybrid approach where a consultant trains your internal developers during implementation. That last option can help save you budget down the road as your internal team can take over ongoing monitoring.

Keeping ARIA and Accessibility Working as Your Site Evolves

Accessibility improvements aren’t just a one and done situation. Ongoing compliance comes down to governance.

• Component library documentation: Each interactive component documented with required ARIA attributes
• Responsibility assignment: Clear ownership (RACI matrix approach) for implementation, testing, and maintenance
• QA testing checklists: Specific validation steps before release
• Regular audit schedule: Quarterly comprehensive audits to catch regressions
• Team training: Ongoing education as ARIA standards evolve

You don’t need to create a 60 page process guide or standard operating procedure document. Just start somewhere! Even documenting the three most common interactive elements with their ARIA requirements is progress.

Frequently Asked Questions About ARIA Tags

Getting Started: Your Next Steps

Here’s what to do next, based on where you’re currently at:

Immediate Actions

1. Audit current state—even just the homepage and primary conversion path

• Use automated tools (WAVE, Lighthouse) for baseline
• Test with keyboard navigation
• Document critical gaps

2. Prioritize based on business impact

• High-traffic pages first
• Conversion-critical forms
• Main navigation structure

3. Start small but start now

• Fix one critical element properly
• Document learnings
• Build momentum for larger work

Timeline Recommendations

• Month 1: Audit and prioritization
• Months 2-3: Critical element fixes (Tier 1)
• Months 4-6: Important element fixes (Tier 2)
• Ongoing: Comprehensive implementation and maintenance

Two steps forward, one step back is still progress. Organizations don’t change overnight—this is a marathon, not a sprint. The time to start is right now, even if it’s just auditing the homepage.

Resources to explore

• W3C WAI-ARIA Authoring Practices: Official implementation guidance
• WebAIM: Training materials and testing tools
• NVDA or VoiceOver: Free screen readers for manual testing

This work is substantial, but it’s also an investment in making websites work for everyone: humans with disabilities, AI tools, search engines, and users who benefit from better semantic structure.